Recognising something on screen is far easier than remembering it, so keep the information visible.
HEUR·006
I'm designing
Authentication
Sign-in, sign-up, recovery and the security decisions that show up as usability ones.
What this surface turns on
- Which methods you support, and which is the default path.
- How much you tell the user when authentication fails.
- How recovery works when someone loses access.
- Whether any step demands a cognitive test the user cannot pass.
Where these usually go wrong
- Paste blocked in password fields, which breaks password managers for no security gain.
- Autocomplete attributes missing, so browser autofill does not work.
- Recovery flows that assume the user still has the email address they lost access to.
- A confirm-password field where a show-password toggle would do.
- Codes that must be transcribed manually, which WCAG 3.3.8 specifically targets.
Why these
Sign-in stands between people and the thing they came for, so every decision is about removing steps without removing safety. These entries cover recovery, error specificity and the WCAG requirements that apply specifically to authentication.
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
Every system has irreducible complexity. The only question is whether the user absorbs it or the product does.
LAW·005
Better than a good error message is a design in which the error cannot occur.
HEUR·005
People spend most of their time on other products, so they expect yours to work the way those do.
LAW·003
The craft decisions
The visual and structural foundations that carry most of the weight on this surface.
Difference is what makes anything perceivable, and it is measurable for text against its background.
FND·002
Using size, weight, colour and space to make the structure of text visible before it is read.
FND·032
A fixed set of spacing values, so every gap in the product comes from the same vocabulary.
FND·042
Patterns to reach for
Solutions people already recognise, with the conditions under which each one earns its place.
Checking input at the right moment, which is rarely while the user is still typing.
PAT·007
Say what happened, why if you know, and what to do next, in that order and in plain language.
WRT·002
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
A persistent message tied to a context, which is where anything requiring action belongs.
CMP·015
Accessibility requirements
Not a separate pass. These are the requirements this surface raises, mapped to the decisions that produce them.
Every input needs a persistent label, and format requirements must be stated before the user types.
A11Y·017
Errors must be identified in text, described specifically, and accompanied by a suggested fix where one is known.
A11Y·016
Everything must be operable with a keyboard alone, which is the single most load-bearing accessibility requirement.
A11Y·002
What assistive technology announces for a control, which must match what a user would call it.
A11Y·008
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
Voice is who you are and stays constant. Tone is how you speak in a moment and must change with the situation.
WRT·003
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
Measuring progression through a sequence, where the largest drop is rarely the biggest opportunity.
RES·011
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.
A review pass for any form, covering structure, labelling, validation, errors and accessibility.
CHK·001
A practical WCAG 2.2 AA review pass, ordered so the checks that find the most problems come first.
CHK·002
Accounts, teams, permissions, billing and the surfaces every SaaS product needs and few design well.
CHK·007
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 feature specification that covers states, edge cases and accessibility rather than only the happy path.
TPL·011
Decisions other teams made
Worked cases, including the options that were rejected and why.
A payments product added security badges and lost conversion, then recovered it by removing them and explaining what actually happens to the money.
CASE·002
A retailer required registration before purchase to build its customer database, and lost the sales it was trying to capture data about.
CASE·001
Designing something else?
Neighbouring territory. Each surface reuses much of the same material, arranged around the decisions that surface turns on.