Test prototype usability by watching likely users attempt a realistic task without immediately explaining the intended method. State the goal, observe what happens and record where help becomes necessary. The purpose is to find problems in the design, not to grade the participant or prove the founder’s idea is good.
Choose a task that matters
Pick a task central to the proposed value: finding a suitable option, setting up a product, completing a booking sequence or organizing an item. Avoid a task selected only because the prototype makes it look impressive. Write the real-world situation that gives the task a reason.
Use neutral instructions. “Prepare this case for a short work trip” leaves room to observe interpretation. “Open the blue flap and place the charger underneath” teaches the action and hides whether the design communicates it.
Recruit people with relevant circumstances
Participants should resemble actual or likely users in the characteristics that affect the task. Familiarity with the problem, physical access needs, device use and working context may matter. Do not rely solely on colleagues who already know how the prototype was designed.
The GOV.UK research guidance describes moderated usability observation and participant recruitment. Use its principles as a method resource, rather than importing government-service participant counts or operating rules as universal requirements for every startup.
Prepare a small observation record
| Record | Why it matters |
|---|---|
| Task and prototype version | Makes the conditions repeatable |
| Relevant participant context | Explains what the observation may apply to |
| Actions and hesitations | Preserves behavior before interpretation |
| Assistance | Separates independent completion from coaching |
| Observed outcome | Shows what was actually completed |
| Possible explanation | Keeps your hypothesis distinct from evidence |
Collect only information needed for the research. Explain the session, obtain appropriate agreement and ask separately about recording. Use suitable arrangements for accessibility and privacy. Participants should know they can stop without needing to defend their decision.
Let silence produce evidence
Founders often jump in when a participant hesitates. Wait long enough to understand what they are trying to do, unless continuing would create a problem. Ask neutral prompts such as “What are you looking for?” instead of naming the intended control.
If you intervene, record the exact assistance and why. A successfully completed task after several hints can still provide useful learning, but it should not be reported as an independent success. Do not quietly revise the task halfway through a session to make the prototype appear easier.
Hypothetical example: opening a travel case
Suppose five relevant adults try an illustrative travel-organizer prototype. Three look for a zipper on the wrong side. Two find the closure independently. After the observer points toward a fabric tab, the other three complete the opening task.
The finding is that three participants needed assistance under the observed conditions. It is not evidence that sixty percent of the entire market will fail. The repeated behavior suggests a concrete design question: does the closure’s placement or visual treatment mislead users?
The founder revises the tab and observes another relevant group using the new version. Keep the results by version rather than mixing them into a single reassuring total. A design change should have its own question and observation record.
Review behavior before asking for opinions
After the task, ask what the participant expected and what felt unclear. Their explanation may help interpret the action, but it should not replace the behavior record. Someone can say the prototype is attractive while being unable to use its main function.
Separate usability from demand and technical reliability. A person completing a task does not establish willingness to pay, long-term durability or safe production performance. Those questions need suitable additional evidence.
Turn findings into a bounded revision
Group observations by the affected task and consequence. A blockage preventing completion deserves a different response from a minor preference. Choose a revision that addresses the observed mechanism rather than redesigning every surface because one participant suggested a favorite color.
Keep a short list of unresolved questions and note where the prototype’s limitations affected the session. A simulated step, missing component or unusually quiet room may make the task easier than real use. Testing should reveal these boundaries rather than bury them.
Consider learning between tasks. A participant who discovers the closure in the first exercise may perform the second easily because of that experience. Preserve task order in the notes and avoid presenting a later familiar attempt as evidence of first-use clarity.
Session checklist
- The task is believable and central to the offer.
- Participants have relevant context.
- Instructions do not reveal the solution.
- Assistance is documented rather than forgotten.
- Behavior and interpretation occupy separate notes.
- Findings stay tied to version and conditions.
- The next revision targets an observed issue.
