Every blockbuster movie begins with a preliminary screenplay reading, and every successful music album starts with demo recordings. Apps and websites are no different. This essential step, where ideas and thoughts take on shapes and colors, is as exciting as the final app launch. Prototyping the app represents a significant turning point in the Sprint design, and like the preceding steps, it has rules, structure, and a very specific mindset.
The prototype mindset:
“From perfect to just enough, from long-term quality to temporary simulation.”
Jake Knapp, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
The prototyping and refining phase represents one of the most significant mindset shifts in the Sprint process. Now, we need to “fake” our solution in a way that is almost credible for testing with potential users.
In his book, Jake Knapp makes a bold and refreshing argument: we don’t have to create an entire product to determine if our idea is viable. We only need to simulate the experience well enough for real users to respond to it. What makes this so effective is the intentional constraint: we only have one day to prototype in a design Sprint. That tight time limit forces the team to focus on what really matters — the user-facing experience — and ignore all the internal complexity. This not only saves time but also liberates teams from perfectionism. We’re no longer building to launch; we’re building to learn.
Knapp also reframes prototyping from a technical process into a storytelling tool. We’re not creating a product; we’re creating a believable illusion — like a movie set — so people can emotionally and logically respond to it. Whether it’s a clickable Figma design, a fake customer service flow, or a mocked-up marketing page, the idea is the same: create just enough reality to get honest feedback.
From a team dynamic perspective, this phase of the Design Sprint also encourages collaboration across roles. Writers, designers, product thinkers, and developers can all contribute. It’s not about who can code — it’s about who can help bring the “stage” to life.
The target during this day in the design Sprint is to break the cycle that many teams fall into: investing weeks or months into building something only to find out users didn’t want it in the first place. Instead, this phase invites teams to test assumptions in days, not months, and to treat ideas as experiments, not commitments. It also introduces an empowering message: we don’t need permission or perfection to test something meaningful. We just need creativity, focus, and the willingness to learn fast.
Prototyping
“If the quality is too low, people won’t believe the prototype is a real product. If the quality is too high, you’ll be working all night and you won’t finish. You need Goldilocks quality. Not too high, not too low, but just right.”
Jake Knapp, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
Jake Knapp emphasizes that the prototype is like a movie set — it doesn’t need to work behind the scenes, it just needs to look convincing on the surface. The idea is to simulate the user experience so you can learn how people react, what they understand, and what they don’t.
We may select the tools to create our prototype. If the product is a digital solution, we can utilize tools like Keynote, Figma, Sketch, clickable PDFs, or simulated service flows. The aim is to be swift, focused, and good enough. However, if the idea involves a physical solution, machinery can produce an object, such as a 3D-printed prototype.
During this phase, the team splits into roles for efficient collaboration. There’s a Maker (or a few), a person writing copy, someone gathering assets, and a “stitcher” or “producer” who ensures the final product feels seamless. The goal? Build just enough of the solution to create a realistic test—quickly, and without overthinking.
You can view our prototype team here:
Trial run
Lastly, we need to run a trial for our prototype. The Trial Run is often underestimated, but it’s one of the most important moments of the entire sprint. It’s like a dress rehearsal before a big performance — and just like in theater, it’s where minor issues are caught before they ruin the main event.
At this stage, our team has worked intensely all week. The prototype is ready, the test plan is in place, and the real users are scheduled for the next day. But before jumping into live testing, our team runs through everything from the top: navigating the prototype, checking the interview script, and simulating the user session.
Why? Because no matter how careful you’ve been, there’s almost always something that needs fixing—like a broken link, a confusing screen, or a missing detail in the instructions. The Trial Run helps the team identify and resolve those issues while there’s still time.
Conclusion:
Prototyping is one of the essential steps in Sprint design, giving the first backbone its first visual life. Yet, this is not a standalone step. As the middle link of a strong, short chain, its success depends on the preceding steps. A well-thought-out ideation process leads to a better prototyping phase.
I remember high school drama classes, where I was sometimes asked to go on stage and improvise the first thing that came to mind. Prototyping is exactly the opposite. With energetic and collaborative preceding steps, it becomes easier to bring our ideas and thoughts to life in this step. No room for improvisation here.
Even though the prototype isn’t fully built or polished behind the scenes, it feels real enough to spark genuine reactions. And that’s the whole point. It isn’t about perfection — it’s about bringing our idea to life just enough to learn from it. As our team completes the prototype, we feel momentum. We’re no longer guessing—we’re getting ready to learn directly from real users. Testing day is just around the corner.
