Validate Requirements With a Prototype — Requirements Engineering, Part 7
- Shawn West
- Jul 28
- 7 min read
Updated: Aug 17
Requirements Engineering · Part 7
People are unreliable at reacting to a description and reliable at reacting to something they can click. That gap is the entire case for prototyping: it converts an opinion about a document into evidence about behaviour, at a point where changing your mind is still cheap.
This tutorial runs one validation cycle in under a week. For where prototyping sits among the elicitation instruments — and what it's blind to — see requirements elicitation techniques that work. This is the running of it.
Illustrative composite continuing the support-tooling example from Parts 1–6. Figures are illustrative, not measured.
Before You Start
The requirement lines you intend to test, pulled from Part 4's traceability matrix. This walkthrough tests REQ-006 (at-risk refunds sort first) and REQ-007 (at-risk rows show hours remaining). If you can't name the requirement a screen tests, you're not ready to pick a fidelity.
Part 6's workshop output — decisions with owners. Prototype requirements that have been decided. Building a screen around a collision that's still open tests your guess, not the requirement.
Production-shaped data before you build. Sixty to ninety refund rows, in the shape the queue actually holds. Get the export or a screenshot from Dana's team first. Eight rows makes everything discoverable and quietly deletes the problem you're testing.
Five to eight participants booked, at least three from outside the product team. Real agents from the support floor. Recruiting real users takes days, so start the outreach before you start building — the build is 1–3 days and the scheduling is usually longer.
A clean block per session: about 30 minutes to run, plus writing time immediately after. Plus one day at the end for synthesis. Sessions back-to-back with no gap produce notes you can't count later.
A prototype tool that produces a real click-through, and the participant's consent to record or a second person taking notes. You cannot run the session and capture behaviour at the same time.
What You'll Build
A low-fidelity prototype that tests 3–5 requirements against 5–8 real users, and a findings note that changes specific requirement lines.
Step 1: Pick the Fidelity Deliberately (10 min)
Fidelity | Good for | Fails because |
Paper sketch | Testing a concept or an information hierarchy | Too abstract for flow or ordering questions |
Clickable wireframe | Flows, ordering, discoverability — most requirement validation | Won't surface anything about speed or real data volume |
Styled mockup | Comprehension and language, late-stage | People start reviewing the visual design instead |
Code prototype | Genuinely novel interactions, performance questions | Expensive enough that you'll defend it instead of changing it |
We used a clickable wireframe: three screens, realistic refund data, no styling. The rule that keeps this honest is that fidelity should stop where your question stops. We were testing whether at-risk refunds get noticed — polish would only have added noise.
Check: you can name the requirement each screen tests. A screen testing nothing is a screen you built because it felt incomplete without it.
Step 2: Build Only the Critical Flow (1–3 days)
Three to five screens, connected, with realistic placeholder data. Skip polish and edge cases.
Realistic data matters more than it sounds. Our first version had eight refunds on screen; the real queue holds sixty to ninety on a Monday. With eight rows, everything is findable and every test passes — the prototype had accidentally removed the problem it was built to test.
Check: your placeholder data matches production volume and shape. Lorem-ipsum quantities produce lorem-ipsum findings.
Step 3: Recruit 5–8 Real Users (1 day)
Five to eight gets you most of the available insight — this follows Jakob Nielsen's long-standing usability-testing guidance that a handful of participants surfaces the large majority of problems in a given design (Nielsen Norman Group, "Why You Only Need to Test with 5 Users"). Recruit across experience levels, and use actual users rather than colleagues wherever you can.
The decision you'll face: real users are slow to schedule; internal staff are available this afternoon. Internal staff know the domain, the vocabulary, and often the roadmap — they cannot un-know it, and their fluency is exactly what you're trying to test for. If you must use them, use the newest hires, and mark the finding as weaker evidence.
Check: at least five sessions booked, at least three with people who don't work on this product.
Step 4: Write Tasks as Goals (30 min)
Task 1: It's Monday morning. Start your day on the refund queue.
Task 2: You have twenty minutes before a meeting. Decide what to do first.
Task 3: A customer emails asking where their refund is. Find it.
Note what these do not say. Not "use the at-risk section," not "click the sort control." The moment you name the feature, you've told them the answer and the test measures nothing.
Task 1 is deliberately open. If the ordering works, the at-risk refunds handle themselves without anyone being told they exist.
Check: no task names a control, a label, or a feature. Read them aloud — anything containing a noun from your own UI needs rewriting.
Step 5: Run the Session Without Helping (~30 min each)
"Thanks for joining. We're testing the prototype, not you — if
something's confusing that's a finding, not a mistake. Please think
out loud: what you're looking for, what you expect, what surprises you.
I'll mostly stay quiet."
Then don't help. When they're stuck, count to ten. The struggle is the data, and rescuing them destroys the only measurement you came for. If they ask "what should I click?", return it: "what would you try?"
Check: your longest silence was at least ten seconds. If you never had one, you were guiding.
Step 6: Read Behaviour, Not Praise (during)
Record what they do:
Where do they hesitate, and for how long?
What do they click that isn't clickable?
What word do they say for the thing you named differently?
What do they scroll past without seeing?
Here is the finding that mattered. Six of eight said the new queue was "much better." Five of those six never used the at-risk group — they scrolled past it and worked top-to-bottom by date, exactly as before. The feature was visible, praised, and unused.
The praise was real; it just wasn't about the ordering. They liked the cleaner rows. Had we recorded reactions instead of behaviour, we'd have shipped a validated failure.
Check: for each requirement you're testing, you have a count of users who behaved as it intends — not a count who liked it. If your notes contain only opinions, the session measured satisfaction, not the requirement.
Step 7: Synthesize by Pattern (1 day)
## Findings — refund queue prototype (8 users)
Behaviour
- 5/8 never engaged the at-risk group; worked top-to-bottom by date
- 8/8 completed "find a specific refund" via search, not the queue
- 3/8 asked what "at risk" meant before acting on it
Quotes
- "At risk of what?" (U2, U5, U7)
- "I assumed the top one was oldest." (U4)
Surprise
- 4/8 expected overdue items to be red. Nothing in the design was.
Patterns across users are signal; a single strong reaction is a hypothesis.
Check: every finding has a count attached. "Users seemed confused" is unactionable; "3/8 asked what at-risk meant" changes a label.
Step 8: Change the Requirement Lines (varies)
Findings that don't alter a requirement were entertainment. Ours:
REQ-006 At-risk refunds sort first
KEEP ordering rule unchanged
ADD at-risk group carries a heading with an explicit deadline
("Breaching today"), not a styling difference alone
ADD overdue rows use the established error colour (4/8 expected it)
REQ-007 At-risk rows show hours remaining
CHANGE from "6h remaining" to "breaches 14:00 today" —
3/8 mis-read relative time as elapsed, not remaining
The ordering was right. The signalling was wrong, and no amount of document review would have found it — everyone who read the spec already knew what "at risk" meant.
Check: each accepted finding maps to a specific requirement line added, changed, or explicitly rejected with a reason.
Step 9: Re-Test the Changes (varies)
Update the prototype, run two or three more sessions, confirm the fix. Ours: 3/3 used the at-risk group unprompted once it had a deadline heading.
Check: the behaviour changed, not just the reaction. Same measurement as before, or you've validated your own optimism.
You're Done When
Every finding in your synthesis carries a count out of the number of participants — 5/8, 3/8, 4/8 — and no requirement changed on the strength of a quote alone.
REQ-006 and REQ-007 read differently in the matrix than they did before you started, and each accepted finding maps to a specific line added, changed, or explicitly rejected.
Your re-test round shows the behaviour moved, not the opinion: participants used the changed design unprompted, and you have the count to show it.
If This Goes Wrong
Everyone praises it and you can't tell whether it worked. Stop reading comments and go back through your notes requirement by requirement, counting how many participants completed the task using the thing you built. Report that count, not the reaction. Six of eight calling it "much better" is compatible with five of them never touching the feature.
A participant stalls and turns to you for help. Hold the silence, then ask "what would you do if I weren't here?" and stop talking again. Do not point, do not name the control. If you did rescue them, mark that task as void in your notes rather than counting it.
Three sessions produce identical, frictionless results. Don't book more of the same — re-read your task wording first. A task that names a control or a label has already given the answer, and you're measuring reading. Rewrite it as a goal and re-run.
The prototype data got thinned to make the build faster. Pause the remaining sessions and reload to production volume before running another. Findings from eight rows don't transfer to ninety, and re-running is cheaper than shipping the wrong conclusion.
One participant reacts strongly and you want to act on it. Don't change the requirement line. Log it as a hypothesis with the participant ID attached, and write a task for the next round that tests it. A single reaction earns a test; a pattern earns a change.
Common Failure Modes
Counting praise. "Six of eight liked it" is a satisfaction score, not evidence the requirement works.
Unrealistic data. Eight rows where production has ninety removes the problem you're testing.
Helping. Every rescue deletes a data point and replaces it with your own knowledge of the design.
Tasks that name the feature. You've given them the answer and measured their reading comprehension.
Internal users only. They know too much, and the thing you're testing is whether someone who doesn't know can succeed.
Cherry-picking. The negative findings are the entire return on the exercise.
Continue the Requirements Engineering path
Part of the Requirements Engineering learning path.
