Running Design Sprints: Problem-Solving in 5 days

On a sunny day at the beach, while vacationing in Greece, I was reading “Sprint: How to Solve New Problems and Test New Ideas in Just Five Days” by Jake Knapp, John Zeratsky, and Braden Kowitz. I began thinking about how this is an absolutely amazing concept! The examples were inspiring, all great companies are doing this (Google, Slack, Facebook, Uber, Airbnb),  the process is innovative…but will this work for us? It can be very hard to organize, and it could be a challenge to convince our management and the team to start working within a new methodology. 

Can you imagine having several people canceling their meetings, stopping the work they’re doing, and gathering in one room for five days with experts from different teams? I’m talking about a designer who usually works remotely from Asia, a part of the team and customers in Poland, summer vacations, sprints, code reviews, slack messages, emails, and all of the routines that everyone usually has.

At the same time, we had quite an ambitious OKR that quarter and the design sprint looked exactly like what we needed! The more I read, it began to seem more realistic. Four days later I pitched the idea to our CPO, by sending a reference to Marty Cagan’s article, and we got the green light! 

A couple of weeks later we were sitting in our Berlin office with the time timer, whiteboards, no laptops, me as a nervous facilitator, and most importantly – a team who really wanted to try something new and put all their efforts into solving one BIG problem. 

For each of us, it was the first design sprint ever. Following the advice from the Sprint book, we went through the steps precisely, methodically, and meticulously. The book offers instructions for each and every small detail. It’s like a recipe – just gather all the ingredients and start cooking. The authors even provide a list of supplies to prepare and give very useful tips for facilitators (like buying snacks). 

Our team consisted of a(n):

• Facilitator, 
• Decider (our CPO), 
• Marketing expert, 
• Customer expert, 
• Industry expert, 
• Tech expert,  
• Design expert, 
• UX intern, 
• External tech expert.

At the beginning of each day, we watched videos describing the process. This practice demonstrated to us that it’s better to describe the whole process to the team in advance.

The process, overall, looks very simple. On Monday, you make a map of the problem. On Tuesday, each individual sketches solutions. On Wednesday, you decide which sketches are strongest. On Thursday, you build a realistic prototype. And on Friday, you test that prototype with five target customers. 

Let’s see how it worked!

Monday: Make a map and choose a target

This day is important because it’s when you choose the target and the focus. In the afternoon we spoke to a variety of people from within our company inviting them to share their thoughts and interviewing them.

At the end of the day, it might feel like you haven’t done enough and there is no progress, which couldn’t be further from the truth. This is the foundation for the rest of the process and is the moment when you immerse yourself in a problem. 

Tip: Prepare your experts and describe what your goal is, so they’re not shocked when entering the room full of people asking questions and writing down their answers.

Tuesday: Sketch competing solutions

This is the most creative day! Every great invention is built on existing ideas – so, first, you need to look for inspiration and take notes about the key points which seem applicable to solving your problem. 

Our team was innovative. We had our demos based on not only financial products, but others like Linkedin, Airbnb, MailChimp, online games, and even a women’s health app for cycle prediction!

During this day you must organize the recruiting process of customers for Friday’s test.

In the afternoon, you “work alone, together” on the sketches and leave them in the room for Wednesday’s review.

Tip:  If you participate in a design sprint, do your homework. Prepare some ideas for demos in advance, as they might not come to mind immediately.

Wednesday: Select the best solution

In the morning we entered our room with our sketches taped to the walls. It felt like a gallery opening – without the champagne. The next step was to choose the solution we wanted to proceed with! 

The voting process is also structured. Rather than participating in endless discussions, you vote according to the rules. 

In the afternoon we planned the prototype with the storyboard which should be five to fifteen steps. This may be difficult, as many decisions have to be made. Don’t leave even the small details for the next day because you will need your storyboard ready for prototyping.

Tip: Remember we had a Decider in the room? This role is really helpful throughout the process. You have to make it very clear to the team, from the very beginning, that the person in this role has the right to veto ideas or push for a particular solution. All participants should consent to this.

Thursday: Build a realistic prototype 

This was the day when our designer did a lot of work in Figma.

Everyone helped as much as they could – by preparing wireframes and an opening scene for the prototype. In our case, it was a fake article on a Polish website describing our new product. 

Before testing the prototype with external people, we had one or two interviews with internal employees to find out which parts were unclear and to test our technical setup.

In the evening, part of our team went back to Warsaw, where they had scheduled interviews for prototype testing.

Tip: Tools like Balsamiq can be used for creating low-fidelity prototypes. These types of tools can also help to engage more of your team in the prototyping activity. 

Friday: Test with your target customer

Quite easy to say, very exhausting to do. We had 6 scheduled interviews, one after another. 

One of our challenges was that observers in Berlin had to listen to customers who spoke Polish. This meant that one team member had to translate on the fly (it would have been better to hire a professional translator).

Our biggest mistake was that we recruited users from user testing agencies. The downside of having gone this route is that they are experienced in being interviewed, and tend to pay attention to UX details, rather than to the value of the product.

Tip: Book some time in the evenings for informal after-work beers. We had a lot of thoughts to be shared and we agreed it was better to discuss our ideas while they were still fresh in our heads.

Design Sprints: Kick-off for future problem-solving

The design sprint is not the end of the road, but rather a launching pad to tackling an essential problem, and to come up with ideas or concepts. As a result of five days of hard work, we had the prototype of a completely new product that evolved later into Finiata Analityka. Working together intensely on one big issue, with quick proof, based on customer feedback, helps product teams to solve difficult problems, save time on endless discussions, and keep teams focused.