Design Sprint #2

With new learnings in how culture affects a sprint and what to do with failure

A little background

A little less than a month after our first try at a Design Sprint, we decided to run another Design Sprint for another project.

Here’s a brief refresher of the Design Sprint framework:

  1. Monday — Set a problem, map out the rough steps to solve the problem, interview subject matter experts, run a “How Might We…” exercise to start ideating
  2. Tuesday — Sketch out ideas and storyboard the features you want to test
  3. Wednesday — Choose your strongest solutions
  4. Thursday — Build your solutions in a Prototype
  5. Friday — Test with real members of your audience

Sprint #2

InterVarsity is creating a space to house its best practices and resources, and this Sprint was to facilitate feature ideas and conversations around content structure.

Technically, this Sprint wasn’t successful — we couldn’t find something that sang for this project. We ended up spending a lot of time trying to get on the same page.

One of InterVarsity’s best traits is the practice of debriefing and processing things that happened. (Whether or not we follow our own advice the next time after debriefing is another thing, but we do at least have the conversation!)

So we debriefed — where did we go astray?

Decisions in Design Sprints

One great thing about Design Sprints is that you get the right people in the room — key stakeholders, designers, developers, and even someone of your target audience is recommended. This creates a great pool of insights and a product that doesn’t suffer from one voice being too loud.

However, it runs a real danger of turning into“Design by Committee” — which is something no one wants. To solve that, the Sprint book recommends having a “Decider” —after discussion, when a decision needs to be made they make it.

For our purposes, our Product Sponsor was made our decider, who is a VP, an older male, and the supervisor of some of the people in the Sprint. Our sprint attendees were a mix of young, older, various ethnic identies, and roles in the organization. We had a very diverse group.

During our debriefing, we discussed how the process of deciding felt wrong for us and we discovered there were 2 lessons tightly intertwined.

Dynamics at play

  1. The team had a tough time transitioning from typical patterns of: “This decision is made.” to “We’re deciding this so that we can test it out to see if it’s a good idea.”
  2. This was complicated furthermore by those who have a high power distance bias and felt unable to lift their voice against a decision that felt really wrong and didn’t feel the discussion was sufficient.

Conclusions

  • Sometimes you don’t come across the idea that you’re ready to prototype. We’re wondering if we need to let things marinate for longer than a few hours, or to send individuals out to think over the problem and come back and present solutions later.
  • We’re still learning when a Design Sprint is applicable because we’re not convinced that it’s for every big problem.
  • We discussed new approaches to deciding that work better for our team — namely, letting the decider make a choice and then asking for final thoughts.
  • While facilitating, I’ve got a sticky note up to remind everyone that if we’re having trouble moving forward, we need to figure out how to test it, and that testing it doesn’t mean a decision has been made.

All in all, we’re looking forward to Sprint #3!


Ashley Crutcher is a Digital Designer at InterVarsity located in Madison, WI. She tweets at @ashleyspixels and enjoys cuddling with furkiddos, crocheting/knitting, ringing handbells, and thinking too much about everything.