01 — Orientation
Designing for someone
The core shift in this whole guide is small to say and hard to do: you are not the user. What feels obvious to you, the person who built it, is often opaque to the person meeting it for the first time. Good design closes that gap. It starts from a real person, in a real context, trying to do a real thing, and works backwards to the interface.
The curse of knowledge
Design is a service
02 — Audience
Know who you are designing for
Before flows or screens, get specific about who this is for and what they are trying to achieve. Vague audiences produce vague products. You do not need a research department; you need a clear, honest picture you can point at when you make decisions.
Who
The person
Described by what they are trying to do, not by demographics alone. “Someone booking their first appointment” beats “25 to 40, urban”.
Context
Where they meet it
Where and how they meet the product. On a phone, in a hurry, on poor signal, one-handed, distracted. Context shapes everything.
Goal
What they actually want
The outcome they actually want. People rarely want your feature; they want the result on the other side of it.
Barriers
What stands in the way
Confusion, effort, doubt, cost, time. Design removes barriers between the person and their goal.
03 — Research
The cheap methods that win
Research sounds expensive. The most useful kinds are not. Talking to five people, or watching them use the thing, will surface more than a month of internal debate. The goal is not certainty; it is to be less wrong than you were, cheaply and often.
Ask: interviews
Watch: observation
Count: analytics
Compare: light testing
Figure 01 — The research landscape
The research landscape
Methods sit on two axes: what people say against what they do, and qualitative depth against quantitative scale. No single method covers the map. Pair one that tells you why with one that tells you how many.
04 — Flows
Flows and journeys
A screen is a moment; a flow is the path. Most real problems live between screens, in the joins: the step that assumes knowledge the person does not have, the dead end with no way back, the loop that never resolves. Map the path before you polish the pixels.
Task flow
One job, start to finish
The steps to complete one job, including the branches. Where does it fork, and does each fork have a way home?
Journey
The wider arc
The wider arc across sessions and channels: first hearing of it, first use, becoming a regular. Slower, and often where loyalty is won or lost.
Happy path
When everything goes right
The clean route when everything goes right. Design it first, then design what happens when it does not.
Edge and error
Most of real use
Empty states, failures, no signal, wrong input. These are not rare corners; they are most of real use. Design them on purpose.
Figure 02 — A user flow
A user flow
A single task drawn as a path. Decisions branch, and every branch resolves: a failure routes to recovery rather than a dead end. Drawing it this plainly exposes the gaps a screen-by-screen view hides.
05 — Drop-off
Where people fall off
Every step you ask someone to take loses some of them. This is not failure; it is physics. The work is to see where the loss is steepest, decide whether that step earns its cost, and remove the ones that do not.
Count the steps
Find the cliff
Question every gate
Measure, then move
Figure 03 — Reading a drop-off
Reading a drop-off
Where people fall off, stage by stage
The same funnel, stage by stage, with the loss at each step named. The steepest single drop is the first place to look. A view like this turns a vague sense that “people leave” into a specific step to fix.
06 — Usability
The working principles
Usability is not a matter of taste. Decades of study have produced a short list of heuristics: rules of thumb that catch most problems before a user ever sees them. They are a checklist you can run against any screen in ten minutes.
Status
Show status
The system always tells the person what is happening: loading, saved, sent, failed. Silence breeds doubt.
Language
Speak their language
Words, icons, and order that match the person’s world, not the internal database. No jargon leaking through.
Exit
Offer a way out
Clear undo, back, and cancel. People explore more freely when mistakes are cheap to reverse.
Consistent
Be consistent
The same thing looks and behaves the same way everywhere. Novelty in the chrome is a cost, not a delight.
Prevent
Prevent errors
The best error message is the one designed out. Constrain inputs, confirm the destructive, default to safe.
Figure 04 — Ten heuristics
Ten heuristics
The classic ten, as a scannable checklist. Run any screen against them in a few minutes: each one you fail is a concrete, nameable fix, not a vague sense that something is off.
07 — Accessibility
The full range of people
Accessibility is not a special case bolted on at the end. It is designing for the actual range of people who will use the thing: those with low vision, limited motor control, hearing loss, or simply a cracked screen in bright sun. Design that works at the edges works better for everyone.
Perceivable
Everyone can sense it
Sufficient contrast, text that scales, alternatives for images, captions for audio.
Operable
Everyone can drive it
Full keyboard use, generous targets, no reliance on precise timing or a single input.
Understandable
Everyone can follow it
Plain language, predictable behaviour, errors that explain how to fix themselves.
Robust
It holds up
It works with assistive technology: clean, standard markup that a screen reader can actually parse.
Figure 05 — The four principles
The four principles
Perceivable, operable, understandable, robust: the frame beneath the standard. Most access failures fall cleanly into one of the four, which makes them easier to find and easier to assign.
08 — Testing
Prototyping and testing cheaply
You do not need a finished product to learn whether a design works. A rough prototype, or even a sketch, put in front of five people, will tell you most of what you need to know while it is still cheap to change. Test early, test rough, test often.
Rough is fine
Five is enough
Watch, don't lead
09 — Acting
From findings to changes
Research and testing produce a pile of observations. The skill is turning that pile into a short, ordered list of changes, without drowning in it or cherry-picking the findings that suit the plan you already had. Not every problem is worth fixing now.
Group
Cluster into themes
Cluster raw observations into themes. Ten notes about the same confusing label are one problem, not ten.
Severity
Rate severity
How badly does it hurt the person, and how often? A rare annoyance and a frequent blocker are not the same job.
Effort
Weigh effort
What will the fix cost to build? Cheap and high-impact goes first; expensive and marginal waits.
Decide
Fix now, soon, watch, or log
Say it out loud so the team acts on the same list, not private hunches.
Figure 06 — Sorting what to fix
Sorting what to fix
Frequency → rare to common
Severity against frequency. A problem that is both severe and common is not a matter of debate; it is next. The grid turns a long, flat list of issues into an order of operations.
10 — Traps
Common traps
Some mistakes recur so often they are worth naming, so you can catch them in yourself. Most are versions of the same root error: designing for the person you imagine, or for the business, rather than for the person actually there.
Designing for yourself
Listening to words over actions
Adding to solve
Dark patterns
11 — First actions
The A–Z
A checklist to start from. None of it needs permission or budget; all of it can begin on the thing you are working on now.
A
The person
Write down who the person is by what they are trying to do.
B
The goal
Name the goal on the far side of your feature.
C
Five people
Talk to five real people about the last time they did the task.
D
Watch
Give someone the task and watch, without helping.
E
The flow
Map the flow, including every branch and dead end.
F
Least confident user
Walk it as your least confident user.
G
Count steps
Count the steps; cut the ones that do not earn their cost.
H
Steepest drop-off
Find the steepest drop-off and fix that step first.
I
Ten heuristics
Run every screen against the ten heuristics.
J
Contrast & keyboard
Check contrast, keyboard use, and scaling text.
K
WCAG version
Confirm the current WCAG version before a client commitment.
L
Prototype rough
Prototype rough; do not polish before you test.
M
Group findings
Group findings into themes, not a hundred loose notes.
N
Rate them
Rate each by severity and frequency.
O
Order the fixes
Order the fixes; decide fix-now, soon, watch, or log.
P
Design the states
Design the empty, error, and loading states on purpose.
Q
Undo first
Add an undo before you add a confirmation dialog.
R
Remove first
Remove before you add.
S
No dark patterns
Refuse dark patterns, even when they would work.
T
Re-test
Re-test after the change; keep or revert on evidence.
— Closing
One thing to carry
If you keep only one idea from this guide, keep this: the person you are designing for is not you, and the only reliable way to learn what they need is to watch them try. Everything else, the flows, the heuristics, the standards, is scaffolding around that single, humbling act of paying attention.