What design sprints are good for

You likely know the design sprint format already, thanks to the GVers’ evangelism: a five-day greatest-hits tour taking in collaborative ideation, sketching, prototyping, and user testing. Heavy timeboxing and lots of dot voting. It’s an intensive but effective format and, to those who don’t realise constraints force creativity, it’s surprisingly versatile.

Design sprints offer an apparently straightforward value proposition: get from idea to insight while skipping build and launch. High impact, risk reduction, learning at minimal cost – all perfectly aligned with current lean trends.
  
Sprints appeal to design consultants too. They offer clean engagement edges and require a complex skill mix – facilitation, strategy, prototyping, training – that commands high rates and opens the door to follow-on work. I love them, and they’re now the bulk of my consulting.

But I’ve done enough sprints to know the real value isn’t always as advertised. Clients naturally want to twist them for their own needs, to wring even more juice out of the process, despite the rigid structure. And that’s fine, because sprints are good at some unexpected things, and bad at some unexpected things too.
 

Design sprints are good for…

Generating momentum. Particularly in larger companies, design and innovation can appear sluggish, but a single week-long sprint lets you temporarily hush whispers of vapourware and show something – real pixels! – that represents at least a decent first thought. This makes sprints particularly valuable for new teams or leaders who want to hit the ground running. It can also galvanise teams to move quickly, setting examples of cadence and establishing a norm of getting assumptions out of heads and into product explorations. The next challenge is to maintain momentum while fending off overexcited expectations.

Highlighting the scope of the design process. Particularly for stakeholders who see design as all downstream aesthetics, a sprint demonstrates that design decisions run all the way through a product, like mould in a good cheese. Your sprint will show the value of broad input from outside PM and Design. Engineers, writers, and support staff should at least feature in Monday’s ask-the-experts interviews; better yet, they should wield pens on Tuesday and Wednesday. If your sprint goes really well, your client will spiral into existential crisis about the difference between design and product management, and you’ll know you've earned your money.

Developing the team. Best to split up prototyping duties rather than pile them all on the designer’s shoulders. So you’ll need to teach some Keynote prototyping: just enough that your teammates will add it as a skill on LinkedIn. You’ll also quickly discover when you don’t have the right people or skills in the room. Perhaps visual design becomes a bottleneck, no one wants to commit to copywriting, or the real decision-maker isn’t available: these problems won’t go away unless you address them.

Provoking core product issues. The interesting questions about a product sometimes only surface once you start designing. A design sprint is an exploratory drill for complexity – you may discover vast reservoirs of viscous complications, or your gushing wells may suddenly dry up. This is where an experienced team helps: red flags and here-be-dragons hunches are useful signals. By the end of the week, you may all be convinced the project doesn’t have legs. Usually no one will say so on the spot, so as not to repudiate a tough week, but if the week’s primary outcome is to shitcan the project, that’s great. It only took you a few £000 rather than a few £000,000.
 

Design sprints aren’t good for…

Reliable product design. Sorry. Even though you have to select tight boundaries for your prototype, you’re still going way too fast for considered design. Sketching, writing, and prototyping 10–20 pages (you’ll end up with this number, even if you try to do just four) in a day or two is a dangerous pace. Even the most experienced designer will find her sketches don’t always translate to the screen – in-tool juggling and shuffling is a natural part of the design process, and from my experience deserves a minimum of ½ day per page. The sprint offers no time for design critique and no time for polish. Nothing I’ve done in a design sprint is portfolio-ready. And that’s entirely the point. A sprint is the opening gambit of a long, complex game – a tool of provocation, not delivery.

Proposing sophisticated user research. Design sprints reflect the learn-through-making ideology that dominates tech culture today – hence Friday’s user tests. But the week does little to suggest opportunities for deeper research such as ethnography, longitudinal learning, ethical inquiry. Instead, a sprint suggests more of itself: more making, more testing, more iteration. If you’re not doing any user research that’s a decent start – you’ll at least learn some fundamental test facilitation skills, although probably not so much the synthesis and analysis, which contain the real flavour and demand practice. But beware the limitations of user tests. The design sprint doesn’t really shine a light on more sophisticated research methods, and nor is it meant to. Hire a researcher.

Answering deep product-market fit questions. A sprint will absolutely provoke these questions, and then leave you dangling. Remember this is a design sprint, not a product sprint. Don’t expect to learn much about market sizing or segmentation, customers’ propensity to pay, business model viability, or your propositional appeal against competitors. There are better tools for that. You can try to get some answers in the tests, sure, but it’s all hypotheticals all the way down – "would you pay for this?" – which are subject to all sorts of bias and divorced from true behaviour. Proper market research this is not.

Getting the green light. The only acceptable approval decision after a design sprint alone is “Let’s not do this project”. Unless the project is cheap and very low-risk (in which case, you wasted a week anyway), a design sprint won’t give you enough reliable information to approve a project. Address the previous paragraph first.
 

Some bonus tips because why not

Prototype in high fidelity. As high as you can. Real text, real images, believable visual direction, colours, type. I’m less and less convinced by low-fidelity testing: the mental gap is just too large. And why would you pass up the chance to learn about people’s responses to brand, to copy, to aesthetics?

Keynote doesn't handle scrolling well, so add a fake scrollbar for desktop-and-mouse-based prototypes. Keep it simple. It’s tempting to add a thumb (that’s the bar in the middle of the scroll track), but users will try to drag it. Up and down arrows are fine.

Amend your Keynote toolbars. Put Group/Ungroup, Front/Back/Forward/Backward, Copy/Paste Style, Mask, and Lock/Unlock in there. Like this. You'll use them a lot.

Use Keynude to override Keynote’s woeful default shape properties. For some reason I’ve found it makes some of the Keynote UI appear in French. Learn French if this is a problem.

Have a writer in the room.

In-house tests are better, but you can export your Keynote to HTML, throw it on a server, and run passable remote tests via Skype etc.

Open your test with a blank Google page / App Store / whatever page and ask users how they’d search for your product. This helps you learn about their language and existing mental models. Show them a dummy results page that links to your prototype, and away you go.

If you liked this and want someone to run a design sprint at your company, I offer a six-day consultancy package – ½ day set up, 5 days onsite (anywhere in the world, subject to visa bits), and ½ day for review, wrap-up, and next steps. Contact me to find out more.