Building a Realistic Sprint Prototype in One Day

Build a sprint prototype in one day: split the storyboard across Makers, a Stitcher, a Writer and an Asset Collector, then trial-run the facade.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

The sprint prototype is the thing customers will use on Friday, and Thursday is the only day to build it. GV describes the day as adopting a "fake it" philosophy: "A realistic façade is all you need to test with customers," and by focusing on the customer-facing surface the team can finish in one day (GV). The prototype only needs to be real enough to provoke honest reactions at the moments the sprint questions care about. Behind the surface there is usually nothing.

Knapp's checklist calls the target "Goldilocks quality": "just enough quality to evoke honest reactions from customers." It also sets out a prototype mindset: you can prototype anything, prototypes are disposable, build just enough to learn, and "the prototype must appear real" (Design Sprint guide). A prototype that looks obviously fake makes customers comment on the fakeness. A prototype polished beyond the day's time budget leaves gaps elsewhere, usually at the end of the flow where the key questions live.

The tool choice follows from that. In his 2012 description of the early GV sprints, Jake Knapp wrote that he "ditched polished Photoshop mockups in favor of quick-and-dirty Keynote prototypes" (Knapp, 2012). The checklist's rule is broader: avoid the team's everyday tools, which are optimised for quality, and pick tools that are "rough, fast, and flexible." For a digital product that often means slides or a design tool the Makers already know; for a service it can be a script and props; for a physical product, a modified existing object.

This skill covers how to divide the storyboard among roles, build in parallel, stitch the pieces into a consistent whole and run a trial before the day ends. It sits between storyboarding and user testing, and the Google Design Sprint method page explains where it fits in the week.

How It Works

Thursday is organised around roles. The checklist lists Maker, Stitcher, Writer, Asset Collector and Interviewer, and suggests breaking the storyboard into smaller scenes assigned to different people (Design Sprint guide). The Remote Design Sprint Guide gives the same list as Makers (two or more), a Stitcher, one or more Writers, one or more Collectors and one Interviewer (Remote Design Sprint Guide). Makers build the screens or objects. The Writer produces the words, which matter more than teams expect because customers read them. The Asset Collector finds images, icons, data and content so Makers do not stop to search. The Interviewer prepares Friday's script and should not build.

The Stitcher holds the whole together. As sections near completion, "the Stitcher moves in," and "it's the Stitcher's job to make the prototype consistent from beginning to end" and to make every step as realistic as possible, according to the remote guide. With the work split, it is easy for one screen to use a different product name or price than the next, and the Stitcher is the person who catches that.

Realism is concentrated where the questions are. Frames that carry a sprint question need real words, plausible data and believable detail. Frames that only move the customer along can be simpler. Every frame should look like part of the same product, since an inconsistent screen draws attention to itself.

The day ends with a trial run. The checklist schedules it for around three in the afternoon: run through the prototype, look for mistakes, and make sure the Interviewer and the Decider see it. The remote guide adds that the Stitcher should run it for the whole team, check it against the storyboard, and "make sure your prototype will actually help you answer your Sprint Questions." The time left after the trial is for fixing what it finds.

Two tasks run alongside building. The Interviewer writes the Friday script from the storyboard and sprint questions, and someone reminds each customer to show up, by email or preferably by phone (Design Sprint guide).

Step-by-Step Guide

Step 1: Pick the prototyping tool

Choose a tool the Makers can already use quickly: slides, a design tool with linking, or physical materials, depending on what the customer will touch. Avoid the team's production stack, which pulls people toward quality and completeness. Decide the format of the finished prototype (a link on a laptop, a phone, printed pages, a role-play) so everyone builds for the same medium. Make this decision in the first minutes of the morning.

Step 2: Assign the roles

Name the Makers, the Stitcher, the Writer, the Asset Collector and the Interviewer (Design Sprint guide). Keep the Interviewer off building duty so they can write the script. In a small team one person can hold two roles, such as Writer and Asset Collector, but the Stitcher and a Maker should be different people. Write the assignments next to the storyboard.

Step 3: Split the storyboard into scenes

Divide the storyboard into chunks of consecutive frames and give each chunk to one Maker. Agree shared details before anyone starts: the product name, colors, fonts, prices, and the name and details of the example customer used across screens. Put those on the whiteboard so each Maker uses the same values. Mark the frames that carry sprint questions for extra care.

Step 4: Build the scenes in parallel

Makers build their scenes while the Writer drafts all the copy and the Asset Collector supplies images, logos and realistic data on request. Use real words throughout, with no placeholder text, because customers will read and react to them. Keep interactions only as deep as the storyboard requires; a button that the story never uses can be decoration. Check in briefly before lunch to catch any scene that has stalled.

Step 5: Stitch the pieces together

In the afternoon, the Stitcher collects the scenes and joins them into one continuous flow (Remote Design Sprint Guide). They look for mismatched names, prices, styles and dead ends, and send fixes back to the Makers. They also check that the transitions between scenes make sense to someone who has not seen the storyboard. The goal is a prototype that feels like one product from the first frame to the last.

Step 6: Run the trial

Around mid-afternoon, bring the team back together and have the Stitcher walk through the whole prototype while the Interviewer and the Decider watch. Compare it to the storyboard frame by frame. Ask whether each sprint question can actually be answered by what the customer will see. List every problem, then sort them into must-fix before Friday and acceptable.

Step 7: Fix, freeze and prepare for Friday

Fix the must-fix list, then freeze the prototype so nobody makes changes during the tests. Load it on the device customers will use and check it works there, including screen size and any links. The Interviewer finishes the script using the final version. Remind every customer of their appointment before the day ends.

Best Practices

• Build only what the storyboard shows. The checklist's advice is to "build just enough to learn, but not more" (Design Sprint guide), and every extra screen takes time from the frames that matter.
• Put your realism where the questions are. A customer will skim past a plain navigation screen but will study the price, the offer or the confirmation that a sprint question depends on.
• Use tools that are rough and fast. Knapp's own switch from polished mockups to quick Keynote prototypes (Knapp, 2012) is a reminder that speed matters more than fidelity on Thursday.
• Agree shared details before splitting up. A list of names, prices and styles on the whiteboard prevents most of the inconsistencies the Stitcher would otherwise have to fix.
• Hold the trial early enough to act on it. A trial that ends the day leaves no time for fixes.
• Keep the Decider close. Quick answers from the Decider on questions the storyboard missed stop Makers from guessing.

Common Mistakes

• Building a working product: Some teams want to build real functionality because it feels more honest. A facade is enough to test reactions; real code costs time the day does not have.
• Placeholder text and fake-looking data: Customers notice lorem ipsum and obviously fake names and start commenting on them. Have the Writer and Asset Collector supply realistic words and content from the start.
• No one owning consistency: When each Maker works alone, screens drift apart in names and styles. Name a Stitcher and give them time in the afternoon to join and check everything.
• Skipping the trial run: Broken links and missing screens found during Friday's first interview waste a session. Run the trial with the Interviewer and Decider present.
• Changing the storyboard on Thursday: New ideas during building make the prototype drift from what the team decided. Note them for later and build what was agreed.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Google Design Sprint

Related Skills

• Sprint Storyboarding: Plan the Prototype Step by Step
• Sprint User Testing: Running Design Sprint Day 5
• Design Sprint Facilitator: How to Facilitate a Sprint
• Running a Remote Design Sprint with Distributed Teams

Sources

• GV: The Design Sprint
• Jake Knapp and John Zeratsky: Design Sprint guide
• Jake Knapp: The product design sprint, a five-day recipe for startups
• The Remote Design Sprint Guide

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.