Test a Design Idea with Users in a Short Sprint Before a Big Decision (Design Sprint)

## Check Whether a Sprint Fits the Decision You Face - Use a sprint when an important decision is blocked by uncertainty about a user experience, service, message, or workflow. - Prefer a challenge that crosses functions, carries meaningful cost or risk, and can be represented well enough for target users to react to it. - Name the decision due after the sprint, the decision owner, and the consequence of continued uncertainty. - Do not use a sprint to replace routine delivery, repair a well-understood defect, prove long-term technical feasibility, or claim statistical validation. - If the team cannot identify a decision, a testable experience, or reachable participants, do the missing discovery or preparation first. ## Turn the Biggest Risks into Sprint Questions and Set Success Criteria First - Write a long-term outcome that describes the change sought for users or the organization. - Convert the largest risks into explicit sprint questions, separating verified facts from assumptions. - Define the target user, situation, behavior, and critical moment in the experience. - State what observable evidence would support, weaken, or invalidate the leading hypothesis. - Set decision criteria before solutions are reviewed so attractive execution does not quietly redefine success. - Include accessibility, trust, privacy, operational, and business guardrails relevant to the decision. ## Name One Decider and a Facilitator Before Starting - Appoint one Decider with authority to resolve scope and select the direction when the group disagrees. - Appoint a Facilitator who protects the process, timebox, participation balance, and evidence standard without steering the solution. - Include a small cross-functional group with direct knowledge of users, delivery, constraints, and the business outcome. - Invite specialists for focused input when needed; they do not need to attend every activity. - Assign research, recruiting, prototyping, and logistics ownership before the sprint starts. - Record how an absent Decider will provide timely decisions; unresolved authority is a reason to postpone. ## Block Uninterrupted Time and Recruit Test Users Early - Reserve uninterrupted working blocks and make attendance expectations explicit; fragmented participation weakens shared context. - Prepare a shared workspace, visible timer, mapping and sketching tools, prototype tools, and a decision log. - Assemble a concise fact base: existing research, constraints, metrics, prior attempts, and known open questions. - Recruit representative participants in parallel with the design work, confirm consent and privacy handling, and schedule backups. - Adapt the calendar to the team, but preserve the sequence of understanding, divergence, decision, prototyping, and testing. - Reduce scope before compressing activities so each phase still produces a usable input for the next. ## Map the Steps Toward the Goal and Pick One Moment to Test - Start from the desired outcome and map the actors, major steps, decisions, and handoffs that lead toward it. - Ask domain experts for facts, constraints, failure modes, and unanswered questions; capture insights without turning the session into solution advocacy. - Reframe promising problems as opportunity questions that invite multiple answers without implying one. - Identify the moment where uncertainty, user value, and decision impact intersect. - Have the Decider select one manageable target that can be represented and tested within the timebox. - Record excluded actors, steps, and assumptions so a narrow target is not mistaken for the whole system. ## Have Each Person Sketch Ideas Alone Before Anyone Judges Them - Review a few relevant patterns from inside and outside the domain, extracting principles rather than copying appearances. - Let each participant review the goal, map, questions, and constraints before developing ideas independently. - Move from notes to rough variations and then to a self-explanatory solution sketch with a clear sequence. - Favor enough detail to evaluate the idea while keeping production effort low. - Separate authorship from evaluation so status, confidence, and presentation skill do not dominate selection. - Keep multiple genuinely different approaches until the decision phase; premature blending hides useful tradeoffs. ## Review Sketches Silently and Let the Decider Choose the Direction - Review solutions silently first and mark compelling elements, concerns, and unanswered assumptions. - Use a structured critique to explain the idea, connect it to the sprint questions, and identify its riskiest claims. - Treat participant votes as information, not as a substitute for accountable decision-making. - Have the Decider choose one direction or an explicit combination of compatible scenes. - Document the selected hypothesis, rejected alternatives, unresolved risks, and the reason for the decision. - Avoid consensus theater: disagreement is useful evidence when it is made visible and resolved by known authority. ## Turn the Chosen Idea into a Scene-by-Scene Storyboard and Interview Guide - Describe the participant's experience from a credible trigger through the moment that reveals the key behavior or judgment. - Turn the chosen direction into a scene-by-scene storyboard with concrete content, transitions, choices, and system responses. - Include enough context for a participant to understand the situation without an observer explaining the intended design. - Resolve contradictions and missing states before prototyping; ambiguity in the storyboard becomes expensive rework. - Limit the path to what is necessary to test the central questions, and freeze scope at an agreed cutoff. - Draft a separate interview guide with neutral prompts, core tasks, follow-up probes, and an opening that sets expectations. ## Build a Realistic-Looking Prototype Without Building the Real System - Build a realistic facade that elicits credible reactions without implementing the underlying system. - Match fidelity to the question: make consequential content, timing, interactions, and decisions believable while simplifying invisible machinery. - Divide production into clear roles, use one integrator to maintain consistency, and keep the interviewer available for test preparation. - Test one coherent hypothesis rather than packing unrelated ideas into the same prototype. - Label operational, legal, privacy, accessibility, and safety assumptions that a facade cannot validate. - Run a pilot through the complete path, repair blocking defects, and stop polishing details that cannot change the decision. ## Interview Users One by One and Watch What They Do, Not What They Praise - Interview participants individually in the context of a realistic task, using the same core scenario for comparability. - Ask open, neutral questions; invite participants to think aloud without teaching them the interface or defending the idea. - Prioritize observed choices, hesitation, comprehension, workarounds, and failures over general praise or stated preference. - Let observers capture concise evidence by participant and scene while the interviewer maintains rapport. - Probe unexpected behavior, but distinguish consistent core questions from adaptive follow-up. - Protect consent, confidentiality, dignity, and participant safety, and stop any activity that violates those boundaries. ## Sort the Findings and Assign an Owner and Deadline for the Next Step - Organize observations by participant and critical scene so repeated patterns and meaningful outliers are visible. - Separate direct evidence from interpretation, then trace each finding back to the sprint questions and decision criteria. - Assess confidence honestly: a small qualitative sample and simulated experience reveal usability and belief signals, not population estimates or production viability. - Decide whether to proceed, revise, repeat the test, investigate a new risk, run a different research method, or stop the direction. - State what was learned, what remains uncertain, which assumption is now most important, and what evidence is needed next. - Assign an owner and deadline for the next decision or experiment so the sprint ends in action rather than a presentation.