Some people believe that you’re now allowed to lift the lid of the pot while the rice is cooking. I don’t subscribe to this point of view. I believe every cooking process should include thorough usability studies. First, myself, then my mom—who is a super rice user—and then anyone else in the kitchen. The author, Steve Krug, says, “Testing with one user early in the project is better than testing with fifty near the end.” In a design sprint, this type of testing is a crucial part of the process.
Here, we will examine how user testing during a Design Sprint can yield valuable insights by involving a manageable number of users. Additionally, we will discuss how user feedback enables our team to move forward on the right path.
“Testing is not merely the final hurdle in your sprint; it’s the gateway to understanding the viability and potential impact of your solution.”
Pattie Belle Hastings, The Sprint Handbook
After three days of focused effort, creativity, and prototyping, it’s time to test our prototype with real users. Instead of delaying a large project launch for months and hoping for feedback, Sprint changes this approach: we gather early insights through a few conversations. It’s all about learning from real people and collecting insights.
Keep it small
In his book, Jake Knapp highlights that we don’t need thousands of data points or a big launch to determine if our prototype is successful. The author supports a key insight from usability research: testing with just five people is often sufficient to identify major usability patterns. If three or more people struggle with the same part of our prototype, we’ve likely found a real problem. This is efficient and empowering — we don’t need to launch at scale to learn at depth.
In a world obsessed with dashboards and Key Performance Indicators (KPI), we must remember the humans behind the numbers. This mindset during the design sprint stresses an empathy-driven approach to design. It values people’s voices. It puts the customer at the center of the product conversation — not after launch, but before anything is even built.
Welcome to the test
Jake Knapp outlines a clear, structured interview format that centers on empathy, neutrality, and active listening. It begins with a warm welcome and gentle context-setting, then transitions smoothly into the prototype — not by saying “here’s our new product,” but by framing it naturally, as if to say: “Imagine this just launched — what do you think?”
That subtle shift is so significant. It makes the user feel like they’re not being tested — the prototype is. That mindset protects the integrity of the feedback. Users are more honest, and teams are less defensive.
While the interviewer guides the user through the session, the rest of our team observes from a separate space, or in the case of a Zoom interview, some team members simply stay muted with the camera off. This separation is genius. It turns the observation into a shared learning experience, where everyone is collecting real-time feedback, not filtered by a research summary or team lead. It creates emotional alignment — our team sees the same surprises, hears the same frustrations, and celebrates the same moments of clarity.
What we begin to notice isn’t just the user’s words, but also what they leave unsaid—pauses, facial expressions, hesitations, and confidence. These subtle cues are small data at its most powerful, leaving lasting impressions. This approach also helps teams move beyond assumptions. When you see someone struggle to complete a task that seemed obvious in our design, the solution becomes clear immediately. The problem reveals itself effortlessly.
During this process, our team has learned to trade perfection for insight. It’s not about impressing users or proving our idea is excellent; it’s about understanding where it succeeds and where it fails—and being grateful for both.
This approach also promotes humility. Many teams begin a Sprint with strong opinions, but watching a user struggle with a feature we championed can be a powerful reminder to focus on genuine user needs. And perhaps most importantly, it builds confidence. Whether users love the prototype or find major flaws, our team walks away with a clear understanding. We know what to do next. We’re no longer guessing.
Insights from user testing
After testing our prototype with real users, it’s time to pause, reflect, and compile our insights. Over the past week, we’ve moved swiftly—mapping the problem, sketching ideas, making decisions, building a prototype, and presenting to users. Now, we have a wealth of valuable data, but if we don’t take a moment to review and organize it, we risk losing some important insights.
All the insights gathered from the interviews are summarized into clear key takeaways. We need to identify recurring patterns and themes in the feedback and prioritize these as items or features to address in the next iteration of our product. Identify what users loved, where they faced challenges, and the questions that kept arising. This helps the team understand which parts of the idea are solid, which areas need improvement, and whether we’re ready to move forward or need to revisit the drawing board.
This moment in the design Sprint reminds us that the Sprint isn’t about achieving perfection — it’s about learning as much as possible, as quickly as possible, so we can make informed decisions. Even if the test showed our idea didn’t work, that’s still a win — because now we know why, and we didn’t waste months building the wrong thing.
By the end of this day, our team has a shared understanding of what worked, what didn’t, and what to do next. We leave the sprint not just with a prototype, but with real evidence and direction — and that’s incredibly powerful.
Conclusion
“Working together to build something that matters to real people. This is the best use of your time. This is a Sprint.”
Jake Knapp, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days
Usability studies in a design sprint have some unique features, such as testing within a limited time, relying on coordinated teamwork, and sharing analytical insights while making prototype modifications. Yet, when executed correctly and well planned, we can skip months of debate and development and reach a solid outcome: a better digital product. So, as the testing day concludes, it’s not just the end of the Sprint — it’s the start of smarter, faster, more confident decision-making toward the final product. And that’s something every team deserves.
