Requirements Gathering Techniques

Prototyping as Elicitation

18 min Lesson 8 of 10

Prototyping as Elicitation

There is a well-established phenomenon in requirements work: stakeholders often do not know what they want until they can see and touch something that is almost right. Words on paper — even carefully crafted user stories — describe a future system in the abstract. A prototype makes that future tangible in minutes. It provokes reactions, triggers memories of forgotten edge cases, and surfaces conflicting assumptions before a single line of production code has been written.

Prototyping as elicitation is not about building a working system early. It is about creating the cheapest possible artefact that sparks the right conversation. Used well, a prototype is a question, not an answer.

Why Prototyping Surfaces Hidden Requirements

Consider a logistics firm whose dispatchers currently juggle phone calls, whiteboards, and spreadsheets to assign drivers to routes. An analyst interviews the lead dispatcher for two hours and produces a tidy set of user stories. Yet when the analyst shows a low-fidelity wireframe of the proposed dispatch screen, the dispatcher immediately says: "Where is the colour coding for driver availability? And how do I flag a high-priority delivery?" Neither detail appeared in the interview. The prototype made the dispatcher mentally step into the workflow and compare it against their ingrained practice — something abstract conversation rarely achieves.

This is the tacit-knowledge trigger effect. Experts carry subconscious rules they cannot articulate on demand. Seeing a concrete representation of their work activates the procedural memory that verbal questioning cannot reach.

Key idea: A prototype is a requirements elicitation instrument first and a design artefact second. Its primary purpose is to generate feedback — especially the corrections, objections, and "what about…?" questions — not to demonstrate what the final UI will look like.

Types of Prototype

The right prototype type depends on the elicitation goal, the audience, and how much time is available. Analysts commonly use four forms:

Paper prototypes — hand-drawn sketches of screens on paper or sticky notes, arranged on a table or whiteboard. Extremely cheap: a 10-screen paper prototype of a clinic booking system can be produced in under two hours. Stakeholders are less inhibited giving feedback on obviously rough sketches than on polished wireframes because it feels safe to suggest changes.
Low-fidelity digital wireframes — greyscale, unstyled screen layouts produced with tools such as Balsamiq or Figma in wireframe mode. Communicate structure and navigation without implying final visual design. Suitable for workshops, remote sessions, and formal review cycles.
High-fidelity interactive mockups — pixel-perfect, clickable prototypes that simulate the real application closely. Useful late in elicitation when fine-grained details (exact field labels, error states, micro-interactions) are being validated. Risk: stakeholders often assume the software is nearly done and become resistant to changes.
Wizard-of-Oz prototypes — the UI looks real but a human operator (the "wizard") manually performs the back-end processing behind the scenes. Used to test AI-driven or complex algorithmic features before any algorithm is built. A logistics firm wanting to pilot a route-optimisation assistant might show drivers a realistic chat interface while an analyst manually calculates the routes in another window.

The four prototype types arranged by fidelity and typical elicitation stage — start cheap and early, increase detail only when feedback stabilises.

The Prototyping Elicitation Cycle

Effective prototype-based elicitation is iterative, not linear. The analyst does not produce a prototype, collect comments, and move on. Instead, the cycle repeats until requirements are stable:

Scope the prototype. Decide which slice of the system to model. For an online store, you might prototype only the checkout flow — the highest-risk, most-contested area — not the entire site.
Build quickly. Paper or low-fi wireframes can be ready in a single afternoon. Resist perfecting the artefact; imperfection invites feedback.
Conduct structured walkthroughs. Present the prototype scenario-by-scenario, not feature-by-feature. "Imagine you are a registered patient who wants to reschedule a same-day appointment" keeps stakeholders in their user context rather than in design-review mode.
Capture reactions, not just requests. Note what confuses users, what makes them hesitate, and what they ignore — not only what they explicitly ask for. A stakeholder who skips a confirmation screen without reading it may be telling you the interaction design is wrong.
Update the prototype and the requirements log. Each round of feedback produces refined screens and new or amended requirements entries. The prototype and the requirements document evolve together.
Validate and freeze. When successive walkthroughs produce no new requirements and only minor layout preferences, requirements in scope are considered elicited. The prototype is then retired or handed to UI designers as a reference.

The six-step prototyping elicitation cycle — repeat steps 2–5 until consecutive walkthroughs produce no new requirements.

Throwaway vs. Evolutionary Prototypes

Analysts must agree with the project sponsor on one critical question before building any prototype: will this prototype be thrown away, or will it evolve into the final product?

Throwaway (exploratory) prototyping — the prototype exists only to generate feedback. Once requirements are stable, it is discarded and the system is built properly from scratch. This approach is almost always correct for elicitation: speed matters more than code quality, and production code built to prototype standards is typically a maintenance nightmare. The online-store team builds a Balsamiq checkout flow in a day, runs three feedback sessions, captures 14 new requirements, then discards the wireframes and starts the real implementation.
Evolutionary prototyping — the prototype is incrementally refined and eventually becomes the production system. Appropriate only when requirements are genuinely stable and quality standards are enforced from the start. Dangerous when used as justification for skipping proper requirements documentation.

Critical pitfall — prototype lock-in: When stakeholders see a high-fidelity prototype, they often assume development is nearly complete and resist the idea that major requirements can still change. This "prototype lock-in" can suppress exactly the feedback you need. Always set expectations explicitly: "This is a visual conversation tool, not the real system. Nothing here is built yet. Your job is to find everything wrong with it."

Facilitating a Prototype Walkthrough

The walkthrough session is where elicitation happens. Preparation and facilitation technique matter enormously:

Prepare realistic scenarios. For a clinic booking system, write scenarios like: "A patient calls to cancel a same-day appointment and rebook for next week." This forces the stakeholder to mentally enact their real workflow rather than evaluate the UI in the abstract.
Ask for predictions before actions. Before the user clicks anything, ask: "What do you expect to happen when you press Confirm?" Mismatched expectations reveal requirement gaps instantly.
Use the "think aloud" technique. Ask stakeholders to narrate their thoughts as they move through the prototype. Silence often means confusion — follow up with "What were you thinking there?"
Record, do not rely on memory. A second analyst should take notes or — with permission — record the session. Feedback comes fast; critical insights are easily lost in real time.
Timebox. A single prototype review session should last no longer than 90 minutes. Fatigue sets in and quality of feedback drops sharply after that point.

Best practice: After each walkthrough session, immediately classify each piece of feedback into one of three buckets: (1) new requirement, (2) clarification of an existing requirement, or (3) design preference that does not affect requirements. Only the first two generate entries in the requirements log; design preferences stay in the prototype notes and are handed to the UI/UX team later.

Prototyping Trade-offs

Like every elicitation technique, prototyping has both strengths and genuine weaknesses:

Strengths: surfaces tacit knowledge that interviews miss; makes abstract system behaviour concrete and discussable; catches requirements errors early when they are cheapest to fix; builds shared understanding and stakeholder buy-in; particularly powerful for UI-heavy systems (booking apps, dashboards, e-commerce flows).
Weaknesses: can focus disproportionate attention on UI aesthetics rather than business rules; stakeholders may anchor to the prototype design and resist better alternatives; non-UI requirements (batch processes, integration protocols, security constraints) are difficult to prototype; high-fidelity prototypes create false expectations of completion; consumes analyst and stakeholder time across multiple sessions.

Prototyping works best as a complement to other techniques. Use interviews to discover the broad scope of requirements, then prototype the highest-risk or most complex flows to validate and refine them. For a logistics route-assignment system, textual interviews might capture the business rules adequately — but the dispatch screen layout must be prototyped with the actual dispatchers, because the visual arrangement of information directly affects the speed and accuracy of their decisions.

Summary

Prototyping is an elicitation technique that surfaces tacit knowledge by making future system behaviour concrete and tangible.
Choose the prototype type (paper, low-fi, high-fi, Wizard-of-Oz) based on elicitation stage and the need to manage stakeholder expectations.
The elicitation cycle is iterative: scope, build, walkthrough, capture, update, validate — repeat until requirements stabilise.
Throwaway prototypes are almost always the right choice for elicitation; evolutionary prototypes carry significant risks.
Set explicit expectations: stakeholders must understand that a prototype is a question, not a commitment to a design.
Classify feedback immediately: new requirement, requirement clarification, or design preference only.