A team shows someone a concept and asks whether they’d use it. The participant tries to help. They praise the idea, suggest features, explain what a colleague might want, and build a reasonable story about a future they haven’t experienced.
Nobody in that session has learned what people will actually do. What would they pause on before approving? Which source would they reopen? What would they correct? Asking for opinions can’t show that.
Feedback lives in the imagination
The participant hasn’t waited for the AI, trusted a recommendation, corrected a mistake, handed over control, or decided whether the result is safe to send. They’re reviewing the idea, not hiring the product.
Feedback is often sincere. It’s also cheap. The participant pays no cost for being optimistic. People are generally polite and will tell you what they think you want to hear.
A person can compliment the product and still have no intention of making room for it. They can say the positioning is sharp, the workflow is elegant, and the pain is real, then go straight back to the ugly workaround they were using before.
Reactions happen inside the job
A reaction appears when the product meets a real situation.
The user pauses before approving. Reopens the source. Smiles when a burden disappears. Copies the result into the old system “just in case.” Refuses to let the AI act. Corrects one phrase and immediately moves on. Asks whether the same thing works on another case.
Those behaviors expose trust, anxiety, relief, confusion, and ownership without requiring the participant to name them.
That’s why Knurture uses situational prototypes. The prototype doesn’t need every feature. It needs enough reality for the user to react as if the decision matters. What matters is that the participant feels like they’re interacting with something that would exist in the real world.
The prototype needs a situation, not a tour
Start with the trigger. Give the participant the same kind of account, document, image, workflow, or decision they would face at work. Include realistic constraints and imperfect information.
Then let the participant decide.
Fill-in table
Situational prototype
Give the participant enough reality to react as if the decision matters.
| Prototype | Decision to test |
|---|---|
| An AI recommendation | Make the user decide whether to follow it. |
| Automation | Show the scope and ask whether to approve. |
| A generated artifact | Make the person use it in the next step. |
| Positioning | See whether they can predict what the product does and who it’s for without explanation. |
Don’t narrate the value. Never tell the participant what they’re looking at or what to think. Ask them to describe what they see, in their own words, and let them encounter the value themselves.
The most useful moments often aren’t verbal
Fill-in table
Watch the silence
Record the moments that aren’t verbal and what each one can mean.
| Behavior | What it can mean |
|---|---|
| A long pause | Evaluation difficulty. |
| A second window opening | The product lacks proof. |
| Re-reading a sentence | The language carries risk. |
| Repeatedly hovering over undo | Low confidence, even when the participant says the feature feels safe. |
Ask what happened after the behavior, not before it.
- “What were you checking there?”
- “What made you hesitate?”
- “What did you expect to happen next?”
- “What would you need before using that?”
The question should help the participant interpret a real reaction, not invent a hypothetical preference.
When the participant asks you something, don’t answer. Reply with “Well, what do you think?” and let them talk it through. Their questions are data. If many participants ask the same one, it may mean something needs clarifying.
Example
An automation prototype
A participant tests an automation on the same kind of workflow they would face at work, with realistic constraints and imperfect information.
- Prototype: automation, on the same kind of workflow the participant would face at work, with realistic constraints and imperfect information.
- Decision to test: show the scope and ask whether to approve.
- Behavior: a long pause before approving, then repeated hovering over undo.
- What it can mean: the pause can mean evaluation difficulty. The hovering can reveal low confidence, even when the participant says the feature feels safe.
- Asked after the behavior: “What made you hesitate?” and “What would you need before using that?”
A prototype can fail beautifully
If users reject the level of autonomy, you’ve learned where the boundary belongs. If they can’t evaluate the output, you’ve found the missing evidence. If the framing attracts the wrong audience, the positioning is doing the wrong filtering. If they love the demo but won’t use the result, the product has not removed a burden.
Don’t optimize for approval. Positive feedback is dangerous when it comes from people who aren’t trying to switch. Feedback from people who aren’t trying to switch can waste time and pull the product toward their needs.
The session should make the next expensive decision cheaper, not prove the team right.
A clear “no” from a realistic situation is more valuable than enthusiastic feedback about a polished concept.
Run a reaction-first session
Before the session:
0 of 7 done
During the session, keep explanation minimal. Let the artifact carry the idea. Record what the participant does before asking why. Observe whether their actions align with their words.
Afterward, turn reactions into product decisions: change the scope, the evidence, the language, the first step, the permission model, or the frame.
