Making 5-day designs sprints more user-centred
9 minutes read
If you could choose one super power, what would it be? The power of flight so that you could ditch the commute? The power to control people’s minds so that you could get your boss to give you that long overdue pay rise? The power of X-ray vision so that… er, moving on. Personally, I’d go for precognition – the ability to see into the future. Imagine, not only could you make a killing at the bookies, not to mention the stock exchange, but you’d always know which products and ideas are going to take off long before they do. You could build a Facebook before Facebook, a Twitter before Twitter. You could wow your friends by telling them that you’d been creating flat designs, long before flat designs were a thing. You would always know which designs are going to work, and which ideas will win out. You wouldn’t be any old designer, you’d be a super-designer.
Alas, precognition will always remain science fiction, rather than science fact. However, there is one fantastic tool that can help you look into the future. Well, sort of. That tool, is called the design sprint. It won’t be any help when it comes to choosing who to back at the Super Bowl, but it will help you to answer critical business questions through design, prototyping, and testing ideas with users.
Design sprints are nothing new. Sure, they’ve become cool and trendy of late, but designers have been carrying out rapid design sprints for decades. Don’t believe me? Checkout this charming video from 1998 featuring IDEO undertaking a design sprint (although they call it a ‘deep dive’).
There is no set recipe for carrying out a design sprint, but ever since Jake Knapp and Braden Kowitz of Google Ventures shared their 5-day design sprint method (outlined in detail in their excellent book called Sprint) this has become the design sprint de-facto standard. Jake and Braden describe their design sprint as, “a ‘greatest hits’ of business strategy, innovation, behaviour science, design thinking and more – packaged into a battle-tested process that any team can use”. I’m a big fan of a lot of their process, and would certainly recommend getting hold of a copy of their book. However, at the back of my mind there has always been a niggle. Call it the curse of the UX designer, but I’ve always felt that their 5-day design sprint process is not as user-centred as it could be. Let me explain.
The usual 5-day design sprint
The usual 5-day design sprint process, as popularised by Google Ventures usually goes something like this.
Day 1 (Monday)
Get the team together and map the problem being tackled. Choose the target to focus on and speak to lots of experts to get insights (notice it’s experts, not users being spoken to).
Day 2 (Tuesday)
Look at possible solutions for the target, both within and outside of the domain and sketch lots and lots of ideas.
Day 3 (Wednesday)
Choose the best idea to take forward. Storyboard the chosen idea to start to bring it to life.
Day 4 (Thursday)
Design and build a prototype to further bring the idea to life. Fake it, don’t make it.
Day 5 (Friday)
Test the prototype with real users, using realistic scenarios. High five to celebrate another successful design sprint by team awesome.
What’s wrong with that?
Well, there’s a lot of great stuff in there, but do you notice that it’s not until the end that users are brought into the fold? There’s no upfront discovery work (unlike IDEO’s deep dive), only some conversations with ‘experts’. It’s a little like the old days when often the first time that users were involved in a project (if at all) was just before launch to carry out some usability testing. The risk with involving users so late on is that ideas and designs are invariably based on a lot of assumptions. Sure, it will only be 4 days before those assumptions are tested, but it strikes me as a less than ideal way to carry out user-centred design.
Good design is built on the solid foundations of insights, and those insights are best served piping hot directly from users. Having direct insights can make it much clearer which part of a problem to focus on, along with which possible solutions are most likely to work best. Equipping the team with first hand insights can also greatly aid the ideation process, not to mention build collective empathy with users.
To give them credit, Google Ventures do recommend interviewing users before design sprints, but this is work outside of a design sprint, which is always much harder to factor in. Not only are the entire sprint team unlikely to be involved, but because the target of the sprint has not yet been chosen it can be hard to determine the insights required and the best approach to do so.
A more user-centred 5-day design sprint process
So, what needs changing? Well the majority of the process is pretty sound. The key thing missing is some upfront discovery work to rapidly collect insights from users, and to help provide the solid foundations for the design work. Here’s what a more user-centred 5-day design sprint looks like.
Day 1 (Monday)
Start by defining the questions you’re hoping to answer, the users you’re focusing on and the problem being tackled. In the morning, you should build up a high-level user journey map and capture assumptions and hypotheses that you’ll want to explore in the afternoon.
Having agreed the problem and domain to tackle, the afternoon should be spent rapidly collecting insights. This means getting out of the office and interviewing and observing users, and generally finding out as much as you can in a very short period of time. It can be useful to pre-arrange activities, such as user interviews, and it’s a good idea to split the team up to cover more ground, pairs usually work well. Focus on the biggest unknowns and the most important user tasks. These insights will help inform the next 4 days of the design sprint.
Day 2 (Tuesday)
In the morning collate and review the insights from yesterday afternoon. A good way to do this is to map them against the high-level user journey, and to use different coloured Post-it notes for different types of insights. For example, orange for pain points and green for user needs. Review the high-level user journey map with experts to capture extra insights and to help clarify any outstanding questions.
In the afternoon, you’ll choose the target of the design sprint, review some existing solutions out there and start to come up with ideas of your own. You’ll typically want to focus on a key part of the user journey, or a promising opportunity, such as an unmet user need. Dot voting can be a good way to help chose the target. For example, everyone might be given 3 little sticky dots to stick on the area(s) they feel should be the focus of the design sprint.
Having agreed the target of the design sprint (and collected lots of insights for said target) the team should spend a little time reviewing and discussing existing solutions. These should include solutions from within the domain, but also outside. For example, interesting ideas from other industries and domains that could be applied here.
Armed with lots of insights, and examples from existing solutions, the last job for the day is to rapidly come up with some ideas of your own. Framing the problem as a ‘How might we..’ question can help. For example, how might we improve the checkout experience for supermarket shoppers? Design games such as Sketch Storming and World’s Worst can be a great way to come up with lots of ideas, the more the better.
Day 3 (Wednesday)
As a team, you’ll have come up with lots of ideas the day before, some good, some bad, some somewhere in-between. Having hopefully gotten a good night’s sleep everyone can come in fresh to reflect on the ideas generated and to choose the most promising one (or ones) to take forward. Once again dot voting can be good way to do this.
Having chosen the most promising idea the next task is to create a storyboard to start to bring it to life. A storyboard (see below) is a short comic-book style story outlining how a user might utilise the idea. Check out these example storyboards to see what I mean.
Creating a storyboard is a great way to consider how the idea would work in the real world and to start to think about what will need to be prototyped in order to evaluate the idea with users. I’d recommend limiting yourself to no more than 9 panels, keeping sketches basic, and the narrative short and sweet. Take a look at Nick Babich’s The Role Of Storyboarding In UX Design article for a good introduction to storyboards.
Having created a storyboard for your chosen idea, the afternoon should be spent sketching ideas for the UI. Focus on the screens and interactions that you’ll need to prototype in order to evaluate the idea with users. A good approach is to carry out multiple rounds of sketching, and to ask people to sketch on their own before sharing with the rest of the team. For example, ask everyone to come up with up to 6 different UI ideas for a page or interaction and then to share the best 1 or 2 with the rest of the group. As a group choose the ideas that work best and iterate.
Day 4 (Thursday)
STOP, it’s prototyping time… Today is all about creating 1 or 2 prototypes that can be used to evaluate your chosen idea(s) with users. I say 1 or 2 because you might want to test 2 different ideas, or even 2 different UI designs. Read my article called Why you should always prototype & user test multiple designs for why this is often a good idea.
Having created the storyboard and UI sketches the day before, the team should be in a good place to prototype just enough of the design to evaluate the idea with users. Just enough means just enough fidelity, just enough functionality and just enough screens and interactions. A good approach is to consider what you’ll want to run through in tomorrow’s sessions with users and therefore what you’ll need to prototype.
Creating a prototype in just one day is a big ask. I’ve found that a good strategy is to divide the work up within the team and to allow everyone to use their design and prototyping tool of choice (I tend to use Axure or Sketch myself). You should aim for medium fidelity designs. Don’t worry about creating pixel perfect mockups, but equally I don’t think that showing users some simple sketches is anywhere near as insightful as getting them to interact with something more realistic.
Day 5 (Friday)
Gulp, it’s show time. Today is the day that you find out how good your ideas and designs really are by putting them in front of real users. Fortunately, those ideas and designs are based on solid insights, rather than assumptions, so I’m sure there’s nothing to worry about.
Running a full day of user testing-like sessions can be hard work, so it’s a good idea to share the workload, or even to consider splitting out into sub teams in order to run more sessions. Where possible pre-arrange sessions beforehand and make sure that you’ve invited a good cross section of your users. Agree the structure of the sessions within the team and try to ensure that scenarios are as realistic as possible. Rather than passively presenting the design to users you should be getting them to actively experience the design first-hand. Take a look at my Usability testing hints, tips and guidelines article for more advice about running user sessions.
Tips for sprinting in style
Along with making the design sprint process more user-centred I’d also recommend these 4 tips to help keep your design sprints running smoother than a Rolls Royce Phantom.
1. Don’t’ try to compress a 5-day sprint into 1,2 or 3 days
I’ve tried running 2-day design sprints, trust me, it doesn’t work. There simply isn’t enough time to properly research, explore, design, prototype and evaluate an idea in less than 5 days.
2. Start at 10:00 and finish at 5:00 pm (17:00)
This is a tip I got from the excellent Sprint book. 10:00 – 5:00 pm doesn’t sound long but trust me, design sprints are high intensity work, so you usually find that you’re in dire need of a sit down and cold beer by 5 o’clock (or is that just me). Starting at 10:00 gives everyone a little time in the morning to get up to date with emails etc. and of course avoids the dreaded 9:00 am start.
3. Keep the design sprint team as small as possible
Small is good when it comes to design sprint teams. Small teams are quick, nimble and cheaper to ply with beer. Your sprint team should be more rugby sevens (i.e. 7 or less), less rugby union (i.e. 15 per team).
4. No laptops or mobiles in the room
Laptops and mobiles = distraction. It might seem harsh but frisking your fellow team mates for contraband laptops and mobile phones is a necessary evil if you want to maintain focus.
Conclusion
As I’ve written before, good design is built on the solid foundations of insights, something the common 5-day design sprint process does not provide until it’s often too late. By carrying out rapid discovery work upfront through this more more user-centred design sprint process you can build the sort of foundations required for great design thinking.
See also
- The Design Sprint (Google Ventures)
- Design Sprint Toolkit (Google)
- Maximizing The Design Sprint (Smashing Magazine)
- The Guide to Agile UX Design Sprints (UXPin)
- Every Week is a Design Sprint (UX Booth)
Image credits
Sketching workshop by Amy Goodchild from uxme.co.uk
Storyboard by Alexandra Mevissen
