UX, UI and usability: differences when designing with AI

You ask AI for “a screen to book medical appointments, modern and clean”. Within seconds it gives you something that looks finished: a calendar, a list of time slots and a button to continue. But looking good doesn’t mean it works.

To fill the gaps in your request, the AI had to assume three things: who the screen is for, how each element responds and whether anyone can actually finish booking. Each assumption maps to a concept we often blur together: UX, UI and usability.

In short:

• UX: everything the person experiences before, during and after using the screen.

• UI: the elements they interact with and how each one responds.

• Usability: whether the person reaches their goal, how much effort it takes and how they feel doing it.

This article accompanies the first episode of Back to Basics, a series on UX/UI fundamentals for working with AI. The case is fictional: a medical appointments app built as a prototype to illustrate the ideas. It doesn’t describe a real project or real results.

1. What AI assumes when the request is vague

Nielsen Norman Group looked at how AI prototyping tools perform in real design contexts, in the article Good from Afar, But Far from Good. One of its findings is that with general instructions, AI makes assumptions and results vary widely. It’s not a one-off flaw of the model: it’s what happens when the request leaves decisions open.

In our example, one possible answer shows nine open time slots and a “Continue” button that is always active. It looks tidy, but it hides three assumptions:

• UX, who it’s for: the AI doesn’t know who is booking, from where or what they need afterwards.

• UI, how it responds: every slot looks available and the button moves on even if you haven’t picked a time.

• Usability, whether it can be completed: nobody checked whether a person can actually book.

Whatever you don’t tell the AI, it assumes. Fundamentals help you fill those gaps before generating and review the result afterwards.

2. UX: the experience goes beyond the screen

The ISO 9241-210 standard describes user experience as a person’s perceptions and responses before, during and after using a product or service. Don Norman and Jakob Nielsen ask us to tell it apart from the interface: UX covers the whole relationship with the service, not only what appears on screen.

When booking an appointment, the journey has three stages:

• Before: the person needs a general practice appointment and looks for where to book it.

• In the app: they pick a time, review the date, time, location and price, and confirm.

• After: they need to know what comes next: whether they’ll get a reminder, how to get there and how to change or cancel.

If the confirmation only says “Booking successful”, the experience fails even if the interface is flawless. The person is left with questions the screen doesn’t answer: will I get a reminder? Where exactly is it? What do I do if I can’t make it?

A good confirmation closes the journey: it repeats what was booked, lets you add it to your calendar, explains how to get there and says how to change or cancel.

3. UI: how each element responds

UI is what lets people interact: buttons, fields, lists and messages. Designing it isn’t only deciding how each element looks, but how it responds.

A time slot in a picker goes through three moments:

• Before tapping: you can see which times are free and which aren’t. A taken slot is crossed out and can’t be selected.

• On tap: the slot responds instantly, confirming the tap registered.

• On release: the time stays selected, with a check icon rather than just a colour change, and “Continue” becomes active.

If you don’t define those states, the AI invents or omits them. An active button with no time selected is a UI problem: a state nobody decided.

The same goes for less visible states: while loading, when there are no slots or when a time gets taken right as you confirm. A request that doesn’t mention them lets the AI draw only the path where everything goes right.

4. Usability: can the person do what they came to do?

ISO 9241-11, as cited by NIST, defines usability through three measures: effectiveness, efficiency and satisfaction, always for specific users, goals and contexts. In plain language: whether the person completes the task, how much effort it takes and how they feel doing it.

An example: to book, you enter an incomplete phone number and tap “Continue”. There are two ways to respond:

• Wipe everything: a notice says the date and time are missing, and the fields are cleared. You have to redo work you had already done.

• Keep the data: the date and what you typed stay in place, and only the phone field is flagged with a specific message: “2 digits missing”.

The GOV.UK Design System recommends the second: say what went wrong and how to fix it, and don’t clear what the person already typed.

A screen that looks good doesn’t prove it’s easy to use. Usability can’t be guessed by looking at a screen: you confirm it by watching people use it.

5. Turn the fundamentals into a request

With these three concepts, the same request reads differently. Instead of “modern and clean”, tell the AI who it’s for, which states it needs, what it must not make up and how you’ll know it works.

This is the full request for the case, split into four parts:

• Goal: a screen to book a medical appointment from a phone.

• Context: general practice at the North location. Use the buttons and styles the project already has.

• States: what happens while loading, if there are no slots, if a time is taken or gets taken on confirm, if the person makes a mistake and, once confirmed, where it is and how to change or cancel it.

• Constraints: don’t make up clinical data or prices. It must be usable with a keyboard only.

Each part answers one assumption. The goal and context cover UX, the states cover UI and the constraints set limits you can check. The result isn’t a finished screen: it’s a screen ready to test. If AI is also part of the product, Designing AI products: control, trust and recovery explains how to keep people in control.

6. Review the screen the way the person would

After generating, walk through the interface. Reviewing isn’t looking at the screen, it’s using it. Repeat the journey on mobile, on desktop and with the keyboard only. If the screen is already in code, Coded prototypes: what to validate before handing over an interface covers what else to check.

Checklist before signing off an AI-generated screen

• Can I complete the booking on mobile and on desktop?

• Do I understand what I selected and what will happen next?

• Can I fix a mistake without losing my data?

• Can I reach everything with the Tab key and always see what’s selected?

• Does the confirmation match what actually happened?

If any answer is “no”, the screen isn’t done. And even if every answer is “yes”, this review doesn’t replace watching real people try to book. That is still the best evidence.

As Nielsen Norman Group puts it in State of UX 2026: “The fundamentals of good UX won’t change.” AI can help you build. Fundamentals help you decide what to build and how to evaluate it.

Which of the three concepts do you miss most when reviewing an AI-generated screen? Tell me on LinkedIn.

Sources

1. ISO (2019). ISO 9241-210:2019. Human-centred design for interactive systems. International standard.

2. Norman and Nielsen. The Definition of User Experience (UX). Nielsen Norman Group.

3. ISO 9241-11:2018, as cited by NIST. Usability. NIST Computer Security Resource Center glossary.

4. GOV.UK Design System. Error message and Validation.

5. Wang and Brown (2025). Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts. Nielsen Norman Group.

6. Moran, Budiu, Gibbons and others (2026). State of UX 2026: Design Deeper to Differentiate. Nielsen Norman Group.