Design Sprint: solve big problems and test new ideas
8 people. 5 days. 2 objectives. 1 challenge.
🇪🇸 First of all, do you want to read this article in Spanish? Check it here.
The Design Sprint is a methodology developed by Google Ventures, based on generating ideas and finding solutions through design, rapid prototyping and testing. The length of this process can vary from 5 to 3 to even a super sprint version of 4 hours.
While I explain my experience with the Design Sprint I will focus on the methodology and tools we have used during the process. I will intercalate some data about the project we did, but I’m more interested in the methodology as a way of learning, than the result and the case we have worked on.
DAY 1. UNDERSTAND
Long-term goal, sprint question, map creation, HMW and choice of target.
The challenge is to turn U2 into the band that will radically change the future of the concert concept.
For those who don’t know U2, it’s a band that has been active for 42 years, and has released 15 Lps, topping the ranking of earnings in 2017 according to Forbes with 118 million dollars. His penultimate tour, “U2 360º Tour” (with 110 shows), is the world tour with the highest revenue in the history of mankind (raised 736 million dollars), surpassing the previous record of the Rolling Stones. Their last tour “Experience + Innocence Tour” (2018) has 60 dates.
The first thing we did as a group was to define a goal that reflects the principles and aspirations of the team. With the exposed data, a brief debate and without any type of research we raised which can be the long term goal:
Let the concert experience begin at the moment you decide to go.
The next group step is to develop a list of Sprint Questions. A brainstorming of questions that arise related to the goal. Some questions were:
- Is it necessary to eliminate new technologies to enjoy it?
- Do I need to buy a ticket?
- What information is important to the user?
- Is it possible that the concert takes place at the same time in different places?
- Does the U2 fan wants a previous experience?
- Does the user like queueing?
- Would the user like to decide what the concert is going to be like?
- What if a deaf or blind person wants to go to the concert?
After the questions, we raised a key user and trace the User Journey Mapping. In our case, the journey starts from the moment our public hears about the concert until they leave it. We help each other with post-it to be able to iterate at the time of making the map.
With the map and the questions of the Sprint Questions that have aroused more interest, we reflect about the How Might We (HMW). With this technique we wrote in post-it in question from, starting with “How could we…?” All HMVs are organized by a theme.
Now it’s time to choose the objective of the Design Sprint. The HMW are voted in silence by marking them with stickers. The decision-maker, a person who normally knows the company or the problem well, has the power to determine the final objective when in doubt. In our case the two most voted objectives were:
How could we turn non fans into fans.
How could we implement in a physical experience a technological experience.
Then, in our case, we split into 2 groups that worked on each of the objectives. Our group worked on the first one.
DAY 2. DIVERGING AND DEVISING
Inspiration with existing ideas, unpolished ideas, Crazy 8 and definitive sketch.
The next day, individually, we did some research on existing ideas to help us with our goal as a form of inspiration to mix and improve them.
Our goal, in a nutshell, is to capture leads. So with this approach I visited, among others, webs of musical groups to see if they developed some kind of pre-concert action, creative webs about award-winning advertising campaigns and see if any of them had some relationship with music, events or concert, pages of new technologies applied to events or strategies for capturing leads with Instagram, in case that way could reach a younger audience. We shared our ideas and drew quick demos of the extracted information.
The next step is the Crazy 8. With a sheet folded into 8 parts, we individually timed one minute per box and 8 quick ideas had to be sketched without much detail.
With the ideas of the Crazy 8 we choose the one we find the most interesting or most viable and a final sketch is developed to solve the objective. Finally a name is assigned to each sketch.
DAY 3. DECIDE
Art museum, thermal map, fast evaluation, silent voting, supervote and storyboard
At the beginning of the day we pasted the sketches of the solutions on the wall with adhesive tape as an art museum. Later we developed a thermal map of the sketches. Silently and with stickers, the parts of the sketches that attract us the most are pointed out. We can put more than one sticker on the ones we like.
Then we briefly discuss the highlights of each idea and again we vote silently. The objective and the Sprint Questions must be kept in mind during the voting. Each member of the team chooses a solution and uses a gold sticker to vote for it. The decision maker, with the supervote, makes the final decision. In our case, there was a tie and he made the final decision, but they can completely ignore the vote.
Once we had the winning idea we made a small storyboard of the trip that our user may follow, from when he learns about the concert, until he leaves it.
To continue with U2, the winning idea consisted in an app in which the user, after purchasing the ticket, can listen to the group’s complete albums, play a microgame and have the possibility of getting a VIP ticket.
DAY 4. PROTOTYPE
Sketch and Invision
Now it’s time to materialize the idea. Each member of the team creates a prototype individually. In our case we used digital tools because it was an App, but you can use a variety of tools, including paper or cardboard. I worked with Sketch for the design and Invision for the interaction, the idea was to get as much Hi-Fi as possible. This was the result:
DAY 5. TESTING
Interviews and Maze
To validate the app I asked 5people to test the prototype in front of me and then ask them some questions.
I also used Maze, a remote testing tool that makes a heat map of the most pulsed areas and allows you to set targets for people who try it. I marked the following objectives: 1)Login in the app. 2)Listen to music. 3.)Play Quiz Song. 4) Login out the app.
The task was simple and almost everyone who tested it carried out the objectives without any problem. I remotely found the problem that the person testing it didn’t have all the information it needed and, for example, asked the prototype for more functionality or went off the path. These are some comments they left on Maze:
CONCLUSIONS
- Keep in mind the goal set in the Design Sprint. If you lose this goal during the process, the ideas that come out may have nothing to do with it and do not provide a solution to the challenge.
- Create and test what is really useful and meets the challenge. In my case, there was no point in testing the login and login out of the app. I actually set that goal because I had the screens made and to test the Maze tools.
- Mark the test objectives or make a workflow before prototyping. If you do this, you won’t make unnecessary or extra screens.
- Do what you want with the Design Sprint. The first thing this methodology does is to set some guidelines to get to generate ideas and find solutions, but the important thing is the ability to adapt and create your methodology with the different tools it offers.
