Building a Realistic Prototype in One Day: The Design Sprint Template
This skill teaches you how to translate a sprint storyboard into a clickable, high-fidelity prototype in roughly seven hours, producing a testable artifact that looks and feels like a real product without writing a single line of production code.
Divide your storyboard into discrete screens, assign each to a team member, and build linked screens in Figma or Keynote. Focus on the critical user flow only, use real content instead of lorem ipsum, and stitch screens together with clickable hotspots. The result is a facade that feels real enough to generate honest user feedback without any production code.
Outcome: You produce a linked, interactive prototype that covers the critical user journey end-to-end. This artifact is the sole input to Day 5 user testing, and its realism directly determines the quality and reliability of the feedback you collect.
Prerequisites
- A completed sprint storyboard with a clear user flow (see storyboarding-sprint-concepts)
- Basic familiarity with a prototyping tool such as Figma, Keynote, Google Slides, or InVision
- Understanding of the target user and the test scenario planned for Day 5
- Access to real or realistic content assets (copy, images, data) for the product concept
Overview
Day 4 of the Google Design Sprint is Prototype Day, and it is the most misunderstood day in the entire framework. Teams that treat it as a chance to explore beautiful visual design or experiment with creative micro-interactions almost always run out of time and arrive at Day 5 with a half-finished artifact that confuses test users. The real goal is narrower and more pragmatic: build a facade. The prototype needs to look real enough that a test participant interacts with it naturally, reveals genuine reactions, and gives the team reliable signal about whether the solution concept works. Nothing more, nothing less.
The design sprint template for prototyping revolves around a single principle: just enough fidelity on the surfaces users will touch, and zero effort on everything else. You are not building a product. You are building a movie set where the front of the building looks convincing but there is nothing behind the walls. Every minute spent on a screen or interaction the user will never see during the test is a minute wasted. The storyboard from Day 3 is your script, and the prototype is your set. If a scene is not in the storyboard, it does not get built.
The artifact you produce is a clickable, linked sequence of screens that a test facilitator can hand to a user on Day 5. The user taps or clicks through a realistic-looking flow, speaks their thoughts aloud, and the team watches from another room. A well-built prototype generates reactions like 'Oh, I see, so this is where I would enter my information' rather than 'Wait, is this a real app or a drawing?' That distinction is what separates useful feedback from noise. When done correctly, you finish the day with 15-30 linked screens covering one critical user journey, ready for the five user tests scheduled the next morning. For details on how those tests work, see conducting sprint user tests.
The secondary benefit of this skill is speed of learning. A prototype built in one day costs a fraction of even the smallest engineering effort, yet it can validate or kill an idea with surprising confidence. Teams that master rapid prototyping find themselves running informal sprints well beyond the formal five-day format, testing new features, onboarding flows, and pricing page layouts in days rather than months.
How It Works
The mental model behind sprint prototyping is the concept of a 'Goldilocks quality' facade. Too low fidelity (paper sketches, wireframes) and users struggle to suspend disbelief. They comment on the roughness of the artifact rather than the concept behind it. Too high fidelity (pixel-perfect designs, animated transitions, real data) and you run out of time or, worse, the team becomes emotionally attached to a polished surface and resists killing the idea when feedback is negative. The design sprint template targets the narrow band in between: screens that look like a real product at first glance but that took minutes, not hours, to create.
This works because of a cognitive shortcut test users rely on. When someone sees a screen with real typography, plausible content, and familiar UI patterns (a navigation bar, a form field, a button), they automatically shift into 'using a product' mode. Their feedback becomes behavioral rather than aesthetic. They try to accomplish a task, get confused at the right moments, and reveal whether the information architecture and value proposition actually land. A wireframe triggers 'reviewing a design' mode, which produces a completely different and far less useful type of feedback.
The technique relies on three structural decisions made before anyone opens a design tool. First, scope: you prototype only the screens in the storyboard, which typically covers one critical user journey of 10-20 steps. Second, division of labor: you split the storyboard into chunks and assign each chunk to a different team member working in parallel. Non-designers handle simpler screens (text-heavy pages, confirmation screens), while designers tackle complex layouts. Third, stitching: at a fixed time in the afternoon, the team reconnects all individual screens into one linked flow and does a full click-through to catch gaps, dead ends, and inconsistencies.
The reason this works inside the Google Design Sprint specifically is that the preceding days have already eliminated ambiguity. By the time you reach Day 4, the team has a clear problem statement from Day 1, a voted-on solution concept from Day 2-3, and a detailed storyboard that acts as a blueprint. Without those upstream artifacts, rapid prototyping devolves into improvisation and arguments about what to build. The storyboard is the contract that makes parallel work possible.
One important nuance: the prototype is disposable. Teams that try to build something they can hand off to engineering after the sprint consistently over-invest in architecture, component reuse, and edge cases. The only audience for this prototype is five test users on Day 5. After that, it gets archived. The insights survive; the screens do not. Internalizing this disposability is what unlocks the speed the method requires.
Step-by-Step
Step 1: Review the storyboard and lock scope
Gather the full team around the completed storyboard from Day 3. Read through every panel aloud, confirming what each screen needs to show and what the user does at each step. Count the total number of distinct screens. Anything not in the storyboard is explicitly out of scope.
Write a numbered list of screens on a whiteboard or shared document so every team member has the same reference. This list becomes your production checklist for the rest of the day.
Tip: If the storyboard implies more than 25 screens, look for panels that can be combined or simplified. A prototype with too many screens is harder to stitch and more likely to have broken links during testing.
Step 2: Choose the right tool and set up the shared workspace
Pick a prototyping tool based on team familiarity, not feature richness. Figma is the most common choice because it supports real-time collaboration. Keynote and Google Slides work well when most team members are non-designers, since they are familiar and require no learning curve. PowerPoint also works.
Create a shared file with one page or slide per screen from your numbered list. , 390x844 for mobile, 1440x900 for desktop). Establish a basic style: one font family, a small color palette, and a consistent button style. Spend no more than 15 minutes on this setup.
Tip: Keynote is underrated for sprint prototypes. Its slide-linking feature creates clickable prototypes natively, and anyone on the team can edit slides without design tool experience.
Step 3: Assign screens to team members for parallel work
Divide the numbered screen list into chunks of 3-5 screens per person. Assign complex screens (those with data tables, forms, or interactive elements) to team members with design skills. Assign simpler screens (landing pages, confirmation messages, text-heavy content) to non-designers. Make sure each person knows what content appears on their screens and what the user's entry and exit points are.
Confirm that adjacent screen owners agree on the handoff: what button or link connects screen 7 to screen 8, and what label it carries. Each person works independently for the next 3-4 hours.
Tip: Pair up adjacent screen owners for a two-minute alignment before they start building. A mismatched button label between screen 7 and screen 8 creates a jarring break in the test user's experience.
Step 4: Build each screen with real content and familiar UI patterns
For each assigned screen, lay out the content using real text, plausible names, actual prices, and representative images. XX' pricing. Borrow UI patterns from existing products users already know: standard navigation bars, conventional form layouts, recognizable icons. The goal is to remove anything that signals 'this is fake' to the test user.
Keep visual polish minimal but consistent: aligned text, uniform spacing, readable font sizes. If a screen requires data (a list of search results, a dashboard chart), create 3-5 realistic entries rather than one or two obviously fake ones.
Tip: Grab screenshots from competitor products or well-known apps for visual reference. You are not copying their design; you are matching the level of visual density and realism that users expect from a real product.
Step 5: Add clickable hotspots and link all screens into one flow
Once individual screens are complete, add interactive hotspots (clickable areas) to buttons, links, and navigation elements. In Figma, use the Prototype tab to create connections between frames. In Keynote, use hyperlinks on shapes to link to the destination slide. Follow the storyboard sequence to ensure the user flow moves in the correct order.
Every screen should have at least one forward path. Add a back button or navigation link on screens where the user might want to return. Test every hotspot yourself by clicking through the entire flow from start to finish.
Tip: Create a 'dead end' screen with a simple message like 'Thanks for your feedback!' for any branch the user might try to explore outside the planned flow. This prevents confusion during testing without requiring you to build extra screens.
Step 6: Run an internal trial with the full team
Schedule a 30-minute team review in the early afternoon. One person shares their screen and clicks through the entire prototype from the opening screen to the final screen, narrating each step as if they were a test user. The rest of the team watches for gaps: screens that load in the wrong order, buttons that lead nowhere, inconsistent terminology, content that contradicts what appears on a previous screen. Log every issue on a shared list.
Prioritize issues that would confuse a test user or break the flow. Cosmetic issues (slightly misaligned text, imperfect spacing) go to the bottom of the list or get skipped entirely.
Tip: Have someone unfamiliar with the storyboard do the click-through if possible. Fresh eyes catch flow problems that the builders have become blind to.
Step 7: Fix critical issues and do a final polish pass
Spend 60-90 minutes fixing the issues logged during the trial. Focus exclusively on problems that would break the test user's experience: dead-end links, missing screens, nonsensical content, or confusing navigation. Resist the urge to add new screens or improve visual design. If a fix takes more than 10 minutes, simplify the screen instead of perfecting it.
After fixes are applied, do one final click-through to confirm every link works. ).
Tip: Set a hard deadline for the final click-through, typically 4:00 PM. Any issue discovered after that gets a workaround (the facilitator navigates manually) rather than a fix. Shipping a complete prototype with minor rough edges beats shipping a polished but incomplete one.
Step 8: Prepare the prototype for the test environment
Configure the prototype for the exact conditions of Day 5 testing. If testing on a phone, load the prototype on the test device and verify touch targets are large enough to tap reliably. If testing on a laptop, open the prototype in presentation or full-screen mode and hide any browser chrome or design tool UI. Prepare a 'reset' procedure so the facilitator can quickly return the prototype to the starting screen between test sessions.
Write a one-paragraph test scenario that the facilitator will read to each user, explaining the context ('Imagine you just heard about this product from a friend and you visit the website for the first time').
Tip: Run through the prototype on the actual test device at least twice. Touch targets that work fine with a mouse cursor often fail on a real phone screen, and font sizes that look crisp on a large monitor can be unreadable on a smaller device.
Examples
Example: B2C mobile app for meal planning
A four-person startup team is running a design sprint to test whether busy parents would pay for a weekly meal planning app. The storyboard covers a single flow: user opens the app, sees a personalized meal plan for the week, taps on Monday's dinner, views the recipe, and adds ingredients to a shopping list. The team has one designer and three non-designers. They need to test on iPhones.
The team identifies 14 screens from the storyboard. The designer takes the four most complex screens: the weekly meal plan grid, the recipe detail page, the shopping list, and the onboarding screen. The three non-designers split the remaining 10 screens, which include a welcome screen, login, confirmation dialogs, and transitional loading states. They use Figma with a 390x844 mobile frame.
Real recipe names, actual ingredient lists from a cooking blog, and stock food photography replace all placeholders. By 1:00 PM, all screens are in the shared Figma file. The stitcher connects them with prototype links, and by 2:30 PM the team does a trial click-through on an iPhone using the Figma Mirror app. They discover that the 'Add to Shopping List' button is too small to tap reliably on the phone, and the recipe page requires scrolling that the prototype does not support well.
They enlarge the button and split the recipe into two linked screens to eliminate scrolling. The final prototype is ready by 4:00 PM. On Day 5, four out of five test users navigate the flow without confusion, and the team gets clear signal that the value proposition resonates but the shopping list needs a 'share with partner' feature they had not considered.
Example: B2B SaaS dashboard for sales teams
A product team at a mid-size SaaS company (about 200 employees) is sprinting on a new analytics dashboard concept for sales managers. The storyboard covers: sales manager logs in, sees a team performance overview, drills into one rep's pipeline, identifies a stalled deal, and clicks through to a suggested action. The team includes two designers, a product manager, a data analyst, and an engineer. Testing will happen on laptops via screen share.
The team counts 18 screens. The two designers take the dashboard overview and the pipeline drill-down, which require charts and data tables. The data analyst builds the deal detail screens using realistic but anonymized data from the company's own CRM exports. The product manager builds the login screen, the suggested action screen, and two confirmation dialogs.
The engineer creates a simple 'error state' screen and a 'no data available' state in case the facilitator needs them during testing. They work in Figma with 1440x900 desktop frames. Real sales numbers, actual rep names (changed for privacy), and charts built from CSV data make the dashboard feel authentic. During the 2:30 PM trial, the team notices that the transition from the overview to the pipeline view is confusing because the navigation pattern changes.
They add a consistent sidebar navigation to both screens, which takes 20 minutes. The finished prototype has 18 linked screens. On Day 5, three of five test users correctly identify the stalled deal without prompting, validating the information hierarchy. Two users miss the 'suggested action' button, signaling a need to make it more prominent.
Example: Internal tool for warehouse operations
A logistics company is sprinting on a tablet-based tool for warehouse workers to scan incoming shipments and flag discrepancies. The team is small: one designer, one warehouse operations lead, and one product owner. Users are warehouse workers who are not tech-savvy. The storyboard covers scanning a barcode, viewing shipment contents, marking items as received, and flagging a missing item. Testing will happen on iPads in a conference room that simulates the warehouse environment.
The storyboard yields 12 screens. The designer builds the barcode scanner interface (a camera-like overlay with a scan button), the shipment detail list, and the discrepancy flagging screen. The operations lead, who knows warehouse terminology and workflows intimately, writes all on-screen labels and instructions in the language warehouse workers actually use. The product owner builds the confirmation screens and a 'shipment complete' summary in Google Slides, which are then imported as images into the Figma file.
Because the users are not tech-savvy, the team increases all font sizes to 18px minimum and makes all buttons at least 48x48 pixels. They use a bold green/red color scheme for received/missing status, matching the visual language already used on the warehouse floor. During the trial, they realize the 'flag missing item' flow requires typing a reason, which is slow on a tablet in a warehouse. They replace the text input with three preset reason buttons ('Not in box,' 'Damaged,' 'Wrong item').
On Day 5, all five test users complete the scan-and-receive flow in under 90 seconds, and four of five successfully flag a missing item without assistance. The team validates the concept and identifies that adding a photo-capture step for damaged items would improve the flagging workflow.
Example: Keynote-based prototype for a nonprofit fundraising page
A two-person nonprofit team with no design experience is sprinting on a new online donation page. The storyboard shows a donor arriving from an email link, reading an impact story, choosing a donation amount, entering payment information, and seeing a thank-you confirmation. They have no Figma experience and are testing on a laptop in their office.
The team chooses Keynote because both members are comfortable with it. They create 10 slides, one per storyboard panel. They use a screenshot of their current website header as the top of every slide for visual continuity. The impact story slide uses a real photo of a beneficiary (with permission) and actual outcome statistics from their last annual report.
The donation amount slide shows four preset buttons ($25, $50, $100, Other) styled to look like web buttons using Keynote shapes. The payment form slide uses a screenshot of Stripe's hosted checkout page embedded as an image, since they plan to use Stripe in the real product. They link slides using Keynote's hyperlink feature on shapes, which creates a click-through experience in presentation mode. The trial click-through reveals that the transition between the impact story and the donation form feels abrupt.
' On Day 5, all five test donors complete the flow. Three donors comment positively on the impact story, confirming it is the right emotional hook. Two donors express confusion about whether the $50 amount is a one-time or recurring donation, revealing a missing label the team adds to their requirements for the real build.
Best Practices
Use real content everywhere, including names, prices, dates, and product descriptions. Lorem ipsum and placeholder text trigger the 'this is fake' response in test users, which contaminates every observation from that point forward. Even rough real content outperforms polished fake content.
Timebox ruthlessly by setting hard deadlines for each phase: setup by 10:00 AM, parallel building until 1:30 PM, stitching and trial by 3:00 PM, fixes done by 4:30 PM. Without timeboxes, teams spend the entire morning debating tool choices and run out of time for the actual build.
Keep the Decider available throughout the day so that content and design questions get resolved in minutes, not hours. When builders encounter ambiguity ('What should the pricing page show?'), the Decider makes the call immediately. Without this, builders either guess (risking a prototype that tests the wrong thing) or stall (risking an incomplete prototype).
Build for the test script, not for completeness. If the test scenario only asks users to complete a signup flow and browse a dashboard, do not build the settings page, the help center, or the billing screen. Every screen outside the test path is wasted effort.
Match the visual fidelity of products your users already know. If your target users are enterprise software buyers accustomed to polished SaaS dashboards, a rough sketch will not generate authentic reactions. If your target users are internal employees evaluating a new workflow, a simpler visual style is fine. Calibrate to the audience.
Designate one person as the 'stitcher' who owns the master file and is responsible for connecting all individual screens into a single flow. Without a single owner, linking conflicts, duplicate screens, and broken paths multiply as the day progresses.
Archive the prototype immediately after Day 5 testing. Do not let it drift into a specification document or a design handoff asset. The prototype was built for speed, not accuracy. Treating it as a source of truth for engineering leads to costly misunderstandings about scope and functionality.
Common Mistakes
Over-investing in visual polish and pixel perfection
Correction
This happens because designers instinctively apply their craft standards to every screen they touch. The signal to watch for is any team member spending more than 20 minutes on a single screen's visual treatment. Redirect that energy by reminding the team that the prototype will be used for exactly five test sessions and then archived. Match the fidelity level of a well-designed slide deck, not a production-ready mockup.
Using placeholder content (lorem ipsum, 'Jane Doe', '$XX.XX')
Correction
Teams default to placeholders because sourcing real content takes effort and feels like a distraction from 'building.' The problem is that test users fixate on fake content and their feedback shifts from 'I don't understand what this product does' to 'I can't read the text.' Spend 15 minutes at the start of the day collecting realistic content: competitor screenshots for reference, real product names, plausible prices, and stock photos of real people. This small investment dramatically improves feedback quality.
Prototyping too many screens or user flows
Correction
This usually stems from skipping the scope-locking step or from a storyboard that tries to cover multiple user journeys. If your screen count exceeds 25, you have likely expanded beyond the single critical path. Go back to the storyboard and identify which panels are essential to test the core hypothesis. Cut everything else.
A tight 15-screen prototype that covers one flow completely will always outperform a sprawling 40-screen prototype with gaps and dead ends.
Building the prototype as a solo designer effort while others watch
Correction
This happens when teams interpret 'prototype' as a design task and assign it entirely to the designer. The result is a single bottleneck who cannot finish 20+ screens in one day. The fix is deliberate division of labor: non-designers build text-heavy and simple screens using Keynote or Google Slides while the designer handles the complex layouts. A prototype built by four people in parallel is almost always better than one built by a single designer under time pressure, because it actually gets finished.
Skipping the internal trial run before Day 5
Correction
Teams skip the trial because they feel pressed for time and assume they will catch issues during testing. The problem is that a broken link or a missing screen during a real user test wastes one of your five precious test sessions and produces no usable data. Always reserve 30 minutes for a full team click-through. The issues you catch during the trial, such as mismatched terminology, confusing navigation, and dead-end screens, are exactly the ones that derail test sessions.
Not testing the prototype on the actual device used for user testing
Correction
A prototype that looks great on a 27-inch monitor can fall apart on a phone screen. Touch targets shrink, text becomes unreadable, and scrolling behavior changes. Load the final prototype onto the test device at least an hour before the end of the day. Check font sizes, button tap areas, and screen transitions. Fix device-specific issues before you leave for the evening.
Other Skills in This Method
Mapping Problems and Defining the Sprint Challenge on Day 1
How to run the Understand phase by creating a problem map, conducting expert interviews, identifying assumptions, and selecting a focused sprint target for the week.
Conducting User Tests and Synthesizing Feedback on Day 5
How to recruit the right test participants, run five moderated usability interviews in one day, capture observations, and identify patterns that validate or invalidate your sprint hypothesis.
Storyboarding the User Journey for Sprint Prototyping
How to create a step-by-step storyboard that translates the winning sketch into a coherent user flow, serving as the blueprint the team follows during prototype day.
Planning and Customizing Your Design Sprint Agenda
How to structure the full multi-day sprint agenda, adapt the classic 5-day format into shorter 4-day or Design Sprint 2.0 variations, and prepare all necessary materials and logistics.
Facilitating a Design Sprint as the Sprint Master
How to effectively facilitate each phase of a design sprint, manage group dynamics, enforce timeboxes, and guide teams through structured exercises from start to finish.
Running Design Sprints Remotely with Distributed Teams
How to adapt the design sprint framework for remote or hybrid teams using tools like Miro, FigJam, and Zoom, including async exercises and strategies to maintain energy and engagement.
Sketching Solutions and Running Structured Voting
How to guide participants through Crazy 8s, solution sketching, heat-dot voting, and the Decide phase to converge on the strongest ideas without groupthink.
Frequently Asked Questions
How do I build a sprint prototype if nobody on the team is a designer?
Use Keynote, Google Slides, or PowerPoint instead of Figma. These tools are familiar to everyone and produce prototypes that are easily good enough for user testing. Take screenshots of competitor products or similar apps for visual reference, use those as a baseline for layout, and swap in your own content. The prototype does not need to be beautiful. It needs to be clear, clickable, and populated with realistic content.
How long should the prototype take to build from start to finish?
Plan for 6-8 hours, which fills one full sprint day. Spend the first 30 minutes reviewing the storyboard and dividing work. Dedicate 3-4 hours to parallel screen building. Reserve 30 minutes for stitching screens together, 30 minutes for the internal trial, and 60-90 minutes for fixes. If you finish early, use remaining time to test the prototype on the actual device rather than adding more screens.
Should I build the prototype before or after writing the Day 5 test script?
Build the prototype first, then finalize the test script. The test script depends on knowing exactly what screens exist, what interactions are possible, and where the prototype's boundaries are. However, you should have a draft test scenario (the one-paragraph context the facilitator reads to users) ready before you start building, because it clarifies which parts of the flow are critical to prototype. See [conducting sprint user tests](/skills/conducting-sprint-user-tests) for the full test script process.
What level of visual fidelity is actually needed for the prototype?
Target the level of a polished slide presentation, not a production UI. Use a single font family, a limited color palette (2-3 colors), consistent button styles, and real content. Avoid custom illustrations, animated transitions, or complex micro-interactions. ' you have the right fidelity. If their first reaction is 'This is really beautiful,' you have over-invested.
Why does my prototype keep taking longer than one day to finish?
The three most common causes are scope creep, unclear storyboard, and solo execution. First, check whether you locked scope at the start of the day. If team members are adding screens not in the storyboard, cut them. Second, review your storyboard from [storyboarding sprint concepts](/skills/storyboarding-sprint-concepts). If panels are vague or ambiguous, builders spend time making decisions that should have been settled on Day 3. Third, verify that you are dividing work across the team rather than funneling everything through one designer.
Can I reuse the sprint prototype as a design specification for engineering?
No, and attempting to do so is a common and costly mistake. The prototype was built for speed, not accuracy. It contains hardcoded content, inconsistent spacing, missing edge cases, and no consideration for responsive behavior or accessibility. Treat it as a communication tool that shows intent, not as a blueprint. After the sprint, create proper design specifications informed by both the prototype and the Day 5 test results.
How do I handle parts of the flow that require dynamic data or logic?
Fake it with static screens. If the flow includes a search feature, build one screen showing the search input and a second screen showing pre-populated results for a specific query that the facilitator will guide the user to enter. If the flow includes personalization, build the screens as if the user is one specific persona with fixed data. The facilitator can set context verbally: 'Imagine you searched for running shoes and this is what appeared.' This approach eliminates the need for any code or dynamic behavior.