How we do design sprints – deciding, prototyping, and testing days part 3
People talk about the “Goldilocks” level of fidelity, high enough to look real but low enough to be able to make it in a day
In my last post, we discussed how to start a design sprint week off with activities on Monday and Tuesday to understand the problem and start creating solutions. Next we need to decide a way forward, make the prototype, and test it.
I hope you have some coffee!
Wednesday – decide
We’re now midway through the design sprint. It will have been hard work, but fun, to get to this stage and we’ll have a collection of great solutions.
Today we’ll critique the solutions and decide which ones can best achieve our sprint goal. In the afternoon we’ll take our preferred solution sketches and combine them into a storyboard for a single prototype.
The art museum
Deciding which sketches are best can be a hard and time consuming task. And making sure everyone has a voice can go against the fast paced, quick decision making ethos that design sprints need.
Knapp and Zeratsky set out a sticky decision activity in the Sprint book, a multi-step process to draw out a good decision quickly. I like to refer to it by the first activity’s name, the art museum. Here’s why.
The facilitator will have collected all the sketches and displayed them in a physical or virtual space creating your own mini art museum. The team then spend time looking at the solution sketches individually, without the benefit of the creator explaining things or answering questions.
This might seem a bit unfair but it mirrors how users will interact with the solution, with no prior knowledge or understanding of it. What they’re interacting with needs to be self-evident or at least self-explanatory.
Dot vote
This is a nice initial activity. Simply look at a sketch and put dots by the parts you like. You can put more than one dot on the most exciting ideas and there’s no limit on how many you can use.
This builds up a heat map of what the team think is good.
At the same time, if you have a question or concern, put it on a post-it next to the sketch. Then move onto the next sketch and repeat.
Facilitators beware: the heat map won’t show you why people like an idea. That’s something we do in the next activity. To keep our momentum, we follow a set process with a time limit for each stage.
Speed critique
The team now look at each solution sketch together, call out the parts identified as important by the dot voting and give them a short name that captures the main feature or idea. At the end, make sure there’s time to review the questions and concerns people have raised.
Once this is done you should have a record of the best ideas for that solution sketch. Move to the next sketch, and repeat.
For virtual spaces you can usually allow the rest of the team to follow your view of the board. Together with timer features, this can actually make the critique feel easier to manage than being in the same room together. If you have people visiting this session as a cameo, make sure they feel they can participate in the best way possible.
It’s important to give people a chance to address questions and talk about any missed ideas. This helps you get the most out of each solution sketch, and also means that people feel they’ve had a fair chance to articulate their thoughts and explain their sketch.
But be wary of rabbit holes and set them to one side to maintain your focus. Make sure the team know it’s okay to say “That’s a good point, let’s talk about it during the coffee break”.
Straw poll
After this fast-paced session, there are likely to be lots of thoughts and opinions in people’s heads that they’d like to discuss. To keep this discussion focussed and give it some structure, everyone is given one vote to place on their favourite idea or sketch.
By giving each team member a single vote, we’re asking them to prioritise the solutions. Remind everyone of the sprint goal and questions, ask them to give risky ideas preference, then set a timer for 10 minutes and ask people to decide but not place their votes until the timer goes off. We want to make sure people are deciding independently and not influenced by others.
When the timer goes off, the team then place their votes and are given time to briefly share their reasons. This makes sure that everyone has an equal voice.
Decider vote
The next stage is to get the decider to, erm, decide. The decider is like a benevolent dictator, they listen to their people but then decide the course they will follow. It’s important to remind the decider that the straw vote shows how the team feel. But they may want to take the team in a different direction and that’s okay.
Give them 3 special (bigger?) stickers and get them to vote. These winners will be turned into a prototype, the others could get pulled into our prototype or saved to explore in the future.
Storyboard
We now need to bring the solutions and ideas we want to explore into a unified prototype. We do this by storyboarding.
The goal is to tell our story, explain our ideas, and show our solutions in a logical and linear fashion. We need to include just enough detail so it’s clear what goes where when the prototype’s getting built. Rough text, headlines, buttons and so on are useful, but don’t get sidetracked by writing all the text.
Start by drawing a 4 by 3 grid which we’ll then populate with the steps a user will go through. This will help the team focus on the important things. You need a tight prototype that someone can work through in less than 20 minutes.
Begin by thinking about the first thing someone will see or do on the prototype and how the prototype will end. This gives us a good starting point and a target to work towards, making it easier for the team to fill in the middle part. You may find that you can use post-its from the solution sketches or the journey map.
Leave a couple of frames empty at the start of the storyboard so you can show how the user has arrived at the prototype. This could be someone mentioning it on Facebook then the user clicking the link, or an online search. This is useful for research participants because it grounds the prototype in something they’re familiar with.
Thursday – prototype
The week so far has been leading up to this moment.
In the first part of this blog series, I explained how design sprints save time and money because we can test something without building it. Our job today is to make something that looks like the real thing, a fake. We’re making a sci-fi prop for the movie, not the working teleporter.
Before you start, it’s useful to go over a few things to set people’s expectations.
All prototypes are disposable
It can be really hard to accept that you might end up binning your prototype. It’s fine if the solution doesn’t work as the design sprint has still served its purpose and saved a lot of time and effort in the long run.
A side benefit of embracing this is that you’ll find it easier to manage the effort put into the prototype. Avoid the tempting extras that won’t help us to test the concept and will take up lots of your limited time.
Do the minimum to learn what you need
We’re making this prototype to test something, you don’t have to make everything to find out if a concept is valuable to users. Have a tight scope and be explicit about what you are and are not going to prototype.
It needs to look like a real thing
We’re articulating an idea and giving it a concrete tangible form. We’re removing the guesswork so what was in our heads earlier in the week is reflected in the prototype. It will become the physical manifestation of that idea.
We don’t want people to look at the prototype and imagine what it can be, they need to look at it and understand it as something real so they respond to it in an honest way. People talk about this as the “Goldilocks” level of fidelity. A high enough level of fidelity so that it looks real but low enough that you can make it in a day.
What will you prototype with?
The team need to produce something convincing, so the medium of the prototype is important. For the purpose of this blog post, I’m focusing on prototypes of digital things but Knapp and Zerasky discuss other tools in the Sprint book.
There are loads of prototyping tools out there: Figma, Invision, Marvel, Sketch, Protopie, the GOV.UK Design System to name a few. There are also lots of things that you might not consider prototyping tools like Miro or Google Slides, but with some clever use of links you can make something suitably convincing.
How will you build the prototype?
Traditionally people are given distinct roles to make, write, gather images or text and stitch the prototype together. But dividing jobs like this hasn’t worked well for me in the past.
I prefer to put people into pairs and create a really low fidelity prototype to begin with, blocking out one section of the storyboard at a time. Once all the sections are completed, the whole team can run though this initial prototype together, give feedback, and make tweaks.
This provides an early opportunity for your user researchers to feed in, and there’s a lower cost to making changes and correcting your course.
The next step is to increase the fidelity of the pages. Spend your time strategically so that you get to the Goldilocks level of fidelity on the most important pages first. As this point you might find it useful to assign people to specific tasks such as copy writing, gathering images or other assets, building the page, or making it into a clickable prototype.
Have a trial run
Aim to have a trial run of the whole prototype a couple of hours before the end of the day. It doesn’t matter if the prototype isn’t 100% finished, there will be enough content for the team to see what will happen on the pages. This will make sure your user researcher has what they need to test with users tomorrow, and you still have time to make some changes.
Friday – test
On Friday, your user researcher will come to the fore and guide you through the day’s events. Nielsen has shown that you can find about 85% of problems with 5 user research sessions. After that, the rule of diminishing returns applies and what you learn becomes disproportionate to the amount of effort required.
How to get the best out of your user researcher
A wise person once said, “User research is a team sport”. Friday is the user researcher’s time to shine and for everyone else to support them.
Be clear about what you want to learn and who your users are
Early on in the week we set a goal and identified a series of questions that we wanted to answer. We then identified the part of the journey that was most valuable for us to focus on and picked a single type of user to look at. We know what we need to learn and from who, we should write this down and keep refining it as we learn more.
Give your user researcher time to write a script
Once your user researcher knows what you want to learn and has seen the prototype, they will usually prepare a script for the user research sessions. This ensures a level of consistency for the sessions, but is also flexible enough to deal with the unexpected or explore interesting points in more detail.
Be aware that there might not be many working hours between finishing the prototype and the first user research session. It might be worth trying to start and finish early on the prototyping day, or sometimes research sessions are scheduled for the following week. While the latter falls outside the traditional 5 day sprint, it removes some of the pressure and can make sure you get the best from your team.
Support them during the interviews and after
Volunteer to observe and note take during the sessions so your user researcher can focus on the moment and ask those pertinent questions.
Note taking isn’t a hard activity in itself and you don’t have to capture everything that’s said. Be opinionated and pull out what you think is important. Don’t worry if you miss something, sessions are normally recorded and there’s usually more than one person observing.
After the interviews, your user researcher may want to spend some time discussing the highlights and what those observing found important. They’ll then pull out some patterns, insights, and recommendations before playing the information back to the team. Again, this is something that takes time but is glossed over in the Sprint book. Don’t rush your research, give it the time it deserves.
Look out for my final post in this series later this week.