User testing

You have a prototype. Now you will put it into the hands of real people and watch what happens. User testing is not about hearing whether people like what you made, but about seeing whether they can actually do what they need to — and where they stumble.

Set up a simple user test

You do not need a lab or equipment. You need someone from the target group, a task and a place to take notes. Surprisingly few tests reveal surprisingly much: already after a handful of users you see the same problems recur, and then you know what to fix.

Make a short plan: one to three realistic tasks the user will perform with the prototype. For Ingrid's packaging service the task could be "order a reusable crate and figure out how to send it back." Write the task as a goal, not as a recipe — do not give away the buttons they should press.

Observe behavior rather than asking for opinions

This is the core. Opinions are polite and unreliable; behavior is honest. Ask the user to think out loud as they try, and then keep quiet. The temptation to help when they get stuck is enormous — but it is exactly where they get stuck that you learn the most. Count to ten in silence before you intervene, if at all.

Avoid leading questions along the way. Not "wasn't that easy?", but "what are you thinking now?". When the user asks "what should I do here?", answer with "what would you do if I weren't here?". You are there to observe, not to rescue your prototype.

Measure whether people understand and complete the task

Decide in advance what counts as success. For each task, note:

• Did they complete it? Yes, partly or no.
• Where did they stumble? The exact step, and what they expected to happen.
• What did they say out loud? Ideally word for word, especially frustration and surprise.
• Did they understand it at all? Did they grasp what the service was and what to do?

A common shock is watching someone misunderstand something you thought was obvious. It is not that the user is slow — it is that the prototype is unclear. That insight is free now and expensive after launch.

Collect and prioritize feedback

After each test, write down the findings immediately, while they are fresh. Once you have tested a few people, look for patterns: problems that show up for several people matter more than one person's preference. Sort the findings by severity — what stopped the user completely, what annoyed them, what was a minor nitpick. You cannot fix everything; you fix what keeps people from succeeding.

Be careful about over-reading single voices. One person who loves or hates something is an anecdote; three who stumble in the same place are a pattern.

How many users do you need?

Fewer than you think. Even with around five users you catch most of the obvious problems, because the same stumbling blocks hit people again and again. Test often with a few rather than rarely with many — then you can fix things and test again.

Common mistakes to avoid

The most common mistake is talking too much: explaining, helping and defending instead of observing. Another is testing with the wrong people — friends who want you to succeed. A third is asking "did you like it?" at the end; then you get a polite yes that is worth nothing. Replace it with "what would you do next now?" and "what was the hardest part?". And remember: when a user struggles, it is never the user who is dumb. It is valuable information about your product.

Do this now

Find three people from the target group and give each of them one realistic task with the prototype. Make a simple observation sheet with the columns "completed the task," "where they stumbled" and "what they said." Keep quiet while they try, and note everything. Afterwards, circle the problems that recurred for more than one person — those are what you carry into the next lesson on iterating.