Prototype Validation Sprints

A prototype validation sprint is a timeboxed learning cycle. A team names a risky assumption, builds only enough of an experience to test it, observes representative users, and converts the evidence into a decision. The output is not a finished product. It is a clearer reason to proceed, revise, test another assumption, or stop.

Google's Design Sprint popularized a five-day sequence that moves from a challenge to a prototype tested with customers in the same week. Google also describes a flexible six-phase form: Understand, Define, Sketch, Decide, Prototype, and Validate. A team can compress or extend the calendar, but the causal order matters. Evidence frames the problem before ideas are selected. The prototype exists to answer a defined question. Testing produces observations before the team interprets them.

The learning system

The sprint begins with an assumption: something the proposed experience must make true for the idea to work. Examples include a user recognizing the purpose of a screen, completing a critical flow, trusting a permission request, or understanding a service concept. The team turns the assumption into a test question and identifies what observable behavior would support or weaken it.

The next artifact is a narrow scenario. It gives the participant a believable reason to act without telling them which controls to use. The team then selects a prototype fidelity that can produce the required behavior. Paper sketches can expose concept and wording problems. Linked screens can test navigation and task flow. A coded or high-interaction prototype can test input, state changes, responsive behavior, or hardware-dependent interactions. Fidelity is a measurement choice, not a quality ladder.

Testing connects the model to representative users. The facilitator introduces the session, reminds the participant that the design is being tested, presents the scenario, and avoids teaching the intended path. The note-taker records behavior, quotations, hesitation, errors, recoveries, and task outcomes. These observations are evidence. A participant's proposed feature or the team's explanation of what they meant is not equivalent evidence.

Prototype Validation Sprints

The learning system

Relevant careers