Project: Prototype a Key Screen Flow
Project: Prototype a Key Screen Flow
Everything in this tutorial has built toward this moment. You know why prototypes exist, how to choose the right fidelity level, what wireframes look like, and how to evaluate them with real users. Now you do it. This lesson walks you through a complete, end-to-end project: select a critical flow, wireframe each screen, annotate UI requirements, and produce a deliverable that a development team can act on.
The scenario used throughout is a logistics dispatch portal — a web application used by dispatch coordinators at a freight company to assign drivers to delivery orders. This is a high-frequency, time-pressured workflow; errors in the interface directly cause missed deliveries and customer complaints. It is exactly the kind of flow where prototyping earns its keep.
Step 1 — Identify the Critical Flow
Not every flow deserves a full prototype. Prioritise flows that are high frequency (used many times per day), high risk (errors have serious consequences), or high contention (stakeholders disagree on how they should work). In the logistics portal, the "Assign Driver to Order" flow scores high on all three. Every coordinator uses it dozens of times a shift; a wrong assignment wastes a journey; operations management and dispatch coordinators have different ideas about how order information should be presented.
Define the flow boundaries precisely before you draw a single box:
- Entry point: Coordinator opens the unassigned-orders queue.
- Happy path end: Driver is assigned; order status updates to "Dispatched"; coordinator sees a confirmation toast.
- Alternate paths: No drivers available; selected driver is over capacity; coordinator cancels mid-flow.
- Out of scope for this prototype: Creating a new order, driver profile editing, GPS tracking view.
Step 2 — Wireframe Each Screen in the Flow
A wireframe captures structure and content hierarchy, not colour or styling. Use grayscale fills, placeholder text, and labelled controls. For each screen, ask: what information does the user need to see to make a decision, and what actions can they take? The answers become your layout.
The "Assign Driver" flow involves three screens: the Unassigned Orders Queue, the Driver Selection Panel (a modal or side-drawer), and the Assignment Confirmation. The wireframe below illustrates all three in one composite view.
Step 3 — Annotate UI Requirements
A wireframe without annotations is a picture; with annotations it becomes a requirement specification. For each screen and each significant control, write a numbered UI requirement in plain language. These feed directly into the SRS UI section and into developer acceptance criteria.
Example annotation set for the Driver Selection Panel (Screen 2):
UI-REQ-NNN) that matches identifiers in your SRS. This makes traceability from prototype annotation to test case trivial.
Step 4 — Document Alternate Paths
The happy path is only half the story. For each alternate path you scoped in Step 1, add a screen or state to the wireframe and corresponding UI requirements. For the logistics portal, two alternates matter:
- No available drivers: Screen 2 shows an empty list with an inline message — "No drivers available for this route at this time. Retry in 5 minutes or escalate to Operations." A wireframe of this empty state is as important as the populated state.
- Coordinator cancels mid-flow: A "Cancel" button on Screen 2 returns the order to the queue without any state change. UI-REQ-017 must specify that no partial assignment is persisted.
Step 5 — The UI Requirements Traceability Matrix
Every UI requirement derived from the prototype must trace back to a functional requirement in the SRS and forward to at least one test case. The matrix below shows a sample slice.
Step 6 — Present, Iterate, and Sign Off
Run a structured walkthrough session with stakeholders. Walk them through each screen in the flow using the think-aloud protocol: ask them to narrate what they would do at each step and what they expect to happen. Do not lead them — if they hesitate at the Driver Selection Panel, that hesitation is data. Capture every comment against a screen number and UI-REQ ID.
After the session, categorise feedback into three buckets:
- Critical: The prototype does not support the task. Revise the wireframe and re-test.
- Important: The design is confusing or inefficient. Update the wireframe and the corresponding UI requirement.
- Minor: Wording, label preferences, cosmetic suggestions. Log for visual design phase; do not re-prototype.
Repeat until no critical or important issues remain. Then obtain formal sign-off: a dated sign-off record attached to the prototype document, listing stakeholder names, roles, and any outstanding deferred items. This sign-off is your mandate to hand the UI requirements to the development team.
The Complete Analyst Deliverable
At the end of this project, your deliverable package contains: (1) the annotated wireframe file (PDF or shared tool link), (2) the numbered UI requirements list, (3) the traceability matrix linking each UI-REQ to a source FR and target test case, (4) session notes from stakeholder walkthroughs, and (5) the signed approval record. Together these artefacts transform a concept into a specification that a development team can implement, a QA team can verify, and a project manager can track. That is the analyst's craft, completed.