The 3hr “Feature Sprint”

We like the GV design sprint….

We’ve been working with the Google Ventures design sprint process at busuu for about 6 months. We love it. The thing we like most is the workshop formats and how they prompt us to think differently about solving problems. In fact, we’ve started using these approaches in all kinds of other meetings.

2 ways we’re iterating design sprints

We’ve also been playing with the structure of the design sprint itself. Our goal is to iterate it into something that fits the way that we work, so that a ‘Design Sprint’ is not just something that we do every 3 months to tackle a ‘big problem’. The reality is that if you work in a startup your entire life is probably dedicated to solving one big problem — that’s what you’re here for! But we can’t be in a perpetual cycle of 5 day design sprints.

So far we’ve landed on two things that are working well for us.

The first is the 3 day Sprint — a turbocharged, condensed version of the 5 day Sprint. It has all the same elements, just stripped back a little and with the pace increased.

The second is what I’m going to write about here — a 3 hour workshop (using Design Sprint frameworks) that we’re using to develop new features.

The 3 hour feature sprint

There’s normally one part of a feature that’s really hard to get right. It’s the speck of gold dust that makes the feature unique and valuable to users. If you lose sight of it or choose to focus on the wrong thing, it’s death for your feature. We use the 3 hour feature sprint to try and solve this problem — to give us a feature design framework that keeps us focused on the most difficult/important part of the feature.

Here’s how it works:

Bring together the team

We run this workshop with a small team with a lot of shared knowledge so that we can move fast. Usually a Product Manager, a Designer and someone from another team who has the most relevant knowledge. For us this could be someone from our Education team, our Marketing team or one of our Engineers.

1 hour — Identify problem

Identify problem
  1. 10m: Set a long term goal — define the ultimate purpose of the feature and the problem it solves for your users
  2. 5m: Identify the start and end of your feature interaction — what need will prompt a user to interact with this feature? Having used it, what will they have hopefully achieved? If your feature already exists, imagine the perfect interaction.
  3. 10m: Using postits map out the key experiences your user needs to have in order to get the full benefit of the feature. If it’s an existing feature some of these might already exist, but lots of them won’t.
  4. 10m: Using postits in a different colour, do a round of ‘How Might We’ to identify the parts of the map that hold the biggest challenges. Generally the area with the most HMW notes is the most important part of the feature. If there’s not a clear winner, do a round of dot voting with 3 votes each.
  5. 5m: Define your sprint focus — make sure the cluster of winning HMW questions is formulated into one coherent question you’re going to answer. If you can solve this problem then your feature will be a hit.

1 hour — Research solutions

Research solutions
  1. 30m: Research existing solutions to the specific problem you’re trying to solve. Don’t get caught up in looking at ‘how other people do this feature’. Remember, you’re trying to solve your focussed HMW question, not re-think the whole feature. There may be good solutions to your HMW that are totally unrelated to the feature itself.
  2. 30m: Lightning demos — Present your research to the team and capture insightful sketches and observations on a whiteboard. Group your insights into themes if they fit naturally. You should now have all the ingredients you need to solve your problem…

1 hour — Distill

Distill
  1. 10m: Do a round of Crazy 8s to get the solutions sketches flowing.
  2. 10m: Each sketch out your perfected version of the solution. Remember again to focus on the key interaction in your feature, not the whole thing. Your HMW mapping has shown that you largely know how the rest of the feature should work already. Don’t forget to give your solution a name!
  3. 10m: Art Gallery — put your solutions up on a whiteboard and review. Let’s be honest, if there are 3 of you then it’s hard to maintain secrecy here. But we do look over them in silence and then use dots to heat map the most valuable elements of each design. Remember to constantly be looking back at your feature goal and the sprint focus.
  4. 30m: Storyboard — we generally find we’re all pretty aligned on the output of the Art Gallery heatmap, so this storyboard mapping is focussed on making sure we get the copy and key interactions right. This will be the basis of your prototype.

Next: Prototype/user test/iterate

  1. Design and build a realistic prototype in Invision. We generally find that the elements of the feature that were not the focus of the sprint are non-contentious and can be designed quickly ‘by committee’ with the sprint team and rarely take long. The focus of the prototype is on finding out if you’ve solved your sprint question; the HMW.
  2. User test. Depending on the feature, we use:
  • Guerilla testing of the prototype in cafes
  • Testing of key views and interactions on Usability Hub
  • Feedback on designs from power users

3. Iterate. act on feedback to resolve snags. Test again!

Finally

You have a feature that you can be confident in building! Often it won’t feel like a revolution. That’s because you’ve focussed all of your energy on one small but really gnarly key experience, rather than on playing with the ‘easy’ bits. The important thing to remember is that this one experience is where all of your marginal gain comes from. If you’ve got that little nugget of gold right, that’s what will make your feature fly.


Originally published at medium.com on September 23, 2016.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.