A prototype review is more useful when the team observes how people interact with the sample before proposing fixes. Watching where a user pauses, asks for help, or handles a component differently than expected gives the team concrete questions to test, rather than relying only on opinions after the activity.
Key takeawaysDecide what question the prototype is meant to answer before the session. · Observe actions and context, then separate observations from interpretations. · Avoid coaching the user unless assistance is part of the intended activity. · Turn feedback into a specific revision or a documented decision to retain the design. · Keep the sample and revision status linked to the review notes. [1]
A prototype can look convincing in a meeting while still being confusing in use. A short observation session helps a team learn whether the activity flow, component labels, instructions, and package make sense to someone who did not design them. The purpose is not to prove a marketing claim or generalize from a few observations; it is to identify questions that deserve more design attention.
Before the session, decide what the sample is supposed to demonstrate. One prototype may test the order of steps, while another may test component size or package organization. Knowing the question helps the team avoid changing unrelated details simply because a reviewer has a personal preference.
Set a narrow observation question
Choose one or two questions that can be observed directly. For example: can a user find the first component without help, can the instructions be followed in order, or can a group return all pieces to the package? Avoid a broad prompt such as ‘Do you like it?’ because the answer may not explain what should change. The session should match the sample's development stage and should not ask users to evaluate features the prototype cannot yet represent.
Describe the setting and materials before the session. If the activity is intended for a classroom, note the group size and preparation; if it is for home use, include the package opening and cleanup. These context factors shape the observation. Child development varies, and a small informal session cannot establish how all children will respond. Treat observations as design input, not as proof of a developmental effect. [2]
Record what happened without coaching
During the session, write down actions and words as neutrally as possible. ‘The user asked which piece to pick up’ is more useful than ‘the instruction was bad’ because it preserves the observation while leaving room to investigate the cause. Note where the user paused, repeated a step, used a component unexpectedly, or asked for assistance. If assistance is part of the intended use, record when and why it was needed.
Avoid correcting the user too quickly. If the team explains the step at the first hesitation, it may hide the point where the product stopped communicating clearly. A facilitator can step in for safety or wellbeing, but should record that intervention. The objective is not to make a participant fail; it is to understand how the prototype communicates before the team decides whether a revision is warranted.
Separate observation, interpretation, and decision
After the session, divide notes into three columns: what was observed, what the team thinks it may mean, and what decision or test should follow. An observation might be that two users swapped the same pieces; an interpretation could be that color distinction was unclear; a next step might be to test labels or layout. This structure prevents an early guess from becoming an unexamined design requirement.
Product design connects user needs, function, and form, but a prototype session is only one source of evidence. A proposed change should be checked against the brief, safety requirements, manufacturing feasibility, and other user feedback. For teams evaluating K&M OEM/ODM solutions, a well-documented observation log can help explain why a design change is requested and what the next sample should demonstrate.
Choose the next sample decision deliberately
A review can lead to several valid decisions: revise the design, gather more information, test an alternative, or keep the current version. State the reason and the owner for whichever path is chosen. If the issue involves a component, material, instruction, or package, note which documents will change and whether a new sample or specialist review is needed.
Do not keep revising a prototype without a question. Each revision should test a defined change or close a specific uncertainty. Otherwise the team may spend time polishing details that do not affect the user or product requirements. Keep a dated record of the sample, observations, decisions, and next review so the buyer and supplier can understand why the current version differs from the last one.
Respect privacy and participant needs
If children participate, obtain appropriate permission and follow the organization's procedures for supervision, privacy, and recording. Do not collect personal information that is unnecessary for the product question. A session should be comfortable and age-appropriate; the participant should be able to stop. The team's interest in design feedback does not override a caregiver's or organization's requirements.
Keep any notes or media in the agreed project location and limit access to people who need it. Summarize patterns without identifying participants. A small session can reveal friction, but it should not be used to make broad claims about all users or to promise educational outcomes. The responsible conclusion is usually narrower: what the team observed, what it plans to change, and what still needs review.
Sources
Frequently asked questions
How many people should test a prototype?
The appropriate number depends on the question and stage. Informal sessions can surface usability questions, but they do not replace formal evaluation or establish broad outcomes.
Should the facilitator explain a confusing step?
Intervene when needed for safety or comfort. Otherwise, record the hesitation first so the team can learn where instructions or design may need clarification.
Does user feedback automatically require a design change?
No. Compare the observation with the brief, safety, feasibility, and other evidence, then document the decision and rationale.