Design Sprint in 2 days

Focus on the problem framing. Leave the prototype and test phases for later (if you really HAVE to).

Bettina D'ávila
NYC Design
12 min readApr 1, 2019

--

Design Sprint is a process of framing the right problem, generating tangible solutions, prototyping and testing them with real users in a period of 5 intense days of work. But for our new project at AB Tasty we only had 2 days available to gather the sprint team in a room — and we did it! 💪🏽

As the original definition goes,

“Design Sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers”

This process became notorious within the Design community back in 2014 when Jake Knapp, from Google Ventures, introduced it in his book called Sprint: How to solve big problems and test new ideas in just five days. Knapp tells the world all about his secret recipe to run a successful sprint, regardless of the problem you want to solve and which kind of business you are running. The methodology is already endorsed by big brands such as Slack and Airbnb, but every person and every company can benefit from running a Design Sprint— all you need is a challenge seeking for resolution.

And why do we call it “sprint”?

verb

  1. run at full speed over a short distance

noun

  1. (especially in software development) a set period of time during which specific tasks must be completed.
Nicolas Hoizey from Unsplash

In other words, sprint is a short period of time (1–2 weeks) containing all main stages of product development, from ideation to user testing. Its goal is to quickly verify assumptions, increase knowledge, and eventually mitigate risks. The main difference is that official Google Venture’s Design Sprint methodology is more focused on validating design ideas with as little effort as possible.

Hence our 2-day Design Sprint at AB Tasty: we gathered a team to focus on the problem and solution spaces entirely. The prototype and testing phases would be handled later, on a different process, by the designers and product manager.

Our 2-day Design Sprint

Our messy — but inspiring — working desk :)

We can say that the GV Design Sprint framework is based on the Design Thinking methodology, whereas both methodologies are drawing a problem space and a solution space prior to the prototyping and testing phases, all followed by a learning process to assess if our hypothesis is wrong or right (and what we can do about it).

Because of the difficulty to get everyone in a room for full five days, we decided to concentrate the process in 2 days only. Why? We understand that the most difficult part of the process is the first 3 days of the sprint schedule, where you define the goals, the problem and come up with different relevant solutions altogether. Hence, we decided to merge Monday, Tuesday and Wednesday steps from the Design Sprint methodology into a 2-days process only.

What follows from this dynamic is that the prototyping and testing phases will be taken care of by the designers in a separate moment. Along with the product managers, the designers will have everything they need to start working on the screens and to schedule the interviews for the user testing sessions.

🔥 Preparation

Chinh Le Duc

First things first: we needed a design challenge. Design Sprint without a challenge does not make sense. Since we already had the design problem facing us for a few months, it was not difficult to define the common goal for the sprint and to generate the motivation needed.

Secondly, we needed a Design Sprint team. This is crucial for the success of the sprint because we need to bring together people that have important assets to contribute to the challenge we posed ourselves. Before the actual activities start, the most important thing is to define who will be the Decider (or Deciders) and the Facilitator. In our case, we agreed that the Decider should be the product manager, responsible already for the feature that will be affected by the sprint decisions. And as UX Designer, I was nominated as the Facilitator, both for my Design Thinking mindset inside the product but also for my familiarity with the Design Sprint methodology already.

In fact, Jake Knapp provides a full checklist on how to set the stage for your Design Sprint, from choosing the right team to the items you need to bring to the table, literally.

Before the big day, it is always important to run a checklist to make sure nothing is missing, such as whiteboard, post-its, A4 sheets, sharpies and pens, sticky dots, computer with charger & adapter, alarm clock and, of course, the sprint book 🙃.

In terms of facilities, we rented a room in a co-working space — close but away from our regular office — to make sure we are fully focused on the activities and away from distractions of our day-to-day responsibilities. The room was equipped with WiFi, big TV screen (to share the sprint presentation, rules and exercises), and free coffee — very important to keep the boat moving ⛵️.

Day 1: Problem Space

Olav Ahrens Røtne

On the first day we basically followed the same schedule as stated by Knapp for Monday.

🏁 Define the long-term goal

To start off the day, I asked everyone: “Why are we doing this project? Where do we want to be in 2 years from now?”

Where do we want to go?

To define our long-term goal we need to answer to these questions in an extremely optimistic way. The aim of this exercise is to think about the best optimal scenario and how we see our project in the future — considering that everything will run perfectly fine, from beginning to the end.

💭 Define sprint questions

In opposition to the previous exercise, the sprint questions should NOT be optimistic but, instead, realistic. We should think about everything that could go wrong with the project. What would stop us from reaching the optimistic long-term goal we just defined?

What could stop us from getting there?

Anyone can end up with one sprint question, or more. We ended up with five questions, but they complement each another. The important thing is that the goals are clear to everyone and they are achievable within one Design Sprint cycle.

From this point on, every activity will focus on these precise questions. Simple as that. But we should never lose sight of the long-term goal, meaning that every decision we make during the sprint should, ultimately, pave the way to the most optimistic scenario as well.

🗺 Build a Map

Here we are going to draw a journey map of our users to identify places in the user experience that could be improved and/or hidden opportunities that we might have overlooked in the past. This map should be placed somewhere visible (on the whiteboard, for example) at all times until the end of the Design Sprint session, alongside the long-term goal and sprint questions. These elements will guide the decision making process until the end of the sprint.

The first thing we need is to list the different type of user personas — our actors — on the left side of the map. On the far-right, we will write down the end point of the user journey: what is the final goal that the users achieve whenever using our product? Note: This step is not necessarily a page or screen within the product, but an accomplishment, a realization.

A simplified version of the experience of a cancer therapy, from the Sprint Book

With these two structures in front of us, we can start building the user journey in between, linking the actors to the final goal. To understand exactly how it works, here is a step-by-step guide done by AJ&Smart:

👷🏽 Ask the Experts

Most of the afternoon is devoted to interviews with members from our sprint team and we also invited three experts to focus on three different topics about the product: Strategy, Voice of the Customer and Technical background.

Who? Our product manager (and also the Decider) was the first interviewee because he holds the strategic mindset from the market and the business perspectives. We also invited a Client Satisfaction Manager — who provides consultancy to many clients who use the feature we are working on — to be the voice of the customer. Before the Design Sprint session, we have conducted interviews and applied surveys with real customers, so we could bring some main points for the discussion in addition to this interview. Later on, we interviewed the lead developer of the feature, who knows all about the technical limitations, possibilities and the history of the product since day 1, in order to give us some technical perspectives and new ways of seeing the problem.

How? At each interview, every member would take individual notes in the form of How Might We questions: when hearing something interesting, each person would turn the topic into a question and write it down on a post-it. This practice should go on and on until the very last interview is over, generating a pile of post-it notes on the desk.

Here is Brittany from AJ&Smart teaching you how How Might We exercise works!

Next step consists in sticking all How Might We questions on the wall (or somewhere visible) so everyone can see it. Then, we grouped them into similar categories and provided labels on top of each group.

How Might We questions being filtered on the wall

After 10 minutes, we gathered all of our How Might We questions into different categories, ready to be prioritized and contextualized into our map. We made a voting session with sticky dots to choose which questions are the most relevant to answer our sprint questions and reach the long-term goal. After clustering dots on a few different How Might We questions, we filtered them on a separate wall in order to analyse how they dialogue with our map. Next, we placed these same How Might We questions on top of the map, to visually represent which part of the user journey they are addressing and, consequently, detect which part of the journey is more clustered (or not) with questions.

🎯 Target the Map

This is the last step of Day 1, where we decide what is the focus of our sprint.

Based on the How Might We questions, we detected the most critical path in the user journey and chose who are the most relevant actors that are impacted by our sprint questions. With this combination in mind, we were able to outline the most critical section of the map, narrowing our user journey to a very specific path. Ta-da! This is our target for the sprint, which represents the ultilmate focus for our decision making process and what the solution space should address from now on.

Integrate the most voted HMW questions on the Map and pick a target.

Day 2: Solution Space

Here we cover Tuesday and Wednesday from Jake Knapp’s sprint methodology. Now that we defined our goal, sprint questions and framed the user journey map with the exact questions we want to answer, it is the time for the creativity to flow! 🌈

⚡️ Lightning Demo

This is a short but an important exercise to start the day. Each of us brought some real-life examples that could relate to our problem somehow. We explained them out loud and/or conducted a demo to the entire team and later we sketched the solution on the wall so they are visible to everyone throughout the entire day.

Note: the examples should not necessarily be the same kind of product or business. In fact, the more different, the better — because we can see the problem and the solution spaces from a different standpoint, which helps the creativity at this point of the sprint.

✏️ 4-Step Sketching

The 4-Step Sketching exercise provides a reliable way for anyone to make ideas concrete and capture them in a simple sketch.

But… “What if I can’t draw?”

Don’t freak out! Sketching is, above all, about solutions. When your team evaluates the sketches to decide which are best, it will be the quality of the solutions that matters, not the artistry of the drawings from which they came. The idea here is to bring ideas to life. If you can’t draw (or rather, if you think you can’t draw), don’t worry. Not everyone is a great artist but everyone can, for sure, sketch a great solution. Sketching is about communicating: writing words, drawing boxes and expressing your ideas with clarity.

Therefore the 4-Step Sketching exercise comprises 4 different phases. You start with 20 minutes to “boot up” by taking notes on the goals, opportunities, and inspiration you’ve collected around the room. Then you have another 20 minutes to doodle rough ideas. Next, it’s time to go crazy and explore quick but different ideas with a rapid sketching exercise called Crazy 8s. And finally, you take 30 minutes or more to draw your your best idea(s) in a final well-formed concept wit all details worked out as much as possible. The final outcome, the Solution Sketch, should be followed by a storyline and a title. The title is important to translate the concept you have in mind and the story you want to tell the others. Plus it gives a more personal approach to you solution and it is easier for your team to remember afterwards, when voting time comes.

Our Sprint members studying the Solution Sketches on the wall

✍️ Storyboarding

At this stage we need to build a cohesive storyboard with all the winning solutions that will answer the sprint questions we defined earlier. As Jake Knapp writes in the Sprint book, it’s a great idea to begin the Storyboarding exercise by re-creating a real-life situation that we expect our target user will face when coming into contact with the product.

However, the winning solutions sketches we had were not a linear storyline but a multiple selection of different ideas from different solution sketches. How to solve that? Writing the 6 action steps!

One action step is every interaction the user has with the product, such as a click or tap in a digital product, or physical interactions in case of a physical product or protoype. During this exercise, the entire team will define together the first and sixth action steps. To structure the storyboarding, AJ&Smart suggest a particular configuration of post-its on the whiteboard in order to organise all the 6 action steps on a top-row and the number of the team member on the column on the left.

Later, each person in the team worked alone to write the remaining 4 action steps, one action step per post-it. After the time was over, each member sticked their post-its on the whiteboard and presented it out loud. Something like this:

AJ&Smart

We voted alone on the storyboard solution that was more consistent for our sprint questions and long-term goal. Later, the Decider had an extra vote to mark an isolated step from any other storyboard that could still be relevant. Then, we added this last action-step voted by the Decider to consolidate our final Storyboarding in a linear way.

Voilà! This was the last activity of our Design Sprint and we managed to decide on a common solution with the entire team 🙌🏽.

And now? How to know that our solution will work? Prototyping and testing! And this descriptive linear storyboarding is the perfect start for the designers to begin prototyping and, later on, testing it with real customers. I hope these guidelines are helpful for you too and don’t hesitate contacting me for any questions or improvement ideas! Have fun and keep up the good work.

And as a little treat for making this far in the article, I am sharing with you my presentation slides, ta-da 🎉 ! This is the exact presentation I built and used during this facilitation process and you are free to use it, share it and craft it as you like. Feel free to pass the knowledge on as well.

👉🏽 2-Day Design Sprint presentation slides here!

As a final recommendation, anything you need to know about Design Sprint, please check the videos and content from AJ&Smart. Enjoy and good learning!

Good design reflects the personality of good people working on it and we often tend to believe that our work is all about pushing pixels or refining prototypes. But I believe good design is also a seamless flow between teams that really care about the quality of their work, taking the time to think about the problem and decision processes so their efforts is deeply ingrained in the final result.

Kudos to the whole team and many thanks for this awesome experience! ⭐️

--

--

Bettina D'ávila
NYC Design

Designer, drummer & beer lover. Senior Product Designer based in Lisbon. Find me at bdavila.me