Useful user testing with a prototype comes down to one discipline: hand the thing over, say almost nothing, and watch what people do before they tell you what they think. Five to eight participants, one at a time, thirty to forty-five minutes each, with a fixed list of tasks and no explanation from you, will surface most of the usability problems in a design. The prototype does not have to be finished or even functional — it has to be real enough that behavior is genuine.

The prototype is a learning tool, not a demo

Founders instinctively run these sessions as sales pitches. That instinct destroys the data. The point is not to hear that your product is clever; it is to find out where a stranger hesitates, grips it wrong, misses a control, or gives up. Every confusion you catch at this stage costs a sketch to fix. The same confusion caught after tooling costs a mold revision.

Rule one: do not explain

Put the prototype on the table and give a task, not instructions. "Please turn it on and set it to the highest setting." Then stay quiet. Count silently to ten before intervening; the pauses are the finding. If you catch yourself saying "you just have to press and hold," you have just written that sentence into your product manual and lost the observation. Note where you wanted to speak — that list is your redesign backlog.

What to actually observe

  • First contact. Which way up do they hold it? Where do their fingers land before they have read anything? That tells you where controls belong.
  • Time to first success. Seconds to complete the primary task, unaided.
  • Errors and recoveries. What they do wrong, and whether they can tell they did something wrong.
  • Grip, reach, and effort. Wrist angles, thumb reach, force needed, whether they need a second hand. Physical findings here connect directly to ergonomics in product design.
  • Language. The words they use for parts and actions. Adopt their vocabulary in your labels and your marketing.
  • Abandonment. The exact moment someone stops trying.

Record the session if participants consent — a phone on a stand pointed at their hands is enough. You will see things live that you missed, and vice versa.

Questions to avoid

Certain questions reliably produce useless answers:

  • "Do you like it?" — people are polite, especially to the person who made it.
  • "Would you buy this?" — stated purchase intent is close to worthless. If you need a demand signal, run a landing page preorder test instead, where people spend money or attention.
  • "How much would you pay?" — ask it in a pricing study, not a usability session.
  • Leading questions: "that grip feels comfortable, right?"

Better prompts are backward-looking and specific: "Walk me through what you expected to happen there." "When did you last have this problem, and what did you do?" "What would you have done if I were not in the room?"

How many participants

For usability findings, five to eight people per round catches the large majority of problems, and the curve flattens fast after that. Two rounds of six with a redesign between them teaches far more than one round of twelve. What matters more than count is fit: participants must resemble real users. Testing a contractor tool on your friends produces confident, wrong conclusions. If you need quantitative preference data or statistical confidence, that is a different study with a much larger sample.

Which prototype do you need?

Match fidelity to the question. A foam or printed product mockup with no electronics answers questions about size, grip, and where controls should be. A functional rig with exposed wiring answers questions about interaction and feedback. Trying to do both at once is usually a waste — our comparison of looks-like versus works-like prototypes explains why splitting them is cheaper. For hand-fit and comfort specifically, a set of ergonomic test models in several sizes teaches you more than one refined unit.

Running the session

  1. Write three to five tasks in advance, ordered from the primary use case outward. Use the same tasks with everyone so you can compare.
  2. Brief the participant on their role: think aloud, there are no wrong answers, you are testing the product and not them.
  3. Have a second person take notes so the facilitator can stay present. Note timestamps, not conclusions.
  4. Test somewhere resembling the real environment — standing, noisy, gloved, dim, whatever applies.
  5. Save your questions for the end, after observation is complete.

Turning results into decisions

Immediately after each session, write your three biggest surprises. At the end of the round, group findings by cause rather than by participant: three people fumbling the same latch is one problem, not three. Then sort by severity times frequency and decide what changes now, what changes later, and what you consciously accept. Feed the accepted changes into the design documentation so nothing gets lost between rounds. Once the design stabilizes, testing shifts in character — longer, unsupervised, and in the field — which is the subject of beta testing a hardware product. For where all of this sits in the broader build sequence, see our prototype development guide.

Need models built for testing?

Projects House builds test-ready prototypes — multiple hand sizes, swappable controls, functional rigs — designed specifically so a session produces answers rather than compliments. Tell us through the contact form what you need to learn, and we will propose the cheapest prototype that can teach it.