Stop leading the horse to water: how to get honest feedback on prototypes

Stop leading the horse to water: how to get honest feedback on prototypes

You put a prototype in front of a customer. They hesitate.

“The button’s just there,” you say. “That takes you to the next step.”

They click it. The rest of the journey goes smoothly. At the end, they tell you it looks good.

It feels like a successful test. But you have just tested whether someone can follow your instructions, not whether they can use your product.

For product managers, that distinction matters. A prototype session should reveal where the experience works, where it breaks, and what people expect. If you keep leading the horse to water, you never learn whether the route makes sense without you.

Give someone a realistic goal. Watch them attempt it. Ask questions that help you understand their experience without supplying the answer.

Give them a destination, not directions

Start with something your intended customer actually needs to achieve. Recruit people who recognise that situation, rather than relying only on colleagues who already know the product.

Imagine you are testing a booking prototype.

A leading task would be:

“Open My Bookings, select your appointment, click Reschedule, and choose Friday.”

You have named the controls, explained the structure, and provided the route. There is very little left to discover.

A better task would be:

“You can no longer attend your appointment on Thursday. Use this service to arrange a Friday afternoon appointment instead.”

Now you can see where they start, what they look for, and whether they recognise that the change is complete.

This is the distinction in Nielsen Norman Group’s guidance on task scenarios: make the activity realistic and actionable without giving away how to use the interface.

Before the session, define success privately. In this example, the appointment has moved to an available Friday afternoon slot and the participant understands the new booking. Clicking the button you expected is not the success criterion.

Make it safe to struggle

People can feel as though they are the ones being tested. They may apologise when they cannot find something or try to give you the positive reaction they think you want.

Set expectations plainly:

“We’re testing the prototype, not you. Some parts may be incomplete. Please approach this as you normally would and tell me what you’re thinking. You can pause or stop whenever you want.”

Ask permission before recording. Use fictional account details rather than asking someone to enter sensitive information into a prototype.

Explain necessary limitations without demonstrating the route you want to test. If a control is genuinely broken or unimplemented, record that separately. A missing prototype interaction is not automatically evidence that the design is confusing.

Then let them begin.

Watch what happens before you explain it

The hardest part is often staying quiet.

You know why the screen looks that way. You know what the label means. You can see the next step. But explaining those things changes the evidence you are collecting.

Watch for:

• Where they look or click first.
• Labels they reread or interpret differently.
• Repeated clicks, backtracking, and abandoned routes.
• Moments when they ask for reassurance.
• Whether they recognise completion or keep searching.
• Comments about uncertainty, effort, or frustration.

Record what happened, not just your interpretation.

“Opened the appointment details twice, returned to the home screen, and said ‘I don’t know whether that saved’” is more useful than “User was confused.”

A pause does not automatically mean frustration. Someone might be reading carefully, considering a choice, or thinking about something outside the task. Treat body language as a reason to investigate, not proof of an emotion.

If they say they are frustrated, capture their words. If you suspect it, ask neutrally rather than putting the feeling in their mouth.

Ask questions that do not contain the answer

Non-leading questions leave room for an explanation you did not anticipate.

Instead of:

“Was the reschedule button hard to find?”

Ask:

“What were you looking for at that point?”

Instead of:

“Did that confirmation message reassure you?”

Ask:

“What do you think has happened now?”

Instead of:

“Would a bigger button make this easier?”

Ask:

“What, if anything, made that step difficult?”

Instead of:

“You looked frustrated. Was it the menu?”

Ask:

“How was that part of the task for you?”

Useful follow-ups include “What were you expecting?” and “Can you tell me more about that?” Repeat their own wording when it helps: “You said ‘risky’. What felt risky?”

Even an open question can steer attention. Pointing at a control and asking what it does tells the participant that the control deserves attention. During the task, avoid introducing interface elements they have not noticed. Save targeted questions for the debrief where possible.

As Nielsen Norman Group explains in its guide to leading questions, your wording can shape both the answer and the participant’s subsequent behaviour.

Do not rescue too early—or turn silence into a test of endurance

When someone asks, “Am I supposed to click this?”, immediately saying yes removes the uncertainty you wanted to understand.

A neutral response might be:

“What would you do if you were using this on your own?”

Then give them space. Do not interrupt every pause with another question. Constant commentary can change how someone approaches the task.

But neutrality does not mean leaving someone stuck indefinitely. If they want to stop, are distressed, or cannot progress, move on. You can also provide limited help to explore a later part of the journey.

Record exactly where you intervened and what you said. Keep completed independently, completed with help, and not completed separate. An assisted finish can still teach you something; it should not be reported as independent success.

Turn observations into product decisions

Consider this illustrative booking session:

The participant finds the right appointment but opens “Cancel” while looking for a way to change it. They back out, try another route, and eventually ask for help.

In the debrief, you ask:

“What were you expecting when you opened Cancel?”

They explain that they thought they would have to cancel before booking another time.

That gives you an expectation to investigate, not an automatic instruction to build a cancellation-first journey.

Separate your notes into:

• Observed: opened Cancel while trying to move the appointment.
• Said: expected to cancel before rebooking.
• Interpretation: the current change-booking route may not match their expectations.
• Next test: make the option to change an appointment easier to discover and test it with fresh participants.

Look across sessions for recurring problems, but also consider consequence. A single observed risk of losing a booking may deserve attention even if other participants avoid it. Small qualitative studies reveal issues; they do not establish how common those issues are across your whole customer base.

Remember what this test cannot tell you

Someone completing a task does not prove they need the product, will pay for it, or will return next week.

A usability test helps you understand whether people can use the experience. Product discovery also needs evidence about whether the underlying problem matters. Ask about recent real situations, existing workarounds, and what people currently spend time or money doing—not just whether they would hypothetically use your idea.

For your next prototype session, write the customer’s goal before writing the questions. Remove instructions that reveal the route. Decide what success looks like, then leave room for the participant to surprise you.

If the prototype only works when you explain it, your explanation is part of the product. Your customers will not have that part.