Writing
Prototype and Validate Before You Build: An Eight-Stage Workflow
An eight-stage workflow that tests the design with real users before production code, then verifies the working software in UAT. What each stage produces, who approves it, when it’s done, and how to scale it down for small changes.
By Ka Lun Chan · Delivery / Engineering judgment
A lot of rework comes from building the right code for the wrong workflow. The feature passes review and ships, and then a real user gets stuck on step two. Fixing it takes new code, new tests and another deployment, for a problem a clickable mock-up could have shown in an afternoon.
Why prototype before production development?
Prototyping and testing a design with real users before writing production code finds workflow, wording and missing-step problems while they are still cheap to change. A screen in a prototype can be redrawn in minutes. The same mistake in shipped software costs code, tests, review, a deployment and sometimes a data migration.
The workflow below puts the cheap questions first. Whether people understand the design, whether they can finish the task and whether the business agrees it’s what it needs all get answered on a prototype. Questions that need real software, like whether the integrations hold up and whether permissions are enforced, get answered in development and user acceptance testing (UAT). Surprises are cheapest at the start, which is also why I pull delivery risk to the front once the build begins.
The workflow at a glance
There are eight stages in two phases. The first five work on requirements, flows and a prototype. The last three work on software. Between them is the gate that matters most: an agreed scope, based on a design real users have tried.
Fig. 728-1 Eight stages, two kinds of evidence. Production code starts only after scope is agreed on a tested design
Before production code: validate the design
- Define requirementsWho is it for, what must it do, and how will we know it worked?
- Map user flowsWhat path does each user take, including when something goes wrong?Side path: if feasibility could change the design, test that part now in a time-boxed spike.
- Build a prototypeWhat will people see at each step, with real content in it?
- Validate with users and stakeholdersCan real users finish the tasks, and does the business agree?Loop: stages 4 and 5 repeat until no critical issue is left. Retest only the flows that changed.
- Revise and agree on scopeWhat are we building, and what are we still unsure about?
Gate Scope agreed. Production code starts here.
On working software: verify the system
- DevelopDoes each increment match the validated design and its acceptance criteria?
- Run UATDoes the working system meet the business requirements with real integrations and data?Defects go back to stage 6. A workflow problem found here is the expensive kind the first phase exists to catch.
- Release and measureDo people use it the way testing suggested?What you learn becomes requirements for the next round.
The stages describe what has to be true before moving on. They don’t need to be eight meetings or eight documents. On a small team, stages 2 and 3 might be one working session, and stage 5 might be a short written decision in the ticket.
What is the difference between prototype validation and UAT?
Prototype validation tests whether people understand a design and can complete their tasks, before production code exists. User acceptance testing (UAT) tests whether the working software meets the business requirements end to end, with real integrations, permissions and data, usually in a staging environment. A prototype can’t replace UAT, and UAT is a costly place to discover the workflow was wrong.
| Prototype validation | UAT | |
|---|---|---|
| Question | Is this the right design for the task? | Does the built system do what the business agreed? |
| Tested on | Wireframes or a clickable prototype with realistic content | Working software in staging, with production-like configuration and data |
| Who tests | Representative users doing realistic tasks; stakeholders reviewing the flows | Business owners and the people who will use or support the system |
| Can verify | Navigation, wording, missing steps, task order, which states are needed, whether business rules were understood | Business rules as built, integrations, permissions, data handling, notifications, end-to-end behavior |
| Can’t verify | Performance, integrations, real data, security, whether permissions are enforced | Whether a different workflow would have been better, at least not cheaply |
| A failure means | Redrawing a screen or a flow | Changing code and tests, then deploying again |
Some risks only show up in working software, however well the prototype tested:
- Performance with real data volumes and real network conditions.
- Third-party integrations, including how they fail, time out and retry.
- Permissions enforced on the server. A prototype can show a button hidden from a role; only the built system shows whether the API refuses the request anyway.
- Data migration and data quality. Old records rarely match the clean examples in a prototype.
- Two people changing the same record at once.
- Email, SMS and push delivery.
- Device and browser differences, and screen-reader behavior. A prototype can check structure, labels and contrast, but assistive technology needs the real markup.
That list is why the workflow keeps UAT. Validating the design early shrinks what UAT has to find, so UAT can focus on the system.
The eight stages
Each stage lists its activities, deliverables, who takes part and who approves. “Starts when” gives the entry criteria. The “Done when” checklist doubles as the exit criteria, so one stage’s checklist is roughly the next stage’s entry check.
1. Define requirements
Flagging assumptions is the step teams skip. “Users already have an account” and “managers approve every request” sound like facts until a user test proves otherwise. Writing them down turns them into things stage 4 can check.
- Activities
- Identify the target users and the main tasks they need to finish. Write down business rules, constraints (budget, deadline, regulation, existing systems) and how success will be measured.
- Deliverables
- A one- or two-page requirements brief with success criteria, a list of assumptions, and the open questions with an owner for each.
- Who takes part
- Product owner, a designer, a tech lead, and someone who knows the users well, such as support or operations.
- Who approves
- The product owner, or whoever owns the budget and the outcome.
- Starts when
- Someone can describe the problem and who has it. A solution isn’t required yet.
Done when
- Each user group is named, along with the main task it needs to finish.
- Success criteria are measurable, such as task completion in testing, time to finish, fewer support requests, or adoption after launch.
- Business rules and constraints are written down where everyone can find them.
- Assumptions are labeled as assumptions, and each open question has an owner.
2. Map user flows
Error paths are where most of the missing requirements live. Asking “what does the user see if this fails?” at each step usually turns up a business rule nobody has decided yet.
- Activities
- Sketch the main journey for each user group, then the alternative paths, the permission differences between roles, and what happens when something fails.
- Deliverables
- Flow diagrams, or a numbered list of steps, covering the main path, alternatives, permissions and error scenarios. New questions go on the open list.
- Who takes part
- Designer and product owner, with a tech lead for feasibility and someone close to the users.
- Who approves
- No formal approval. The product owner and tech lead review the flows before prototyping starts.
- Starts when
- The requirements brief exists and the main tasks are agreed.
Done when
- Every main task has a path from start to finish.
- Alternative paths and early exits are covered, such as saving a draft, cancelling or coming back later.
- Each role’s differences are marked: what it can see, change and approve.
- Error scenarios are listed: bad input, missing data, a service that’s down, an expired session.
- Any step whose feasibility is uncertain is flagged for a spike.
3. Build a prototype
Placeholder text hides problems. A label that fits as “Lorem ipsum” may wrap to three lines with a long product name or a translation, and a table that looks clean with three sample rows can fall apart with three hundred.
- Activities
- Start with low-fidelity wireframes to settle layout and order. Then build a clickable prototype of the main flows with realistic content: real labels, realistic names and numbers, and text at its real length.
- Deliverables
- A clickable prototype of the flows that will be tested, including loading, empty, error and success states wherever the flow needs them.
- Who takes part
- Designer, with the product owner reviewing content and an engineer checking that nothing in it is unbuildable.
- Who approves
- No formal approval. The designer decides when it’s ready to test.
- Starts when
- The flows are reviewed, and any spike that could change the design has answered its question.
Done when
- Every flow in the test plan can be clicked from start to finish.
- Content is realistic, and long names, long lists and empty fields are represented.
- Loading, empty, error and success states exist wherever the flow needs them.
- The prototype promises nothing the business hasn’t agreed to, such as a price or a policy.
4. Validate with users and stakeholders
You don’t need a big study. Nielsen Norman Group’s guidance is that about five users from one group find most of the usability problems in a qualitative test, and that several small rounds teach you more than one large one. When users and stakeholders disagree, take the conflict into stage 5 as a decision instead of leaving it for a meeting after launch.
- Activities
- Ask representative users to complete realistic tasks on the prototype without help. Record whether each task was completed, where people hesitated or got confused, the errors they made and what they said. Separately, walk stakeholders through the flows and ask them to confirm the flows meet business needs.
- Deliverables
- Short test notes for each task covering completion, confusion, errors and feedback. A ranked issue list with critical ones marked, and the stakeholders’ confirmation or objections.
- Who takes part
- Representative users from each main group, a facilitator, a note-taker, and the relevant stakeholders.
- Who approves
- Stakeholders confirm business fit. Users don’t approve anything; their results are evidence.
- Starts when
- The prototype covers the tasks in the test plan, and you have recruited users who match the target groups.
Done when
- Each main user group has tested the tasks that matter to it.
- Results are recorded per task, so patterns across users are visible.
- Issues are ranked, and critical ones (a task people can’t finish, or a wrong business rule) are marked.
- Stakeholders have confirmed the flows, or their objections are written down.
5. Revise and agree on scope
This is the gate. Everything before it was cheap to change, and everything after it costs more. The agreement can be short, but it has to be written down, because “I thought we agreed” is how scope drifts in week three.
- Activities
- Fix the critical issues, retest the flows those fixes touched, and decide what to do with everything else: fix now, accept, or defer. Then write down what will be built.
- Deliverables
- A short scope agreement: the accepted requirements, the final prototype, acceptance criteria for each flow, what’s out of scope, and the remaining uncertainties with a plan for each.
- Who takes part
- Product owner, designer, tech lead, and the stakeholders who raised objections.
- Who approves
- The product owner signs off the scope. The tech lead confirms it can be built within the constraints.
- Starts when
- Test results are in, and the issues are ranked.
Done when
- No critical issue is left open, and every fixed flow has been retested.
- Each flow has acceptance criteria someone could test against.
- Out-of-scope items are written down so they don’t come back as surprises.
- Remaining uncertainties are listed with how each will be resolved: a spike, a measurement after launch, or a decision by a date.
6. Develop
Traceability sounds heavier than it is. A requirement ID that appears in the screen name, the user story and the pull request is usually enough to answer “why does this exist?” six months later. Smaller stories and smaller pull requests also make each increment easier to check against the design.
- Activities
- Build the validated design in small increments, each one a usable slice of a flow. Review each increment against its acceptance criteria and the prototype.
- Deliverables
- Working increments in a test environment, each traced to the requirements, screens and acceptance criteria it covers.
- Who takes part
- Engineers, the designer for questions and review, and the product owner reviewing increments.
- Who approves
- Code review approves each change. The product owner accepts each increment against its criteria.
- Starts when
- The scope agreement is signed off. Spikes and environment setup can start earlier.
Done when
- Each increment links to a requirement, a screen and its acceptance criteria.
- Departures from the prototype were agreed with the designer before review.
- Automated tests cover the business rules and the error paths from stage 2.
- New uncertainty goes back to the product owner as a decision instead of a guess in code.
7. Run UAT on working software
UAT should mostly find defects: things built differently from what was agreed. If it keeps finding “that’s not how we work,” stage 4 tested the wrong people or the wrong tasks, and that’s worth fixing before the next project.
- Activities
- In a staging environment, business owners and future users run realistic scenarios end to end. They verify business requirements, integrations, permissions for each role, data handling and the error paths.
- Deliverables
- UAT results per scenario, a defect list ranked by severity, and either a written acceptance or a list of what must change first.
- Who takes part
- Business owners and the people who will use and support the system, with QA and engineers fixing defects.
- Who approves
- The business owner, or the designated UAT approvers, accept the release.
- Starts when
- The agreed scope is built, staging matches production closely enough to trust, and the test data is realistic.
Done when
- Every acceptance criterion has passed in staging.
- Each role has been tested with its real permissions, including what it shouldn’t be able to do.
- Integrations have been tested in both success and failure cases.
- Data imports, exports and migrations have been checked against real or production-like records.
- No open defect blocks acceptance.
8. Release and measure
Prototype testing and UAT both rely on a handful of people in controlled conditions. Production is the first time you see everyone, and the success criteria from stage 1 tell you whether the earlier stages got it right.
- Activities
- Deploy once the acceptance criteria pass. Watch actual usage against the success criteria from stage 1, along with errors and support requests, and fix what comes up.
- Deliverables
- The release, a rollback plan, a dashboard or report on the success criteria, and a short list of follow-ups.
- Who takes part
- Engineers and operations for the release; the product owner and support watching usage.
- Who approves
- The product owner decides when to release, with the tech lead confirming it’s safe to deploy.
- Starts when
- UAT is accepted and the rollback plan is ready.
Done when
- Monitoring and alerts cover the new flows before release.
- Success criteria are being measured in production.
- Support knows what changed and where to send problems.
- Findings become requirements for the next round, which starts again at stage 1.
When should you build something before the design is final?
Build a small technical prototype, often called a spike, before the design is final whenever feasibility could change the design. If the answer to “can we actually do this?” might force a different workflow, find out before users test a flow you can’t build.
I prototype the riskiest part first. These are typical questions a spike answers:
- Can the third-party API return data in real time, or only in a nightly batch? A live status screen depends on the answer.
- Can we get the data at all, in the format and quality the flow assumes?
- Will offline use, camera access or file upload work on the devices the users actually have?
- Is the search or calculation fast enough at real data volumes to run as the user types?
Keep each spike to one question and a fixed amount of time, and treat the code as disposable. The deliverable is the answer, fed back into the flows in stage 2. Once the plan holds up, a walking skeleton early in stage 6 proves the pieces connect end to end before features pile up on top.
Does every change need a prototype?
No. Match the process to the cost of being wrong. Copy fixes and obvious bug fixes can go straight to development and review. A new flow in an existing product needs a quick prototype and a few users, while a new product or a workflow people depend on deserves all eight stages.
| Change | Stages | Sign-off |
|---|---|---|
| Copy fix, small visual tweak, obvious bug | Develop, review, release | Code review, with the product owner agreeing in the ticket |
| New screen or changed step in an existing flow | A sketch or clickable mock of the affected flow, a walkthrough with a few users, then build | The product owner, once the flow is tested |
| New product, or a workflow people depend on | All eight | Scope agreement at stage 5 and UAT acceptance at stage 7 |
The more a mistake costs after release, the more of the first phase is worth doing. Data migrations, regulated or public-sector workflows, mobile apps that wait on app store review, and anything people have been trained to use all raise that cost. An internal tool with five users who sit near the team lowers it.
Two habits keep the process light. Formal approvals happen only at the scope gate and at UAT, and the stages in between use reviews. A minor change to a flow that has already been validated gets a quick check with the designer instead of another round of testing.
Short answers
What is the difference between prototype validation and UAT?
Prototype validation tests whether people understand a design and can complete their tasks, before production code exists. User acceptance testing (UAT) tests whether the working software meets the business requirements end to end, with real integrations, permissions and data, usually in a staging environment.
Can a prototype replace user acceptance testing?
No. A prototype can verify navigation, wording, missing steps and whether business rules were understood. Performance, integrations, real data, security and server-side permissions only show up in working software, so they still need UAT.
How many users do you need to test a prototype?
For a qualitative usability test, Nielsen Norman Group’s guidance is that about five users from one group find most of the problems, and that several small rounds teach you more than one large study. Test each main user group separately.
When should you build a technical spike before the design is final?
When feasibility could change the design. If an API, a data source, a device capability or performance at real data volumes might force a different workflow, answer that question with a time-boxed spike before users test the flow.
Does every change need a prototype?
No. Copy fixes and obvious bug fixes can go straight to development and review. A new flow in an existing product needs a quick prototype and a few users, while a new product or a workflow people depend on deserves the full workflow with scope sign-off and UAT.
Tailor it before you start
The same eight stages look very different for a public-sector form, a mobile app and an internal dashboard. Before planning any of them, I’d want answers to four questions:
- What is the product idea, in a sentence or two?
- Who are the target users, and which group matters most?
- What platform is it on: web, mobile, desktop or several?
- What is the main workflow a user has to finish?
Those answers decide which users to recruit, which risks need a spike, and how many of the stages are worth doing at all.