Ask five people whether they would use a site to pay for parking and five say yes. Ask when they last paid for parking and what they actually did, and one of them tells you she put coins in because the app wanted a card she did not have on her, which is a fact about a real evening rather than a prediction about a future one. That swap is the whole method. Ask when they last did it, not whether they would.
Everything else in this topic is that discipline applied at a larger size, and the size that matters is the task. The multi-storey in Aarhus has a payment site, Parkeo, and the task written for testing it reads: you have parked in bay 47 and you want to pay for two hours, starting on the home page, and stopping when you believe you have paid. Write the task with a starting point and a stop condition, and hand it over in exactly those words. Every part of that sentence is doing work. Without the starting point people begin where they last were. Without the stop condition they carry on until they think you look satisfied, which means the thing you measured was your own face.
The output is a decision, and it has no artefact
Every other topic in this pillar makes something you can open. This one makes a decision about what should exist, and its outputs, the notes and maps and wireframes, are working papers that get thrown away. That is why the seven clusters below look like a list of documents and are not: finding out, instead of assuming and deciding what goes where exist to settle arguments, and a document that settles nothing is a document nobody needed.
The order of the seven is the order in which each answer makes the next question answerable. What people are trying to do, then what things are called and where they live, then the sequence those things get touched in, then the cheapest possible drawing of that sequence, then a clickable version, then a stranger in front of it. Then round again, because the stranger changes the first answer.
Five people, one at a time, and you say almost nothing
The session is the piece of this topic that is a skill rather than a document, and it is short. Five people, one at a time, twenty minutes each, one task. Read the task aloud, then go quiet. The hard part is not the recruiting, it is the silence: a participant who stops moving will look up, and the reflex is to help, and helping ends the test. There is one sentence that gets you out of it without lying. Answer a question with what would you do if I were not here. They tell you, and that answer is the finding.
Parkeo went to five people on a Thursday. Four of the five typed the registration plate into a field that had been split into two boxes and lost the last two characters, because nothing in the design said the plate was in halves. Three of the five pressed the browser Back button at the confirmation screen, which never repeated the bay number, so they could not tell whether they had paid for bay 47 or for the bay above it. One gave up entirely. Nobody complained, and none of the five said the site was confusing, because people do not say that. They say sorry.
Count how many of the five hit it and how many got out. Two numbers, and together they are a severity: four hit the plate field and all four eventually got out, which is friction. Three hit the confirmation and one of them did not get out at all, which is a hole. Sorting a list of findings by those two numbers is the difference between a report and a decision, and it takes about ten minutes.
Write down what happened, not what to build
The discipline that keeps a finding useful for more than a week is to write the finding as what happened, not as what to build. Four of five lost the last two characters of the plate is a finding. Add validation to the plate field is a solution wearing a finding's clothes, and it closes off the three other repairs that would also work, one of which is not splitting the field. A finding written as an observation survives a change of platform, a change of team and a redesign. A finding written as a fix expires the moment somebody implements it badly.
The other half of the same discipline costs nothing and gets skipped by nearly everybody: run the whole flow with the mouse unplugged. Tab through Parkeo from the home page to the confirmation, and the two failures that show up are ordinary, which is the point. The bay selector cannot be reached at all, and the focus ring is invisible on the dark header, so a keyboard user is somewhere on the page and cannot tell where. That is designing for the people your defaults exclude, and unplugging the mouse is the cheapest ten minutes in this topic.
Five people, one Thursday
What five people can tell you, and what they cannot
Five is enough to find the holes and nowhere near enough to count anything, and reading it as a measurement is how a small test gets used to end an argument it never settled.
What five sessions know about Parkeo
- YesWhether the task can be finished at allOne of the five did not finish itYes
- YesWhere people stop, and in what wordsThe plate field and the confirmation screen, both on videoYes
- YesWhether a label is read the way it was meantWatching somebody read it beats asking whether it was clearYes
- NoHow many of your users hit the same thingFour of five is four people, not a proportion of anybodyNo
- NoWhether anyone would pay for itA room with a task in it is not a marketNo
- Not checkedWhether it works without a mouseAll five used one, so nobody lookedNot checked
The last row is the one this structure exists for. Filed under no, it would be claiming somebody tested keyboard use and it failed, which is a different fact with a different next action.
The stall is learning the documents and never running a session
This is where people in UX stop and do not notice. The artefacts are learnable from articles: a persona, a map, a wireframe, a flow. They can be produced convincingly by somebody who has never watched one stranger fail at anything, and they look like the work because in a portfolio they are the only part that photographs. The tell is precise. Go through a portfolio and look for one sentence that begins with a number of people out of another number. If it is not there, nobody has been watched, and every diagram in it is an assumption drawn neatly.
Running a session is not hard and it is not expensive. It is uncomfortable, which is a different problem and the reason it gets postponed. The first one is uncomfortable for about eleven minutes, which is roughly when the first participant does something you did not think was possible.
Taken backwards, you learn about a button
The reversal is the ordinary one in this pillar and it is worth naming exactly. Somebody draws screens, then builds a prototype, then tests it. The test then asks whether people can use the screens that exist, and the answer comes back about a button, a label, a colour. What it cannot tell you is whether the task those screens serve was the task anybody had. Parkeo tested that way would have produced a better plate field on a site that still makes you choose a bay number you have to walk back into the stairwell to read.
Wireframes before flows is the same fault one rung down: screens get drawn for steps the task does not contain, and they survive, because a drawn screen is harder to throw away than an undrawn one. The sequence of screens a task actually takes comes first for that reason, and structure agreed before anything gets styled is cheap only if it comes second.
What to open in 2026
Figma is where the clickable version gets made, and its free tier is enough for a five person test. It took that work from InVision, which shut its services down at the end of 2024, and the practical difference is that the prototype now lives in the same file as the screens rather than in a second service that goes out of date the moment somebody edits a frame. Something clickable, before anything is built is the cluster, and the fidelity question in it is the one that decides how much of this you build at all.
For the mechanical half of accessibility, axe DevTools is a free browser extension that finds the machine-checkable faults, which is a real fraction of them and never all of them. The standard behind it is WCAG 2.2, published in 2023, replacing WCAG 2.1 from 2018 as the version to write against. It is free to read, which is unusual for a standard and worth knowing, because a client asking for compliance is asking for a document you can both open.
What none of these settles is the thing a session is worst at: everything that happens before somebody arrives and after they leave. The five people in Aarhus were handed a task in a room. Nobody tested the version where it is raining, the ticket machine has a queue, and the site takes eleven seconds to load on a phone with one bar, and that last one is not a design problem at all, it is everything between a browser and a server. The next question after this page is which of those two your failures are really coming from, and whether people can actually use it is where the answer starts. What it looks like once the answer is settled is the surface people touch, and the rules that hold it together whatever it turns out to be are the principles that hold whatever you are designing.