Learn to develop better products using the Design Sprint: Day 1

What is a Design Sprint & First day of the process

We’re Novateva, a software development company. Our main focus is to combine cleverness and creativity in order to turn our clients’ needs into solutions and their ideas into technological products.

The first time we heard about the Design Sprint it was in a paid e-learning platform where we were looking for new ways to improve our processes and bring value to our clients. The speaker was very enthusiastic, explaining how this method could help us get better insights faster than we would otherwise be able to.

If you are reading this then there are two things you should know: First — We’ve been involved with this method for a while and; second — We’re happy to share our experience with others because it’s genuinely fun working collaboratively on projects where everyone is passionate about making something great happen together.

So… What is a Design Sprint?

The design sprint is a 5-day process developed by Google for solving problems, and it’s built around rapid feedback and collaboration between you and your team members.

It is a design process that helps you solve problems and create an MVP by breaking down complex tasks into smaller ones. The idea behind this process is simple: break down the idea into its smallest parts, then take each part and focus on how it affects the entire solution. By doing this repeatedly until you’ve reached your goal (or gotten closer), you can create an entirely new way of thinking about an issue or problem — and ultimately come up with solutions that are more effective than before.

However, the design sprint is not a magic formula.

Its goal is to be part of a process backed by development and research to be able to better understand the target market and test ideas. To do this, they have established a methodology with five clear phases:

• Exploration

• Sketch

• Decision

• Prototype

• Validate

We’ve been working with the Design Sprint method for some time now, and we learned a lot from our first prototype. The first Design Sprint prototype we built was a little rough around the edges, but it did exactly what we wanted it to do: show us how our product could be used by end users. This process is applicable to any type of client, from individuals to global corporations and everything in between.

It is suggested to use it when you wish to start from scratch and bring an idea to reality, also when there is a significant chance of failure or if you want to test a new feature for a product.

In this article we are going to talk about the first day of the design sprint, its process, and the tasks we do on that day.

Map & Sketches.

The first day of the Design Sprint is a full day dedicated to getting everyone involved in the process, define the user experience map, identify the focus/most critical part of the design sprint and make an outline of the product individually.

But, first:

• You need to get everyone’s schedules synced up

• Send out an email reminder, so people know when they need to be ready to go

• Create a shared document with each team’s tasks and materials. We recommend using Miro, that’s what we use. Our board looks something like this:

Novateva's Miro board

All team members must be working on the template (here, we are going to fill all the suggestions made during the DS).

Before starting this process we need to define a set of roles:

• Facilitator: Is the person in charge of keeping track of time and avoiding unneeded discussions.

• Decider: the person with the highest level of responsibility, and the one who makes the decisions of the project. This role belongs to the client (in case he agrees on taking part in the design sprint); otherwise, it belongs to the one who interviews him.

• Experts in different areas: interdisciplinary teams help to reduce biased results.

• Assistants: We added this role to our Design Sprint process because we believe that assistants make the process go more quickly and smoothly. They are in charge of moving the post-it notes, categorizing them, and anything else that may be required throughout the process.

  
  

While it’s important to have a cross-functional team, it’s also essential that the Design Sprint has a mix of experience levels and skills. A good design sprint will have participants with different perspectives who bring their own backgrounds to the table.

We start by interviewing the experts:

For the most part, the experts are the clients or the person who has previously interviewed the client, lead techs, designers. The facilitator gives them 20 minutes to speak, and if that’s not enough it can be extended by 20 more minutes.

The whole idea of this process is understanding and to do so, we ask triggering questions such as:

What problems are you looking to solve with the product?

How does your customer currently solve this problem?

What are the expectations of the user(s) about the product?

And many more questions that would help us get the idea. If there’s more than one expert, this dynamic turns into a conversation. Any team member can make triggering questions and said questions must be previously formulated. It’s crucial to get some of this information from them, but sometimes there are no answers yet, and so we need to make our own assumptions based on what we know about their business or what we think their needs might be.

Meanwhile, everyone else should be writing notes (all notes should look the same on post-it’s and markers with the same color) with the prompt = “How Might We do it”. The “How Might We = HMW” method is used to obtain opportunities during interviews allowing to turn weak points and ideas positively. The main idea is to seek opportunities instead of solutions. This is an expansive thought exercise destined to avoid the team from coming to premature solutions.

For later voting, these HMW Notes should be organized into categories. That is handled by the assistant. Once moved to the main worksheet, the assistant must display them using a readable font-size.

For 10 minutes, the team reviews the notes categorization made by the assistant. At the beginning, there may be default categories, but you can add new ones if needed.

The voting process it’s really simple:

All participants have 2 votes (blue ones) and the decider has 4 votes (red ones). You can use any color you want, but we chose those two. The facilitator should set a timer for 5 minutes, and during that time, everyone on the team reads the post-it notes and votes on which HMW notes they prefer to work on during the design sprint.

The notes chosen to be worked on during the design sprint week are those that have received at least two votes and preferably more.

After that, we set the long-term goal

Which represents the project’s future if it succeeds in a few years. Starting with the words “In X years from now, the goal is…” on a post-it note, each participant writes their long-term goal.

The assistant takes the notes and puts them on a board, using a readable size.

The facilitator should read the long term goals out loud and set the timer for the voting process:

Long-term goals are subject to vote, each participant has 1 vote, but the decider has a bigger sticker to differentiate their vote. This process should take 5 minutes.

The decider ultimately chooses the long-term objective that makes the most sense in light of their future goals.

Later we define the Sprint Questions.

Which represents the project’s future if it succeeds in a few years. Starting with the words “In X years from now, the goal is…” on a post-it note, each participant writes their long-term goal.

The assistant takes the notes and puts them on a board, using a readable size.

The facilitator should read the long term goals out loud and set the timer for the voting process:

Long-term goals are subject to vote, each participant has 1 vote, but the decider has a bigger sticker to differentiate their vote. This process should take 5 minutes.

The decider ultimately chooses the long-term objective that makes the most sense in light of their future goals.

Later we define the Sprint Questions.

These are the ones that come after setting the long-term goal. They contain useful information about how the project could fail. The idea is to turn the negative comments into opportunities. Members must make 3 questions starting from the premise “How this project may fail?”. Then, each one of those questions must be reformulated into something proactive or into opportunities using a sticky note. Questions are subject to vote in a 5-minutes process: each member has 2 votes. At the end, the decider chooses a question with a bigger sticker.

User experience map.

At this point, everything that has been decided converges. The objective is to define, step by step, the user’s flow at the most critical part of the application. This flow is going to be the prototype.

The process starts by setting a timer for 20 minutes. (Add 10 min. if needed).

In a white board, add the actors that are going to participate on the critic flow to the left. Then, place the actors’ goals to the right.

Afterwards, We need to fill all the steps needed so that the actors can finish the flow, from left to right.

The assistant copies and pastes all the HMWs, Sprint questions and long-term goals for their use in the map

Once the flow chart is finished,

A long term goal is put in the top right corner.

The most voted questions and votes are placed in the parts of the flow where it makes sense to add them.

Your user experience map should look something like this:

Quick Demos

The next stage is to look for examples of similar situations that have been solved in impressive ways. The facilitator should set a timer for 40 min. Every member looks for inspiring examples that contribute to the main idea and posts them on the designated work area, along with the corresponding screenshot, URL, and reason why it was picked.

It’s important to search for examples outside the main project’s field in order to obtain creative ideas.

All the examples they found should be explained in 5 to 8 minutes per member.

We finished our collaborative work, but that doesn’t mean we are done yet.

It’s time for homework:

Individual work is now due from each Member on Day 2. This process it’s what’s typically called “Sketches”.

This assignment has a certain set of tasks that must be completed first:

First, each participant individually reads everything that is written on the board and makes notes about the long-term goal, the Sprint questions, and anything else that they find interesting. Later, they will generate ideas by taking a sheet of paper and outlining everything that occurs to them in accordance with the notes they previously made.

Then, using a piece of paper that has been three times folded, each participant draws eight more detailed renditions of the original idea that was previously developed. Taking one minute for each concept, this process should take eight minutes.

Those first steps are necessary to get the final result of the day: the Solution sketches. Each team member is required to fill a work space with a solution. The current answer must, in contrast to the others, be realistic and understandable enough to explain itself. Each work area features a replica of a screen for various device kinds as well as usable components. Each participant must leave notes where they feel they are necessary.

The final output of the first day should look something like this:

We finish this activity by making the decider pick the flow’s critic part (in general, it’s the one with more notes, although the decider is free to choose any).

And by doing that, we are done for the day.

You are not alone, we know that it’s demanding.

We know that the first day of the design sprint can be a little overwhelming. You’re facing hundreds of choices, and there are so many things to think about! But remember, there are no wrong answers — just different ones for your team. Design sprints are a blank canvas. It is your chance to show your skills, but more importantly, it’s a chance for your team to solve the issue your client has efficiently. It’s also an opportunity for you to connect with the team and show how much passion you have for the project.

In conclusion:

Day 1 of a design Sprint is all about understanding and outlining the solution.

• Understanding the problem: What it is and why it matters.

• Understanding the context: Where you are in this journey, how this project fits into its bigger picture, any relevant data or stories that might help guide your thinking.

• Understanding goals: What values do we want to achieve by working together?

• Outlining solutions: Building a preliminary solution to the problem your client has.

We hope this blog post has given you a better understanding of how the first day of the design sprints work, and the process behind them. If you want to learn more about what makes a successful design sprint, and the following days of the process, we would be posting part 2 of this design sprint series here on medium.