Users act on their belief about how the system works, not on how it actually works.
MOD·001
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.
HEUR·003
Below roughly 400 milliseconds of system response, people stop waiting on the machine and productivity rises sharply.
LAW·006
People give disproportionate weight to a source that appears authoritative, including visual markers of authority.
BIAS·006
Absorbed, effortless concentration occurs when challenge and skill are balanced, and interruptions destroy it.
PSY·005
An interface people can explore without fear produces confident users and fewer support tickets.
PRIN·006
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.
FND·001
Animation should explain a change, and anything that does not explain something is delay.
FND·052
Using size, weight, colour and space to make the structure of text visible before it is read.
FND·032
Colours assigned a fixed meaning, which only works if the assignment is consistent and never the only signal.
FND·023
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.
PAT·013
What to show while waiting, chosen by how long the wait is and whether its length is known.
PAT·011
The screen before there is anything to show, which is a teaching opportunity rather than a gap.
PAT·010
Reversing the last action, which is the single highest-value safety mechanism in most products.
PAT·022
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.
CMP·015
A brief confirmation that disappears, which makes it unsuitable for anything the user must act on.
CMP·014
Communicating how far through something the user is, which requires honesty about what you can measure.
CMP·026
A small marker of status, category or count, which must not look like something you can press.
CMP·023
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.
A11Y·009
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
A11Y·002
Large-scale motion can cause nausea and dizziness, so the system preference must be honoured.
A11Y·012
Software that reads the interface aloud, navigating by structure rather than by layout.
A11Y·005
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.
WRT·001
Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.
WRT·003
Say what happened, why if you know, and what to do next, in that order and in plain language.
WRT·002
Deciding what content a user needs and in what order, which is a design activity rather than a writing one.
WRT·004
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.
RES·001
Structured conversations about what people actually did, which is far more reliable than what they say they will do.
RES·003
Participants record their own experience over time, which captures things a single session cannot.
RES·013
Measuring what people do at scale, which tells you where problems are and never why they exist.
RES·010
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.
CHK·010
A structured pass across the whole product, organised by the same categories as the audit tool.
CHK·008
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
CHK·002
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.
TPL·011
The problem, the constraints and the success measures, agreed before design starts.
TPL·010
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.
CASE·010
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.