I've run my first design sprint and it's been awesome: this is what I learned

An incredibly powerful tool for product design

You are at the very beginning of a new project. You feel the incredibly fast pace of change of the market. You feel overwhelmed by the quantity of variables you need to handle. You have no idea if the project will be a huge success or a complete failure. You are trying to answer a precise need, and you have to figure out what's the best way to do it.

You are in the sweet spot for running your first design sprint.

The Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. This technique has been developed by Google Ventures.

These are the process steps:

  1. Understand, Monday
    - Define a long term goal
    - Talk with the experts
    - Define a target for the sprint
  2. Define, Tuesday
    - Sketch solutions on paper
  3. Diverge, Wednesday
    - Make difficult decisions
    - Define a storyboard to test your hypothesis
  4. Prototype, Thursday
    - Build an high-fidelity mockup
  5. Validate, Friday
    - Test with real users
    - Debrief

Are five days enough? Yes. If the long term goal and the target are clear you will get meaningful results from the sprint.

Why the Sprint?

Launching a new product is hard. The biggest risk is building something that your users won't use or something that they won't understand. The Sprint is a tool that empowers you to test your assumptions in five days, instead of months.

The typical path for launching a product is:

  1. Idea
  2. Build
  3. Launch
  4. Learn

The Sprint cuts the path from the idea to the last point: learn. It jumpstarts your project with feedback from the users on the actual product instead of personal assumptions.

That information would cost you months of design and development, and it could arrive just too late.

Why building and launching if you can skip it and get the information?

I know. Just five days? I know, it sounds over-optimistic. I thought the same until I ran my first one.

Some context and my first experience

Let me introduce myself: I'm the co-founder of Belka, a product design and development company. We design and build digital products for companies and startups.

I had the opportunity to run my first sprint with Carlo Gavazzi Controls, a company that builds Power Consumption Meters. They launch several products every year, with different targets, features and specifications.

We have been working with them for a long time before the design sprint, but despite that, designing their products has always been our biggest design challenge, because of their complexity.

I collected all the information I learned regarding the sprint in this post.

The sprint is time-boxed by this tiny timepiece.

Everything can be tested!

The last day of the sprint is for user testing. We tested a piece of hardware, which was actually an empty box.

Users didn't notice it, until the last one broke a connector and saw that it was empty on the inside. He looked at me with a puzzled face. He didn't understand that he was interacting with an empty box.

This is crucial. You can test the product on the users with an empty box and you can retrieve the information you are looking for, without building the actual product.

That's the magic of the sprint!

User Testing checklist

One day to build a mock prototype is enough

I have no idea how we did it, but we did it. It's possible to build a prototype of an app with bluetooth connectivity in one day. I guess that the pressure of the user testing of the next day, and sketching all together is enough to make you run faster.

During the fourth day — the prototyping one — we had a complete and clear storyline sourced from all the sprint participants. That's what really allowed us to move so fast.

The information flow between teams is priceless

During the sprint we had Belka's team and Carlo Gavazzi's team in the same room for five days, building a product together. I never learned that fast about their company, their product and their users in a such a short time-span.

I'm sure that this will save time for both teams and enhance quality over time. The mental model that both teams had at the beginning radically changed at the end of the Sprint, and this is something you usually build in months.

Sharing information involves post-it!

Talking to users is always a source of inspiration

This is nothing new, but it's is true. You always learn a lot on your product talking to final users.

Non-designers are tier-one designers during the Sprint

This was surprising for me. One of the participants of the Sprint was a guy for the post-sales support department. He's not a designer nor a manger, but he sketched one of the best solutions. Everyone praised that solution. We user-tested that solution and it's been a success.

All the participants involved from the product team are valuable. The hardest part of designing products is taking decisions and the team of the Sprint is valuable for that purpose.

Bad drawing is not an issue at all. Clear mind and contextual knowledge is what makes the difference.

Bring developers to the sprint

I've run the Sprint with Fabrizio, Belka's Android developer. He's not a designer, and he's been a valuable resource in the whole process.

Other than helping me moderating the Sprint he brought his expertise in the technical field. This is especially important when you are discussing design features because you can understand how much time it will take to implement them.

That's the power of the sprint: connecting different people within different fields, in order to gather informations and better understand the product.

You will never access that amount of information via brief

In Belka we employ many different methods to retrieve information from our partners:

  • shared user stories
  • high-level and low-level mockups
  • plenty of meetings and checkpoint
  • interactive mockups

But I never had access to as much information as I got in a Sprint. The true difference here is that you try to solve problems along with your partners, allowing yourself to slip inside their mental models and decision patterns.

Do you recommend the Sprint?

Yes. I've never experienced such a powerful tool for product design with another team. At the end you will have deep knowledge of the product, not to mention a tested prototype of a core version of it.