Design Sprint — How we redesigned a shopping experience in just 4 days
This is a summary of how I conducted the first of several design sprints.
The tl;dr
- Design Sprints are awesome
- I learned how to organize my first sprint from scratch
- I led several other sprints after that
- Apart from the Facilitator role, I also led the tests interviews
The context
Our methodology was failing. It was strange because everything was made for us to succeed. Or so we thought.
We had a simple assignment: rethink the current shopping experience of the CRM tool of a telecommunication company. We had the resources: 2 UX designers on the job. We had a (very tight) deadline: four weeks to get a prototype running. And we had a schedule: a new presentation to all the stakeholders every Friday to show the progress.
But on the 3rd Friday, we were back to square one. The meetings were not helping: after our presentation, the management would share their thoughts and the architect would expose their technical limitations. A back and forth would follow for two hours with nothing coming out of it, except “Well boys, I think you should show us something different next week.”
With one week left, we had to do something. I came up with the idea of trying a Design Sprint. If you’re not familiar with this methodology, you can learn more about it here and here. But if you are really interested, you have to read the book.
I had 3 days to prepare everything. I worked over the weekend. Saturday I read the book. Twice. Took notes. Sunday I prepared a slick kick-off deck breaking down everything that will happen during the week. Monday I prepared each exercise and bought the equipment.
I put together a team of nine people: the product manager (who will be the decider), an architect, a business analyst, four users with years of experience using the current application, one UX designer, and I, who will endorse the facilitator role. Those nine people will be in the room for four straight days. Other people will also step in the room from time to time as experts, to share their input.
The objective of the sprint was simple: design in four days what we could not design in four weeks.
The challenge
Before we dig into the details of the sprint, let me give you a bit of context about the project. By redesigning the shopping experience of the current CRM, the goal was to allow the employees to sell cellphones and mobile plans more easily. The existing system was slow and clunky. We could basically burn everything down and build the interface anew. But within the technical constraints of the existing back-office. The front-end could change but not the back-end. This last part was the main reason why no progress had been made so far; Week after week, we were discovering new technical limitations.
Day one, a great start
With that in mind, let’s enter the new realm of Design Sprints. Day one was a tough one. I had to introduce the team to this new work method. And since we started on a Tuesday, we had to compress two days into one.
“Hello everyone and welcome. Now please give me all your cellphones and laptops. It’s not a holdup, just a sprint, you will get back your electronics at the end of the day. Or at any given time if you really need to make a call or send an email, as long as you step out of the room.”
This may seem like a gimmick, but this no-phones-no-laptops rule actually gives momentum to the process.
In the morning, we talked about our goal. This was pretty easy because we already had a good understanding of what needed to be achieved. After a quick round table, we ended up with a clear objective and seven questions to address throughout the rest of the week. Our goal was as follows: make the shopping experience easier and faster and make up-sell possible.
Next was the user journey mapping. This is where the magic happens. It is the backbone of your project: on a big white board, you lay out your starting point and where you want to go. Then you fill everything in between.
You start with the actor(s) on the left and you put the result on the right. Then you add the different steps in between that you connect together using arrows. The map should be simple and contain no more than 15 steps.
After a slow start (which I think is the least that can be expected, considering nobody had done that before), the team built a very well structured user journey. We took different approaches: does the client want to buy a new phone first or is he more interested in the plan? And what if the client already has a phone? How do we bring these three scenarios to the same conclusion?
During this phase, which took exactly one hour, we tried not to think too much about the technical constraints, and we focused more on the ideal path for the user. As I was leading the discussion, I suddenly realized one thing: how critical it is to have a diverse team. A team that brings different perspectives, different expertise, and skills. Everyone’s insight is valuable. Having a business analyst, a technical architect, a user, and a project manager in the same room create a collaborative mood.
Next, the “How might we” questions. Every person describes the challenges he or she is facing and everybody else takes notes in the form of a “How Might We” questions. This note-taking format suggests that a solution is possible. It is very powerful to see a challenge positively.
Once again, having people bringing different expertise makes a much complete picture of the project. Once everyone has finished talking, we organize the notes by category. That’s a huge mess at first, but a fun one. We cover the wall with sticky notes and the group quickly figures a way to put the mess in order. Once everything is organized on the wall, it looks really nice. The team takes a few minutes to review what has been said and vote for the most interesting notes. Then the decider chooses the ones we keep.
With the selected notes in hands, we get back to the user journey map. We pinpoint them on the board, next to the corresponding step. The HMW questions will need to be answered by the solution sketches later on.
After lunch, it’s time for the lightning demos. Each person gets in front of the computer and presents an inspiration taken from a real website. I gave the team the lunch break to prepare for this. It’s enough time to come up with one or two examples. The examples can be taken from the competition or from websites and applications outside of your industry. The goal here is to see how other companies handle the same challenges that your team is facing. The demos should not exceed 5 mins each.
Here comes the big one. It’s sketch time. Everybody take a pen, a sheet of paper and starts taking notes. We use everything that has been said so far: the sprint questions, the user journey, the HMW notes, and the lightning demos. Notes turn into ideas. Ideas into sketches. And the sketches into wireframes. Apart from the UX designers, the people in the room are not usually used to draw on paper. It is likely that the last time they draw something was in kindergarten. So expect a few raising eyebrows when you explain that they are going to spend an hour sketching.
Drawing is like riding a bike. You never completely forget how to do it. This exercise creates amazing results. Everybody played along and the solutions were on point. At this moment, I realized that it is foolish to think sketching should be reserved to UX designers. To be fair, the user’s sketches were messy and difficult to understand at first. But the concepts they came up with, were far more interesting than the ones we, the UX designers, were able to produce. I think it is because their designs are fuelled by years of using the application.
Day two, where the decision sticks
It’s a new day, we start with clear minds. The process of decision making is made super easy. It takes all the endless talk out of the equation with a simple but yet super efficient tool: a colored dot sticker.
You put all the solution sketches on the wall. Like in a museum. Everybody gathers around and discover the solution drawn by others for the first time.
You use small dot stickers to create a heat map: every time you see something interesting on a design, you put a small dot sticker next to it.
Then there is a speed critic where the facilitator narrates each sketch and calls out standout ideas. After that, the team calls out the standout ideas that the facilitator missed.
Then there is a silent vote where you vote for your favorite design with a big dot sticker.
Sometimes you have a clear winner, sometimes two designs stand out. That’s the decider role to choose between the two or he can decide to test the two.
In our case, we had one solution to test, and it was now time to put it in perspective with a storyboard. The storyboard helps you imagine what your finished prototype will be like. That way you can anticipate the problems before they arrive.
It also helps you understand how the user journey fits into the different screens that will be in your prototype. That way, the UX designers can assemble the interactive prototype faster. By knowing how the pieces fit together, you don’t need to think what the next step should be.
The storyboard
We ended up with 2 distinct paths: whether the client wants to shop for his cellphone first or whether he wants to choose his plan first. Until now, we rejected the idea of having two paths because we thought it would give us twice as much work. But here we realized we could just use the same five screens in the two different paths, by organizing them in a different order. And only two screens needed slight modifications for the second path to work.
Day three, ready to prototype!
While we were prototyping, the users were writing the two scenarios we were going to use the next day. Earlier in the week, we recruited 5 users of the current system to come to play with our prototype.
Day four, test and take a step back
The setup for the tests is as follows. Two rooms, one big and one small. The test is conducted in the smaller room where you can find a table, two chairs, and a computer. The chairs will accommodate the tester and the interviewer. The primary role of the interviewer is to make the user feel at ease and guide him if he’s lost. He also explains all the parameters of the test. The main are:
- You are being recorded; It helps us collect the data
- You are not the one being tested, the application is
- We are using a prototype so expect a few bugs
- But feel free to click anywhere you want
The observation takes place in the big room where the whole team gathers around two TV sets. The first one displays the user’s screen. The second shows the user’s face. That way we can hear and see him react in real time.
Each test lasts between thirty and forty minutes. Most of it is the user testing and describing what he sees or understands. There is also a part of questions and reviews.
At the same time, in the big room, nobody talks. Rather everybody writes. The people gathered in the room listen, observe and take notes. On sticky notes. Each sticky is there to describe a positive or negative observation. Once the note is written, you put the sticky note in front of you and you continue the observation. At the end of the test, you stick your notes on the board in the different sections that have been determined beforehand.
A quick side note, you can always conduct more than five tests. But I have tried that approach in another sprint and I can confirm that you will not learn a lot more. Five tests seem to be the sweet spot. After five, the users usually repeat the same positive and negative points others have found before them.
The conclusion
The tests are over. And the sprint almost is. Now it is time to reflect on what has been achieved during the week.
To do that we get back to the first board. The one with the sprint goal and the sprint questions. Out of the seven questions, we were able to answer positively five of them. The two remaining will need some rework.
As for our goal, we were able to reach it, except for the up-sell part. But we figured early in the sprint that it is a subject for a whole sprint in itself.
All in all, it was a busy and productive four days. The results were spectacular. Of course, it is not easy to have that many people clear their schedule for a sprint, but if the challenge is worth it, you should really consider it. It has exceeded our hopes and got us results fast. And the management was happy.
So happy that they wanted to do another. That’s how good it was!
And we start again
The end is just a new beginning. Sprints are made to iterate. We did successfully answer a lot of questions with this one. But not every aspect of the shopping experience was covered. Sometimes it’s okay to do another sprint right away, but it doesn’t mean you need to do all the exercises again. You pick and choose what works for you and do a shorter one. But for your first one, if time is not a constraint, consider doing a full week.
