A sprint week produces plenty of evidence, and very little of it survives the next stakeholder meeting. Turn it into a product decision you can defend in front of anyone who asks by building an outcome scorecard while the testing sessions are still fresh. Then track what happens after the decision, and report it without inflating the result.
A design sprint that ends on Friday afternoon with applause has produced an output. The team built something and watched people use it. That's the deliverable. The outcome is narrower and harder: did the week reduce the uncertainty that justified clearing five calendar days for seven people?
Jake Knapp, who created the method at Google Ventures, puts the range of results plainly. Your prototype, he says, "might be an efficient failure or a flawed success." Both count as success at the level that matters, because both tell you what to do next.
So measure the design sprint against one standard. It worked if you can now write down a decision and name the evidence behind it.
Write the scorecard the same day the sessions end, before the notes get tidied into a story. Memory decays fast, and the version of events that survives a weekend is almost always the flattering one. What you want on paper is the raw material: what you asked and what people did with it.
The structure matters because it blocks a specific failure. Teams that invent their success criteria after prototype testing will pick criteria the prototype happened to meet. Anchoring the scorecard to the framing you set on Monday removes that option.
Start by copying across what the design sprint was supposed to answer. Knapp's Monday exercise has teams write a long-term goal and then turn their fears about it into questions, and those questions are your baseline. If they're vague, say so now rather than pretending the week resolved them.
Underneath each question, record the assumption that made it risky. Teresa Torres, who coaches product teams on discovery, prefers the language of assumption tests over hypotheses precisely because it keeps the bar honest. You're trying to remove risk from a bet.
For every task in the script, log what you expected and what happened. One row per participant, per task. Keep these columns:
The behavior you predicted before the session
Whether the participant completed the task, and unassisted
Errors, wrong turns, and the points where they stopped moving
What they said the screen meant, in their words
Which assumption the moment supports or damages
Add a difficulty rating if you used one. The Single Ease Question is useful here because it has a reference point: across more than 400 tasks, MeasuringU found average scores sitting between 5.3 and 5.6 on a seven-point scale. A task averaging 3 is not a minor annoyance.
Prototype testing with five people is enough to find problems. Nielsen Norman Group's own researchers point out that the five-user rule assumes any given issue has roughly a 31% chance of showing up per participant, which is a diagnostic claim. Write counts, never percentages.
Now list what the week couldn't touch. A clickable prototype says nothing about whether people will pay or whether the behavior survives week three. Those gaps belong on the scorecard with the same prominence as the findings.
Flag contradictions too. If two participants did the opposite thing in the same moment, that's an open question, and it needs naming before anyone builds on top of it.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Look for repetition across sessions, because repetition is the only thing five people can give you. Knapp's rule is that after five customer interviews, the big patterns surface. A pattern means the same behavior in two or more sessions. One person struggling is a note. Four people struggling at the same step is a finding.
Separate what people did from what people said in a debrief, and treat the facilitator's conclusions as their own kind of material. The third kind is the most dangerous, since it arrives already interpreted. Nielsen Norman Group's guidance on usability work is blunt about the first two. It warns that "listening to what people say is misleading" and that you have to watch what they do.
That's also why praise doesn't go in the evidence column. Rob Fitzpatrick, author of The Mom Test, calls compliments the “fool’s gold of customer learning,” and his test is exact: if you can't say why someone liked it and what it would replace in their week, you've collected a compliment instead of data. Someone who says "I love this" and then abandons the task has told you one thing, and it isn't the nice thing.
Set the decision criteria before the testing sessions, not after them. Criteria written once you’ve seen the synthesis drift toward whatever the prototype happened to achieve, which is the same failure the scorecard exists to prevent. Put numbers on them. For example: “Proceed if 4 of 5 participants complete setup unaided; revise at 2-3; stop at 0-1.” Then apply them in front of the person who actually owns the call.
Savioke's sprint worked partly because the company's chief operating officer told the team on day one that the whole thing hinged on the hotel guest satisfaction index, which gave everyone a shared yardstick for stakeholder alignment.
Be clear-eyed about the base rate you're working against. Ron Kohavi's team at Microsoft reported that only one-third of ideas improved the metric they were designed to improve, and at Airbnb Search, 20 of 250 ideas tested positive. A design sprint can tell you which bet you're placing against those odds.
Proceed when the critical assumption held up in repeated behavior. Participants finished the task, and their explanation of the screen matched what you built it to mean.
Document the uncertainty you're carrying forward anyway. Savioke learned the robot's personality worked and that the touch screen games nobody wanted had to go, which is what a real proceed looks like: a yes with specific exclusions attached.
Choose this when the direction survived but the execution didn't. Mixed patterns and people reaching the right screen by the wrong route. Those observations invalidate this build of the concept.
Scope the revision to the failures you observed and run prototype testing again on the same tasks, so the comparison means something. Changing the flow and the copy at once leaves you unable to say what moved.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Stop when the evidence hits a load-bearing assumption and the assumption loses. The cost of stopping is one week. The cost of not stopping is visible in the industry numbers: Pendo's analysis of anonymized product usage found that 80% of features are rarely or never used, and the older Standish Group figures put it at 45% never used with another 19% rarely used.
Record a stop as a result with a number attached. Weeks of engineering not spent is the measurable thing the week produced, and treating it as a loss teaches everyone to avoid running the test next time.
A decision with no owner is a conversation. Convert each line of the scorecard into an action with an owner and a date. The week ends, and calendars reclaim everyone by Tuesday, so settle both before the room empties.
Prototype revisions, owned by the designer who holds the file, due within one week, with the specific failures they must address
Research to answer the pricing and willingness-to-pay questions the prototype couldn’t reach, owned by the founder or product lead, started within two weeks
A technical feasibility check on the riskiest screen, owned by an engineer who sat in the sessions, done within one week
Stakeholder alignment tasks for the people who weren’t in the room and will otherwise relitigate the decision in six weeks, owned by the decision-maker, completed within two working days
A review date when the whole scorecard gets reopened, set by the sprint facilitator, six weeks after the sprint
That fourth item deserves its own warning. Stakeholder alignment achieved inside a sprint room has a short half-life, and the person who missed Friday will reopen the question. Send them the scorecard.
At the review date, reopen the scorecard and check it against reality rather than memory. Which unresolved assumptions got answered, and by what? How long did the decision take to reach engineering? Did the revised prototype get retested, or did it quietly ship instead?
Process measures are fair game and easy to verify. Decision-to-delivery time, the gap between the product decision and the change reaching users, is a number you already have access to, and it says something real about whether the week accelerated anything. Track it as your own process metric. It isn’t a DORA measure: DORA’s change lead time runs from code commit to production, so it starts after the product decision has already been made.
After release, add behavioral measures tied to the behavior you predicted in the scorecard. Google's HEART framework and its Goals-Signals-Metrics process exist for this translation, and the Task Success category maps almost directly onto what you watched people attempt on Friday. If the design sprint predicted that people would complete setup unaided, the live measure is completion rate for unaided setup.
Sprint findings and business outcomes are different categories of claim, and collapsing them is how a good week turns into a bad slide. Five people completing a task tells you the interaction is learnable. It tells you nothing about retention or whether anyone will choose you over the incumbent.
Nielsen Norman Group’s Kate Moran walks through a hypothetical worked example in which a design project is projected to save roughly $318,000 over three years. Every input is a projection, not a result from a released product. It shows how to build a forecast, and it isn’t evidence of what design returns.
NN/g also notes that such estimates don’t need to be perfectly accurate to be useful, which means a rough pre-launch estimate is legitimate as long as you label it a forecast and show its assumptions. Once the product ships, replace the forecast with measured numbers. Before that, the claim a sprint can honestly support is about risk removed. In your write-up, keep observed behavior from prototype testing apart from the business result you'll measure later. Stakeholder alignment is not a business result either, however good it feels in the room.
Measure the sprint by the decision it enabled and the uncertainty it removed, and let the market handle the rest. A scorecard written on Friday and a named decision-maker will outperform any retrospective narrative you could assemble later. If your last design sprint ended without one, bring us the gaps you find.
Tell us about your idea. 24-hour response. NDA-friendly.
Book a Discovery Call →Record each behavior separately and attach the task conditions, participant wording, and point of divergence. Mark the assumption as unresolved rather than averaging the results. Retest the same moment with a revised script or additional participants, because opposite actions can indicate unclear wording, different expectations, or a genuine split in user needs.
Reopen it on a date chosen before the team leaves the workshop, based on when the next evidence should exist. Use an earlier review for prototype revisions and a later review for release behavior. Keep the original predictions visible, then record what changed, which assumptions remain open, and who verified each result.
No, prototype testing can show whether people understand and use an interaction, but it can't establish willingness to pay. Add a separate pricing study that examines current spending, alternatives, and commitment to a paid option. Keep those findings in the unresolved-assumptions section until the research produces direct evidence.
Send them the scorecard, decision, supporting observations, open assumptions, and assigned actions. Ask for written objections by a fixed date, then resolve them with evidence or record them as new risks. This process gives absent stakeholders a clear way to review the work without reopening every discussion from the workshop.
Separate observed prototype behavior from later business results. Report task completion, errors, and decision speed as sprint evidence, then measure revenue, retention, or cost after release against a defined comparison point. Calculate financial return only when the costs and outcomes come from released work rather than forecasts.
Tell us about your idea. 24-hour response. NDA-friendly.
