Usability testing of prototypes: where the scenario logic breaks
A mockup answers the question “what does it look like,” but not “will anyone be able to use it.” Interface usability problems almost always live not inside an individual screen but at the junctions: between a form and confirmation, between choosing an option and moving on, between an email and returning to the app.
Usability testing of prototypes is exactly about this: we give a person a task and watch where they stop, where they go off track, and at which step they abandon the path.
A typical defect is dead ends in the user flow. A button is active, but the next step isn’t provided for; a required field appears only after the form is submitted; going back a step erases what was entered.
A static mockup doesn’t show this: the screens are drawn, but the transition logic has never been walked through end to end.
Testing on a clickable prototype exposes such gaps in a single pass — before they turn into code and into late mockup revisions for an interface that’s already built.
A separate risk area is losing users during registration. Here the scenario is the longest and patience the shortest: an extra required question, an unclear password requirement, no hint when an error occurs — and the person leaves without ever reaching the product.
We record the exact step where the drop-off happens, how many steps they managed to complete, and what they were trying to do before leaving.
At the output, you get not general impressions but a list of specific points in the scenario prioritized by their impact on the share of users who reach the target action: what to fix in the prototype immediately and what can be deferred. Below, we break down how this works in practice.
The effect of early validation: fewer reworks, shorter approval cycle
Validation on a prototype catches precisely those classes of problems that cost an order of magnitude more in finished front-end markup: navigation dead ends, ambiguous button labels, lost form states, a mismatch between expectations and the actual logic of the steps.
Moving a block on a mockup is an hour’s work. The same fix after release turns into a separate task with tests, regression, and re-approval.
The dynamics across iterations are predictable. According to Nielsen Norman Group estimates, five participants uncover about 85% of interface problems — enough for the second run to no longer produce new classes of failures.
The number of design iterations drops from four to six down to two or three, and the mockup approval cycle shrinks from several weeks to a single review.
Contentious decisions are resolved along with arguments from the “it seems to me” category.
Instead, there is a session recording: four out of five participants did not find the needed section, three did not notice the transition to the next step, one lost entered data when going back. Such evidence closes the question once and does not return in the next round of discussions.
By the end of the validation, a short list remains of what actually needs to be changed, and it also becomes the basis for the project’s design system.
Design iterations stop going in circles: a fix is made once, confirmed by a repeat run with two or three participants, and goes into development together with the described scenario.
Fewer reworks in front-end markup, a shorter approval cycle, lower cost of late fixes — the effect of early validation holds throughout all further development.
Comparison of formats: moderated testing, hallway tests, remote sessions
The validation format is chosen based on the question that needs an answer.
If it is important to understand why a person cannot find a button and where the step logic breaks, moderation is needed: the facilitator asks clarifying questions during the session and drills down to the cause. If you need a “cold” reaction and speed, hallway tests work. When the audience is spread across cities and roles, remote sessions with screen recording help.
The formats do not replace but complement each other, so a research plan usually includes two of the three. On sample limitations: 5–8 people per segment reveal the class of the problem and its repeatability, but not percentages for the entire audience.
In the report, therefore, we write “4 out of 6 participants encountered the problem,” not “40% of users.”
| Format | When it fits | Limitations |
|---|---|---|
| Moderated testing | First prototype, contentious scenarios, need reasons for behavior rather than the fact itself | 40–60 minutes per participant plus recording analysis, sample limited to one city |
| Hallway tests | Quick validation of one hypothesis: is the screen clear, is the wording readable | Only surface-level reaction; a long scenario and underlying causes cannot be tested |
| Remote sessions with screen recording | Dispersed audience, narrow segments, testing on one’s own device | Depends on the participant’s connection and equipment; some nonverbal reactions are lost |
Bottom line: we start with a moderated run with 5–6 people, then cover contentious points with hallway tests on a larger number of participants.
Work stages: scenario outline, respondent recruitment, report
Until a prototype has gone through real users, scenario evaluation remains the team’s hypothesis. Below is the sequence we follow for usability research on a prototype: from testable hypotheses to handing results over to development and design.
- Task and hypothesis breakdown. We record which prototype decisions we are validating and what we consider a failure: the share of successful completions of the key path, the number of critical errors, time to first target action.
- Test scenarios. Each scenario is one user goal without hints in the wording, with an explicit entry point and a session stop criterion.
- Interview guide. A moderator script with neutral questions: the participant verbalizes expectations before clicking; we do not give hints or defend the interface.
- Respondent recruitment. Sampling by product criteria — role, experience, task frequency. We filter out those who have already seen the mockups: their answers are predictable and distort the picture.
- Running sessions. Screen and voice recording, notes with timestamps; a separate observer records where the participant gets stuck and what they do instead of the expected step.
- Analysis and handoff of results to the team. We sort errors by criticality — path-blocking, slowing, cosmetic — calculate frequency by participant, and deliver a prioritized list of fixes with recording excerpts.
Each stage ends with an artifact: scenarios, guide, and report remain with the team and serve as the basis for a repeat run after fixes.
Deliverables: report, problem map, validation protocol
Prototype testing ends not with a set of opinions but with a set of documents that the client’s team can work from without us.
Each artifact has its own consumer: the designer takes fix points from the problem map, the developer takes priorities, the project manager takes the dynamics across repeat validations.
- Usability testing report: scenarios, hypotheses, exactly what broke at each step and at which point participants stopped.
- Session recordings with timecodes: a link to the moment where a person did not find a button or hit a dead end — you can show a contentious situation without retelling it.
- Interface problem map: screen or block, defect class (navigation, wording, feedback), frequency of repetition across different participants.
- Prioritized list of fixes: what breaks the main scenario and is fixed before release, what goes into the next cycle, what we consciously close as contentious.
- Repeat validation protocol: which scenarios we recheck after fixes, on what sample, and by what criteria we consider a problem closed.
- Validation protocol template: a fixed format so the next validation does not begin with inventing the report structure.
We deliver artifacts in working formats — a spreadsheet for the problem map, a text document for the report, links to recordings with access for the team.
After fixes are made, we update the map: closed items are marked, remaining ones are carried over — you can see exactly what changed between iterations.
Case study: how mockup validation resolved contentious decisions before front-end markup
The client is a corporate user account service: before front-end markup, nine contentious navigation decisions had accumulated, which the team discussed on mockups without external data.
Instead of an internal vote, we assembled a clickable prototype in Figma and put it through usability testing with eight participants — existing clients with different levels of experience in the account area.
What we measured before fixes
Each participant went through five scenarios: service activation, document export, plan change, transaction history search, and support request. We recorded two metrics — scenario completion success without hints and task completion time.
On the original prototype, the scenario reached the end in 42% of attempts, the average task solution took about three minutes, and people mainly got lost in transitions between sections and could not find the return point.
What was confirmed and what was disproved
Of the nine contentious navigation decisions, five were confirmed: the duplicate menu, third-level nesting, and hidden filter in the transaction list did indeed hinder users.
Four were disproved — including removing the side panel and moving settings into a separate section: participants found them faster than the team had assumed.
What changed
After fixes to menu item descriptions and section structure, scenario completion success rose to 79%, and task completion time dropped to one and a half minutes.
The fixes were made in the mockup before front-end markup: the scope of interface work decreased by about a quarter because two sections and some states were no longer needed.
This usability testing case resolved the dispute even before development — no rework was required on the finished product.
What to do if the prototype has already been approved but fixes are expensive?
Late interface validation is still worthwhile: in an approved prototype there is no code yet, so fixing a scenario costs hours of mockup work rather than a release rework.
The cost of an error grows with every stage — what now looks like a dispute about one screen becomes rewritten forms, analytics, and automated tests around them in a finished product.
At this stage we do not run the entire product, but assemble a minimal sample — usually five people from target segments. As Jakob Nielsen shows, this is enough to catch most recurring problems: each subsequent participant brings new observations less and less often.
What matters more is not the size but the composition — a novice, an experienced user, someone who accesses from a phone.
Next is targeted validation of contentious screens: we take 3–5 scenarios with the highest cost of error (first order, registration, key form) and analyze them in detail. We leave the rest alone so as not to rebuild an approved scheme because of cosmetics.
We divide post-approval fixes into three classes. Texts and block order we make immediately: this is a mockup fix, not a logic fix. Form hierarchy and states — also via mockup.
We change the scenario only where the problem blocks completion of a step; everything else goes into the queue for the next iteration without delaying release.
At the output, the client receives a list of problems prioritized by impact on the result, not a “tester’s opinion”: it is clear what is mandatory before release, what can come after, and what we consciously accept as a limitation.
Common concerns: sample, stages, contentious decisions
Debates around prototype testing rarely concern the method — more often they discuss the boundaries of applicability: is it too early, will there be enough participants, what to do with already approved decisions. Below are answers to technical concerns that arise in almost every project.
The test checks not “do they like it” but scenario walkthrough: where the participant stops, what they search for longer than expected, at which step they abandon the task. This changes wording and structure before they go into development, so fixes remain inexpensive.
Can a clickable mockup be tested without visual design?
Yes. On screen diagrams it is already visible whether a person understands the structure: whether they find the needed section, whether they guess the purpose of a block, whether they go back after an error.
Only trust issues and readability are not tested — they are covered in the next iteration, when visual styling appears.
How many participants are needed for the conclusions to be valid?
For one type of task, 5–8 people are enough: by the fifth participant, new causes of failures almost stop appearing; the same two or three barriers repeat.
If the audience is divided into clear groups — for example, new and returning users — the sample size in the study is multiplied by the number of groups.
How much time do sessions take and what do you need from our side?
One session is 30–45 minutes; series run over two or three consecutive days. The full cycle: preparing the scenario and mockup, running sessions, analyzing recordings, and producing a prioritized report.
From your side, we need access to participants from the target audience and a person who will confirm the scenarios.
The decision has already been approved — will testing change anything?
The test does not revisit the decision but shows the cost of refining it.
A single barrier is removed with text or block order; if the scenario falls apart entirely, that is an argument to return to the structure now rather than after release, when rework affects front-end markup and logic.
We format the conclusions as a prioritized list of fixes and hand them over before programming begins — so the impact on development is limited to clarifying the structure rather than rewriting finished screens.Let’s discuss your task: what is needed to start validation
To discuss the task concretely and come back with a timeline estimate rather than general wording, we need a short set of inputs from you.
At this stage, the prototype can be either a clickable mockup or a rough build — what matters is that the main user paths, not individual screens, can be walked through on it.
- A link to the prototype and a brief product description: what the service is, who the user is, what task they solve.
- A list of scenarios or hypotheses to validate: whether the user finds the needed section, reaches checkout, understands error texts and hints.
- A target audience profile for participant recruitment: role, experience with similar products, interface language.
- Data on current behavior, if available: funnel, click map, support requests — these show which places to validate first.
- Constraints: deadlines, your side’s readiness to attend sessions as an observer, requirements for recording and storing materials.
- A point of contact on your side who makes decisions on contentious findings and approves the final report.
From this we assemble a validation work plan: how many sessions are needed per scenario, how we record observations, and where the boundary lies between an interface problem and a question about product logic.
We select the team composition for the scope — a session moderator and an analyst who reviews recordings and consolidates findings into a report prioritized by impact on key actions.
Describe the task in two or three paragraphs or send a link to the prototype — we will come back with a timeline estimate, work plan, and team composition for your scope.
