Beyond "What Went Well" in Design Sprint Retrospectives

The design sprint retrospective serves a deceptively simple purpose: to help teams reflect on their process and improve future sprints. Yet this 30-60 minute session at the end of an intense week may yield disappointingly shallow insights.

Picture this: Your team just finished a five-day design sprint for a digital app helping pregnant mothers track their health and connect with healthcare providers. You've prototyped a compelling solution, tested it with five expecting mothers, and gathered invaluable feedback. Now it's time for the retrospective.

"So, what went well?" you ask.

The responses: "The prototype looked really professional." "We stayed on schedule." "Good collaboration." "The users liked it."

These answers feel like the retrospective equivalent of "fine" when someone asks how you're doing—true perhaps, but revealing nothing. These surface-level responses don't help you understand why things worked or how to replicate success - which is really waht you are after.

What's happening?

When we ask "what went well," we're actually creating several problems:

• We invite rehearsed positivity. Team members have been conditioned in workplace settings to offer upbeat, non-controversial observations. They'll reach for the safest, most obvious answers rather than the most meaningful ones.

  
  

• We lose the narrative. Imagine your pregnant mother app sprint: Perhaps the real breakthrough came on Wednesday afternoon when a developer questioned whether push notifications would stress users out, leading to a complete rethink of how the app delivers health reminders. But "good collaboration" doesn't capture that pivotal moment or the conditions that allowed it to happen.

  
  

• We miss the nuance. Consider the weight loss app sprint: Maybe the sketching exercise on Day 2 felt frustrating and chaotic in the moment, but that messiness actually generated the most innovative ideas. A simple "sketching went well" erases the valuable tension that made it productive.

  
  

• We can't replicate success. When your student learning app team says "the prototype was good," you don't learn whether it succeeded because you wisely limited scope, because the designer had specific expertise in educational interfaces, or because you made a lucky guess about which features to prioritize.

  
  

• We avoid uncomfortable truths. Perhaps during the pregnant mother app sprint, the only reason Friday's user testing revealed such clear insights was because a team member violated the sprint structure and conducted informal research earlier in the week. "User testing went well" doesn't acknowledge this deviation or create space to discuss whether the formal structure needed adjustment.

The result? Teams leave retrospectives feeling like they've checked a box but gained nothing actionable. They return to the next sprint armed with the same vague sense that "collaboration matters" and "staying on schedule is good," doomed to stumble over the same obstacles.

Our 5 magical prompts

As design thinkers, we asked ourselves: HMW make our retrospectives more effective? One of the ideas: come up with a set of prompts that make generic answers IMPOSSIBLE.

Prompts that invite teams to relive specific moments, acknowledge tensions, and connect activities to outcomes.

Here are five magical prompts from our perspective that transform design sprint retrospectives, and why they work:

1. What's a decision we made quickly that you're glad we didn't overthink?

This prompt does triple duty.

First, it reveals which sprint principles the team has truly internalized—the whole point of design sprints is to make progress through constrained decision-making, not endless deliberation.

Second, it builds confidence in the team's judgment by highlighting successful instincts.

Third, it creates permission for future speed.

In the pregnant mother app sprint, this might surface the moment when the team chose to prototype only the first-trimester experience rather than building for all nine months.

Someone might say: "We could have spent hours debating whether to show the whole pregnancy journey, but we just picked the riskiest assumption to test—whether new mothers would even want an app at this overwhelming moment. We were right to test narrow and deep rather than broad and shallow."

That's not just a feel-good observation. It's a replicable decision-making pattern the team can apply to future sprints.

2. Which day's activities gave us the most momentum, and why do you think that was?

This forces the team to compare and contrast the sprint's structure, not just accept it wholesale. It reveals what actually works for this team, not teams in general.

The weight loss app team might realize their biggest leap forward came on Thursday during prototype work, not during Monday's mapping or Tuesday's sketching.

Digging into why, they discover their team thinks best with tangible artifacts in hand. Abstract discussions and rough sketches left them uncertain, but the act of building clarified their thinking.

This insight might lead them to prototype earlier or use higher-fidelity sketches in future sprints.

3. What's an idea that didn't make it through but taught us something valuable?

This prompt reframes "failure" as data and gives voice to the paths not taken. It's especially powerful because design sprints are built on divergence followed by ruthless convergence—most ideas must die. But those dead ideas often contain wisdom.

During the student learning app sprint, perhaps someone sketched a peer-tutoring feature that got voted down. In retrospect, although the feature was too complex for the first version, the insight behind it (isolated students desperately needed social connection, not just content) informed every other design decision.

By acknowledging this, the team recognizes that divergent thinking served its purpose even when specific ideas didn't survive.

4. When did the sprint shift from feeling hard to feeling productive?

This question acknowledges that sprints should feel hard because they're designed to compress months of work into days. But there's a difference between productive difficulty and wheel-spinning frustration.

Identifying the inflection point helps teams understand what conditions enable breakthrough

The pregnant mother app team might pinpoint Wednesday morning's storyboarding session. Before that, they were overwhelmed by the complexity of pregnancy tracking, prenatal care coordination, and community features.

The storyboard forced them to pick one user journey and follow it through, which paradoxically opened up clarity on everything else.

The facilitator can now ensure future sprints hit that storyboarding moment before the team drowns in possibilities.

5. Which corner we cut in prototyping actually helped us learn more?

This question liberates teams from perfectionism and reveals the power of constraints.

Design sprints deliberately use "just enough" prototypes to test with users, not production-ready products. But teams often fight this, wanting to build more complete solutions. This prompt helps them see the value of strategic incompleteness.

The weight loss app team might realize their clickable prototype only worked for one specific user journey (logging breakfast), while everything else was static screenshots.

During user testing, this limitation actually helped as users focused their feedback on whether the logging experience felt motivating rather than getting distracted by absent features. The team learns that strategic gaps in prototypes can sharpen user feedback by controlling variables.

Retrospective prompt library

Beyond these five magical prompts, different situations call for different questions. Here's a list of prompts from our library organized by what you're trying to uncover.

When energy was low during sprints

• What's an activity that re-energized the room when we were flagging?

• If energy was currency, where did we spend it wisely and where did we waste it?

• What ritual or break made a bigger difference than you expected?

• At what point did the sprint feel like a marathon vs. when did it feel like a sprint?

• Which time-boxed activity made you think 'I wish we had longer' vs. 'that was perfectly timed'?

  
  

When there was team tension

• When did different working styles complement each other vs. create friction?

• What's an insight that only emerged because we had diverse perspectives present?

• When did conflict or disagreement actually sharpen our thinking?

• Which sprint exercise felt most natural for your discipline, and which felt foreign?

• At what moment did you understand what another discipline needed that you weren't initially providing?

  
  

When the problem space was overwhelming

• Which limitation (time, resources, scope) actually made us more creative?

• What would have been worse if we'd had more time or fewer restrictions?

• When did narrowing down feel right vs. premature?

• Which constraint forced us to prioritize in a way that improved the final direction?

• What did the deadline force us to address that we might have avoided otherwise?

  
  

When user testing had surprises

• What assumption about users got challenged and how did that redirect us?

• Which user testing moment made you want to high-five someone?

• What's the riskiest assumption we tested, and how did it feel to get validation or pushback?

• When during user testing did you have an 'aha' moment about our process, not just our solution?

• What did users teach us about our own solution that we completely missed?

  
  

When decisions felt difficult

• When did having more ideas actually help us vs. when did it feel overwhelming?

• At what point did we have enough information to decide vs. when did we need to push further?

• Which voting round or prioritization gave us the clearest signal?

• What's a decision we made that felt risky but turned out to be exactly right?

  
  

When you want to highlight individual contributions

• Whose contribution or idea really stuck with you, and why?

• What's a skill or perspective someone brought that made a real difference?

• When did you feel most heard by the group?

• What allowed the quiet voices to be heard this week?

  
  

When processes felt forced

• Which sprint exercise felt like busywork vs. which one changed how we see the problem?

• When did the structure feel like helpful guardrails vs. when did it feel constraining?

• What's a sprint rule or activity we could safely skip next time?

• If you could extend one day by 2 hours, which would it be and what would we do with that time?

  
  

When you want to extract lessons

• If you could bottle one thing from this sprint to bring to every project, what would it be?

• What's a capability this team now has that we didn't have on Monday?

• What mistake or misstep taught us the most?

• What almost didn't work but ended up being valuable?

• What's something we stumbled into accidentally that we should do on purpose next time?

  
  

When you want to identify key artefacts

• Which artifact (sketches, storyboards, prototype screens) do you keep coming back to mentally?

• What's something we created that's more valuable than the final prototype?

• Which day produced the output that most changed our direction?

  
  

Facilitating retrospectives

As the retrospective facilitator, our job is not to guide the team toward predetermined insights or validate our own opinions about what worked.

Our role is twofold: maintain neutrality and bring the right tools to the table.

Neutrality means resisting the urge to agree, disagree, or add our own observations when team members share. Our reactions shape what people feel safe saying. A raised eyebrow or enthusiastic nod can bias what comes next.

Neutrality also means distributing attention fairly. If developers have been quiet while designers dominate the conversation, our job is to create openings: "I'm curious if the engineers have a different view on that sketching session."

If someone offers a generic answer, our follow-up question should invite depth without judgment: "Tell me more about what specifically made that collaboration feel different from other projects."

But neutrality isn't passivity.

The second part is about bringing the right tools.

Before the retrospective, we reflect on what we observed during the sprint:

• Did energy dip on a particular day? Select prompts that explore pacing and momentum.

  
  

• Did we notice tension between disciplines? Choose questions that examine how different perspectives collided and combined.

  
  

• Was there a moment when the team seemed lost, then suddenly found clarity? We want to craft prompts that help them identify that turning point.

What we want to do as facilitators

We want to show up at retrospectives with 8-10 carefully chosen prompts based on what we witnessed.

We want to sequence them intentionally, perhaps start with an energizing question about momentum or success, then move into more challenging territory about decisions or tensions, and end with forward-looking questions about capabilities and lessons learned.

We want to write these prompts where everyone can see them. Let the team know you've selected specific questions based on what you observed, and that these aren't the only valid topics—if something else feels urgent to discuss, the group can redirect.

We want to deliver our prompts and give people time to think (silence is okay), invite multiple perspectives, probe gently for specifics when answers feel vague, and otherwise get out of the way.

We want to let the prompts are do the heavy lifting. And our neutrality to create safety for honesty.

The retrospective doesn't exist to make people feel good about the sprint, though it's wonderful when they do. It exists to help teams see their own patterns, understand what conditions enable their best work, and carry forward specific, actionable practices that will make the next sprint stronger.

And that transformation starts not with the answers, but with the questions we choose to ask.