Look for the second click

A feature can do exactly what the spec said and still leave the person using it guessing.

That gap, between works as scoped and works in someone’s hands, is easiest to catch when the team sits with the build before it ships. User acceptance testing is the obvious moment. So is a sprint demo, a feature review, or an audit of something already live. Any time you look at the product as a user rather than as its builder.

First, a quick recall

From No. 01

A good problem statement has four parts. Type them from memory before you look back.

S G O S… W

Five principles, and what each looks like in the room

Each one catches a different kind of friction: the kind that is easy to feel and hard to name. They are in rough order of how often they turn up in a typical session.

Mental model match

Is this behaving how I’d expect?

People arrive with expectations built from every other interface they use. Save means save. Back undoes the last step. Submit asks first if it can’t be undone. Mismatches bite when your product behaves, or is labelled, differently from the tools people use every day.

Look for the surprise A small jolt of “wait, why did it do that?” Workarounds come later, once the surprise is absorbed. The broken expectation is the cleaner finding.

Look for the re-read A label, instruction or error message read twice. If the words don’t land during a calm review, they won’t land for a teacher between lessons.

Recognition over recall

Do I have to remember things across screens?

People should be able to see what to do from what is on the screen, not remember it from three steps ago. Recall costs pile up: a teacher switching between four screens, a student coming back to a quiz after the bell, an authoring flow with options spread across several steps.

Look for the back-click for context A tester goes back to check what they just entered, or copies something into another tab to refer to. The flow is asking their memory to carry what the interface should.

Visibility of system status

Did the system register that?

Every action should get a visible response. A click, a save, a submission: nobody should have to guess whether it went through. On slow school networks, missing feedback turns into duplicate submissions, lost work, or quiet abandonment.

Look for the second click Something is clicked, nothing visibly happens, and it is clicked again. Or the page is refreshed, or another tab is opened to check. The second click is the user filling in a status the system should have shown.

Information scent

Could I have found this on my own?

A label, link or menu item should give off enough signal that people know what is behind it before they try it. Weak scent turns a well-built feature into one nobody finds: generic labels, vague menu items, features filed under unrelated headings.

Look for the path that needs a guide A tester who had to be told where the feature lives, or a menu label that could mean three things. After each smooth completion, ask one tester to find the same feature from the home screen, unaided. If they can’t, the path needs work.

Error prevention

What happens if I make a mistake?

Destructive or irreversible actions should be hard to trigger by accident. Submitting an assignment, publishing a resource, deleting student work: once done, undoing them ranges from awkward to impossible.

Look for the action without friction An irreversible click that doesn’t ask. A destructive option next to a harmless one, styled the same. No undo. For each action of consequence, ask: what happens if someone does this by accident? If the answer is “they lose work”, the finding is real.

The second click is the user doing the system’s job for it.

After the session, log it so it travels

A finding is only useful if the team can act on it weeks later, when nobody remembers the room. Four lines is usually enough.

GoalWhat the person was trying to do: the outcome, not the click.

ExpectedWhat they expected to happen.

HappenedWhat the product did, in plain words.

ThenWhat they did next: re-read, was surprised, went back to check, clicked twice, worked around it, gave up, finished without comment.

“Finished without comment” belongs on that list. A smooth completion is a finding too, and it is the one most often left out.

Take this with you

Watch behaviour, not opinions: the surprise, the re-read, the back-click, the second click, the guided path.
For every action of consequence, ask what happens if someone does it by accident.
Log goal, expected, happened and then. If the finding can’t travel without you, it won’t travel.

“It works” is the spec talking. Watch someone use it before you believe it.

Try this week

Run a twenty-minute hallway review.

Pick one flow you shipped recently. Give a colleague who didn’t build it a goal, not instructions.
Say nothing. Tally each surprise, re-read, back-click and second click.
When they finish, ask them to find the same feature again from the home screen.
Log the top two findings in the four lines above, and send them to whoever owns the flow.

To mull over

Which of the five would your own product fail first, and how do you know?
Where does your product use a word differently from the tools your users use all day?
Which of your findings from the last review were really problem statements nobody had written yet?

Look for the second click.