Prototyping & UI/UX Requirements

Why Prototype?

18 min Lesson 1 of 10

Why Prototype?

You have spent weeks eliciting requirements, drawing use-case diagrams, modelling data, and producing a detailed specification. Stakeholders have signed off on it. You feel confident that everyone understands what is being built. Then the first working screens appear — and a senior stakeholder says, "That is not what I meant at all."

This moment, distressingly common in software projects, is the core problem that prototyping solves. A prototype is a tangible, low-cost representation of the proposed system — made early enough that changing it is cheap. Its singular purpose as an analysis tool is to validate requirements before a single line of production code is written. This lesson explains why that matters, how the feedback loop works, and what the analyst's role is in driving it.

The Fundamental Problem: Requirements Are Abstract

Requirements documents — even excellent ones — describe systems using words and diagrams. Words are ambiguous. Diagrams represent logical relationships, not visual experience. Most stakeholders are not trained to read a use-case diagram or a DFD and mentally simulate the system they will actually use every day. They are domain experts: a clinic receptionist, a warehouse supervisor, a finance manager. When you show them text that says "the system shall allow a user to filter appointments by date range, status, and clinician," they nod — because they cannot yet imagine the dozen interaction details that make that filter either a joy or a nightmare to use.

A prototype makes the abstract concrete. It transforms "filter appointments" into actual drop-downs, date pickers, and a result list that the receptionist can click through. The moment the receptionist interacts with it, they discover requirements they could not have articulated in a requirements workshop: "I need to see the appointment count next to each status filter." "The date picker should default to this week, not today." "I need to clear all filters with a single button." None of those requirements were in the SRS — not because they were overlooked by a poor analyst, but because they are requirements that can only be surfaced by experience.

Core insight: Prototyping does not replace requirements engineering — it completes it. A prototype is the last stage of requirements elicitation, the stage that surfaces the requirements that cannot be expressed until something tangible exists to react to.

The Cost of Change Curve

The economic argument for prototyping rests on a well-documented principle in software engineering: the cost of fixing a requirements defect rises dramatically the later it is discovered. A requirement misunderstood during analysis costs minutes to fix in a document. The same misunderstanding discovered during user acceptance testing costs days of rework — redesigning screens, rewriting business logic, re-testing affected modules. Discovered after go-live, it may cost weeks and damage user trust that takes months to rebuild.

Prototyping deliberately moves discovery left on the timeline. A low-fidelity prototype can be built in hours. Stakeholder feedback can be gathered in a single session. Changes cost a few minutes with a drawing tool or a simple HTML file. The prototype has no production dependencies, no database schema constraints, no deployment pipeline to traverse. It is the cheapest possible vehicle for discovering requirement gaps.

Cost of fixing a requirements defect versus the stage at which it is discovered. Prototyping deliberately moves discovery to the cheapest point on the curve.

What Prototyping Validates

A prototype is not simply a UI demo. When used rigorously as an analysis tool, it validates requirements across several dimensions:

Completeness. Are there use cases the SRS describes but the prototype reveals as logically incomplete? For a clinic booking system, a prototype of the "reschedule appointment" flow might reveal that the SRS never specified what happens when all alternative slots are full — a gap invisible in text but obvious when a user clicks "Reschedule" and hits a dead end.
Correctness. Does the proposed interaction match how the domain actually works? An online store's checkout prototype might expose that the analyst modelled "apply discount code" as a final step, but the merchandising team applies it before tax is calculated — a business rule that was in a policy document no one shared during workshops.
Feasibility of user interface requirements. Some requirements are technically implementable but practically unusable. A prototype surfaces these early. If a logistics manager must enter 12 fields before submitting a shipment, that is technically possible — but the prototype session will immediately surface that usability requirement for a "quick-entry" shortcut.
Priority and scope alignment. Stakeholders often disagree on what is essential. Walking them through a prototype makes trade-offs tangible: "If we include this advanced filter, the simpler summary screen must be deferred to phase two. Which do you want first?" Abstract priority discussions become concrete screen-level decisions.

The Prototype-Feedback Cycle

Prototyping is not a single event — it is a disciplined cycle. The analyst builds a prototype, presents it to stakeholders, collects structured feedback, updates the requirements, revises the prototype, and repeats. Each iteration tightens the gap between what was specified and what stakeholders actually need. Knowing when to stop is as important as knowing how to run the cycle: when no new requirements surface in a session, the prototype has done its job.

The prototype-feedback cycle: each iteration reduces requirement gaps. The cycle exits when no new issues surface, signalling that requirements are ready to baseline and design can begin.

A Concrete Example: Online Grocery Store

An e-commerce team analysed requirements for an online grocery store. The SRS stated: "The system shall allow customers to add items to a shopping cart, view the cart, and proceed to checkout." Clear, well-formed, and — as a prototype revealed — critically incomplete.

During the first prototype session, five new requirements surfaced within 30 minutes:

A customer must see the estimated delivery window before adding items, not just at checkout — because they will not order if the slot is unsuitable.
Out-of-stock items should remain visible in the cart with a "Notify me" option, not silently disappear.
Customers frequently order the same items each week; a "Repeat last order" button was considered essential by six of the eight test participants.
The minimum order value rule must be displayed inline as the cart total updates, not only surfaced as an error at checkout.
For customers with dietary restrictions, the cart should warn when a newly added item conflicts with a stored dietary profile.

None of these requirements appeared in the SRS. All were discovered in one 30-minute prototype session. Building a production implementation of the original SRS and then surfacing these gaps during UAT would have cost weeks of rework across multiple components.

Analyst practice: Before each prototype session, prepare a brief structured observation guide: which tasks will you ask participants to attempt, what specific decision points are you trying to validate, and what SRS sections are most at risk. Unfocused prototype sessions produce vague feedback. Structured sessions produce actionable requirement updates.

Prototyping and the Analyst Role

It is worth being precise about what the analyst's job is in the prototyping phase. The analyst is not a UI designer; they are not trying to produce beautiful screens. They are using the prototype as a communication and validation instrument. The quality standard is not visual polish — it is fidelity to the requirement under test. A rough wireframe that accurately represents the proposed interaction logic is more valuable than a polished mockup that obscures ambiguities behind attractive styling.

The analyst also owns the feedback loop: capturing feedback in structured notes, mapping each piece of feedback to a specific SRS requirement (adding, modifying, or confirming it), and maintaining the requirements change log. Every session should end with a brief written summary that states: which requirements were confirmed, which were modified, which new requirements were added, and what will change in the next prototype iteration.

Prototype scope creep: Prototype sessions frequently generate wish-list suggestions that go beyond the agreed project scope. It is the analyst\'s responsibility to distinguish between a genuine gap in the specified requirements and a new feature request that belongs in a future release backlog. Both are valuable — but they must be tracked separately and handled through the change-control process, not silently incorporated into the prototype.

Summary

Prototyping solves the core problem that requirements are abstract and stakeholders cannot fully evaluate them until something tangible exists.
The cost of fixing a requirements defect rises steeply the later it is discovered; prototyping moves discovery to the cheapest point — before any production code is written.
A prototype validates requirement completeness, correctness, UI feasibility, and priority alignment.
The prototype-feedback cycle is iterative: build, present, collect feedback, update requirements, revise, and repeat until no new issues surface.
The analyst\'s role is not visual design — it is structured validation: mapping every piece of feedback to specific SRS requirements and maintaining the requirements change log.
Prototype sessions must be structured with clear observation goals; unfocused sessions produce vague feedback that is difficult to act on.