Why watch instead of ask
You know how your prototype is supposed to work, so you cannot see it fresh. Someone else can. Usability testing means watching people try to use a model, so you can see where they succeed, hesitate or get stuck. It is more reliable than asking “Do you like it?”, because people are polite and are poor at predicting their own behavior.
Testing does not need a lab. A table, a quiet room, a prototype and a notebook are enough. A few short sessions often reveal the most glaring problems, although a small group cannot tell you how everyone will behave, so treat results as guidance.
Safety before sessions
Never ask someone to test something that could injure them. Check the prototype yourself first: no live mains voltage, no exposed hot parts, no sharp edges, no unstable batteries. Keep to low voltage, and use cardboard or foam stand-ins for anything risky. If the real function cannot be tested safely, test the parts that can be, and describe the rest. Work in a ventilated space, and keep children away from small parts and from any test of an unfinished product.
What a prototype can test
Decide what question you are asking. Different models answer different questions:
- Rough models. Cardboard, foam or paper can test size, shape, grip and basic layout. They are cheap enough to modify between sessions.
- Working but unfinished models. A bench version with exposed wiring can test whether the function makes sense, but only with someone knowledgeable, and with safe supervision.
- Near-final versions. These test details, durability and finish.
Do not wait for polish. People often react more honestly to a rough model, because it looks changeable. Cardboard prototyping is useful for exactly this reason.
Plan the session
- Choose tasks, not features. Instead of “look at the buttons,” give a realistic job: “Please turn it on and set it to the lowest setting.”
- Write a short script. Include a greeting, a reminder that you are testing the design and not the person, the tasks, and a few closing questions.
- Recruit people like your users. Try for people who have not seen the project. Five to eight sessions is a typical size for a small test, though even two or three can be revealing.
- Prepare materials. The prototype, a pen, a notebook, a timer if needed, and permission to record if you want to.
During the test
Your job is to stay quiet and observe.
- Say little. Give the task and then stop. If they ask “How do I…?” reply, “What would you try?”
- Do not help too soon. It is hard to watch someone struggle, but their struggle is the data. If someone is truly stuck or in danger, step in.
- Ask them to think aloud. “Say what you are thinking as you go” gives insight into expectations. It can feel unnatural, so remind them gently.
- Do not defend. If someone says the design is confusing, thank them. Explaining why they are wrong teaches you nothing.
- Watch the hands and face. Hesitation, squinting, wrong buttons, repeated attempts and workarounds are all signals.
After the tasks, ask a few open questions: “What was easiest? What was most confusing? What would you change?” Ask about specific moments you noticed: “I saw you pause here. What were you thinking?”
Record what happens
Note what the person did, in order, with times if useful, and separate observation from interpretation. A simple table with columns for task, what happened, where they struggled and a severity guess works well. Photos or short videos are helpful if the person agrees, and you should keep recordings private.
Pay special attention to errors people make repeatedly, to mistakes that could be hazardous, and to tasks nobody could finish. These are signs of design problems more than user problems. If testers struggle to handle the object comfortably, revisit how it fits hands and bodies.
Turn observations into changes
After a few sessions, collect all the issues and sort them. Fix first what:
- Affects safety.
- Prevents users from completing a basic task.
- Many testers struggled with.
- Is cheap to fix.
Then change the prototype and test again. Resist fixing everything on the basis of one comment, and resist ignoring a pattern because it hurts your pride. Where testers misread instructions or labels, the problem may lie in the product instructions rather than the object.
Failure is part of the point. Learning from failure in a cheap test is far better than discovering the same problem after you have made a batch.
Pitfalls
- Testing only friends. They may be too kind or too familiar with your intent.
- Leading the tester. Pointing at the right button defeats the test.
- Asking only for opinions. Behavior is more reliable than preference.
- Testing too late. The earlier you test, the cheaper the changes.
- Treating a handful of sessions as proof. They show problems; they do not prove success.
A tiny test you can do today
Make a cardboard model, write down one task, hand it to a person with no explanation and watch for two minutes. Write down what you saw. Even that tiny exercise tends to uncover something you had not noticed, and it fits neatly into the wider design process of looping between building and learning.