A prototype helps most when it is still allowed to change.
Concept of the week · Learn while the design is still soft
A prototype is valuable because it makes an idea tangible. But tangibility alone does not tell you whether the flow will hold up when someone meets it without the team’s context. Inside the team, shared understanding fills gaps too easily, so weak decisions quietly turn into extra explanation, hidden checks, and late rework.
So we use prototypes to make ideas tangible, then test them with real users while the design is still easy to change.
A team is redesigning the workflow for changing an infusion rate on a bedside infusion pump. They build a clickable prototype and run two internal rounds with engineering, safety, and clinical specialists. The larger logic gaps disappear quickly, so confidence rises.
Then they run the first moderated sessions with Intensive Care Unit (ICU) nurses.
One nurse pauses at the handoff between the current and new rates. Another looks for a missing trend cue. A third reads the confirmation screen as a final lock, not as a state that can still be edited.
What looked smooth in review turns into pauses, re-reading, reassurance seeking, and uncertainty about whether the pump has already committed to the new rate.
None of these breakdowns looked serious in the conference room, because everyone there already knew how the flow was supposed to work.
Five lightweight sessions surface the real friction: interpretation, sequence, and trust.
The same pattern appears in software. An admin console, onboarding flow, or setup wizard can feel obvious to the people who built it, yet create extra verification steps, manual lookups, and avoidable hesitation for people meeting it cold.
Every unclear interaction adds rework, retraining, and another verification path.
One thing to remember: Every untested interaction ships hidden work.
How teams ship this: Version the prototype, task set, and severity notes together. After each round, fix only the few breakdowns that most affect comprehension, trust, or task flow, then test again with the next small group.
Asset & resource
First-Round Usability Test Pack
A lightweight pack for early testing when the goal is not to prove the design, but to see where it still breaks under first contact. Keep it small enough to prepare quickly, clear enough to compare across sessions, and structured enough to turn observations into the next design changes.
Task list
Write 3–5 realistic tasks that reflect what the user is actually trying to get done, not what the interface is trying to show.Neutral moderator script
Use a short introduction and a few neutral prompts to guide the session without teaching the flow.Observation grid
Capture where people pause, backtrack, misread state, ask for reassurance, or create their own workaround.Severity log
Mark each issue by impact, frequency, and recoverability so the next round focuses on the breakdowns that matter most.Round summary
End each round with the top three findings, the design changes made, and the open questions that still need another test.
Rocket Surgery Made Easy by Steve Krug
is still one of the clearest guides to keeping early usability testing small, practical, and repeatable.
Light wisdom & reflection
“Testing one user is 100 percent better than testing none.”
Where in your current concept is the team still protecting premature confidence by talking about the design instead of watching someone try it?
Mindful practice
Think of one moment this week when you explained something too quickly because it already made sense to you.
What would change if you let one person try first, without your rescue?
Notice what your urge to explain is protecting.
Best,
Andreas Walden
Share this with someone designing for clarity.
Bonus chapter · AI can free up time to test more
In medical device work, early formative evaluations help teams find and fix usability problems while change is still possible. Later validation work serves a different purpose: showing that intended users can use the device safely and effectively.
That distinction matters when teams add artificial intelligence (AI) to the workflow.
AI can help with more than clerical tasks. It can draft moderator guides, clean up transcripts, cluster observations, compare rounds, identify repeated breakdowns, and suggest patterns that warrant closer inspection.
But it should not replace contact with users or turn partial evidence into false certainty.
The point is not to let AI decide what matters. The point is to reduce the drag between rounds so teams can stay closer to the work: test earlier, synthesize faster, and return with a better version while the design is still easy to change.
So we can let AI help structure the material and propose insights, but raw observations, severity judgments, risk decisions, and final conclusions still need human review and a clear link back to the original sessions.
That trade is worth protecting. In early rounds, the real advantage of AI is more chances to learn from users before the concept hardens.
