Users act on their belief about how the system works, not on how it actually works.
I'm designing
An AI Product
Model-driven features, where explanation, control and correction carry more weight than accuracy.
What this surface turns on
- What the user is told about how a result was produced.
- How a wrong result is corrected, and how cheaply.
- Whether anything changes without explicit acceptance.
- What happens at the boundaries of what the model can do.
Where these usually go wrong
- Output presented with uniform confidence regardless of how confident the system actually is.
- No way to correct a wrong result other than starting again.
- Content changed without explicit acceptance.
- Streaming output with no way to stop it.
- Failure states that say the request failed without saying what to do instead.
Why these
AI features fail on explanation and control more often than on model quality. The selection covers setting expectations, showing confidence honestly, keeping the person in charge of the output, and the writing that makes all three legible.
Why it works the way it does
The reasoning layer. Read these when a decision needs justifying, or when something is failing and you cannot say why.
Users make mistakes and change their minds, so every state needs a clearly marked way out.
Below roughly 400 milliseconds of system response, people stop waiting on the machine and productivity rises sharply.
People give disproportionate weight to a source that appears authoritative, including visual markers of authority.
Absorbed, effortless concentration occurs when challenge and skill are balanced, and interruptions destroy it.
An interface people can explore without fear produces confident users and fewer support tickets.
The craft decisions
The visual and structural foundations that carry most of the weight on this surface.
The order in which elements are noticed, controlled by size, weight, colour, position and space.
Making one thing stand out, which only works if most things do not.
Animation should explain a change, and anything that does not explain something is delay.
Using size, weight, colour and space to make the structure of text visible before it is read.
Colours assigned a fixed meaning, which only works if the assignment is consistent and never the only signal.
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
Apply the change immediately and reconcile with the server afterwards, so the interface never waits on the network.
What to show while waiting, chosen by how long the wait is and whether its length is known.
The screen before there is anything to show, which is a teaching opportunity rather than a gap.
Reversing the last action, which is the single highest-value safety mechanism in most products.
Telling users something happened, where the default should be not to interrupt.
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
A persistent message tied to a context, which is where anything requiring action belongs.
A brief confirmation that disappears, which makes it unsuitable for anything the user must act on.
Communicating how far through something the user is, which requires honesty about what you can measure.
A small marker of status, category or count, which must not look like something you can press.
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Telling assistive technology that something changed, when focus did not move to say so.
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
Large-scale motion can cause nausea and dizziness, so the system preference must be honoured.
Software that reads the interface aloud, navigating by structure rather than by layout.
Language and content
The words do more work here than most teams budget for.
The small pieces of text that do most of the work: labels, hints, empty states, errors and confirmations.
Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.
Say what happened, why if you know, and what to do next, in that order and in plain language.
Deciding what content a user needs and in what order, which is a design activity rather than a writing one.
How to find out
Research methods suited to the questions this surface raises.
Watching people attempt real tasks, which is the most direct evidence available about whether a design works.
Structured conversations about what people actually did, which is far more reliable than what they say they will do.
Participants record their own experience over time, which captures things a single session cannot.
Measuring what people do at scale, which tells you where problems are and never why they exist.
Check your work
Interactive checklists, with progress saved in your browser.
Whether the design serves the user's interest, including where that now overlaps with legal obligation.
A structured pass across the whole product, organised by the same categories as the audit tool.
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
Documents you might need
Fillable templates, prefilled so they are usable rather than empty.
A feature specification that covers states, edge cases and accessibility rather than only the happy path.
The problem, the constraints and the success measures, agreed before design starts.
Decisions other teams made
Worked cases, including the options that were rejected and why.
An accurate suggestion feature went unused until it explained itself and became easy to reject.
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.