Every system has irreducible complexity. The only question is whether the user absorbs it or the product does.
LAW·005
I'm designing
A Checkout
The last few screens, where every unnecessary decision costs a sale.
What this surface turns on
- Whether an account is required before payment.
- The order of steps, and whether it matches how people think about buying.
- How address and card entry tolerate messy input.
- What the confirmation actually says.
Where these usually go wrong
- Forced account creation before payment.
- Card numbers rejected because the user typed the spaces printed on the card.
- Address fields that impose one country's structure on everyone.
- Generic payment errors that leave the user guessing which detail was wrong.
- Entered data cleared on failure.
Why these
Checkout is the highest-stakes form most products have. These entries cover cost transparency, payment failure, guest access and the confirmation, because those are the four places where money is actually lost.
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.
Be liberal in what you accept and conservative in what you send, which for interfaces means accepting messy input and returning clean output.
LAW·012
Effort increases as a visible goal gets nearer, and artificial early progress accelerates the whole journey.
LAW·014
People judge an experience by its most intense moment and its ending, not by the average of the whole thing.
LAW·007
Working memory holds a small number of chunks, so the design lever is what counts as a chunk, not the raw item count.
LAW·004
Losing something feels worse than gaining the same thing feels good, which shapes how people react to change.
BIAS·002
The craft decisions
The visual and structural foundations that carry most of the weight on this surface.
Things placed close together are read as belonging together, before anything is read.
FND·004
A fixed set of spacing values, so every gap in the product comes from the same vocabulary.
FND·042
Using size, weight, colour and space to make the structure of text visible before it is read.
FND·032
Difference is what makes anything perceivable, and it is measurable for text against its background.
FND·002
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
Breaking a long task into steps, which reduces per-screen load but adds navigation cost and abandonment points.
PAT·016
Checking input at the right moment, which is rarely while the user is still typing.
PAT·007
Suggestions as the user types, which turns recall into recognition when it is fast enough.
PAT·003
An interruption that should be reserved for genuinely irreversible actions, because it stops being read when it is routine.
PAT·008
What to show while waiting, chosen by how long the wait is and whether its length is known.
PAT·011
Components you will specify
Each entry covers the states, behaviour and accessibility contract you need to define.
Free-form entry, where the label, the hint and the error placement do most of the work.
CMP·003
Choosing one option from a known set, which is the wrong control below about five options.
CMP·004
A persistent message tied to a context, which is where anything requiring action belongs.
CMP·015
Communicating how far through something the user is, which requires honesty about what you can measure.
CMP·026
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Errors must be identified in text, described specifically, and accompanied by a suggested fix where one is known.
A11Y·016
Every input needs a persistent label, and format requirements must be stated before the user types.
A11Y·017
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
A11Y·002
Deliberately moving focus when the interface changes, so keyboard and screen reader users are not stranded.
A11Y·004
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
Say what happened, why if you know, and what to do next, in that order and in plain language.
WRT·002
Designing so the product can be adapted to other languages and regions without being rebuilt.
WRT·006
How to find out
Research methods suited to the questions this surface raises.
Measuring progression through a sequence, where the largest drop is rarely the biggest opportunity.
RES·011
Watching people attempt real tasks, which is the most direct evidence available about whether a design works.
RES·001
Comparing variants with real traffic, which tells you what happened without telling you why.
RES·009
Check your work
Interactive checklists, with progress saved in your browser.
Product pages, cart and checkout, covering the decisions that determine whether people buy.
CHK·006
A review pass for any form, covering structure, labelling, validation, errors and accessibility.
CHK·001
Whether the design serves the user's interest, including where that now overlaps with legal obligation.
CHK·010
Documents you might need
Fillable templates, prefilled so they are usable rather than empty.
Every path through a task, including the error paths and the states most flows forget.
TPL·005
A session script with tasks phrased as goals, and moderator prompts that do not lead.
TPL·007
Decisions other teams made
Worked cases, including the options that were rejected and why.
A retailer required registration before purchase to build its customer database, and lost the sales it was trying to capture data about.
CASE·001
Splitting a long form into steps did not raise completion until the team also saved progress and let people come back.
CASE·009
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.