Sprinting for design
When introducing a bold, new method of doing things, you’ll face pushback. “What for?”, “What’s wrong with the way we’re doing things? We’re agile!” — those questions will be your trusted, if annoying companions. Showing that you’re doing something for a purpose is paramount to having any impact at all.
So what does that have to do with “design sprints”? Well, it’s a bold, new method. It works. People will hate it at first. Implementing it as an accepted way of doing things in your organization will yield amazing results. So, no time like the present to learn more about it.
Design sprints were developed at Google Ventures by Jake Knapp. You’ll find all there’s to know about them, including detailed charts and timeboxes and such on their website. There’s also an updated version called Design Sprint 2.0. Read about them both, and choose one that you think will suit your needs best. It’ll probably be the 1.0, it grants more leeway for… unforeseen issues with active participation in the workshop.
The purpose of this article is not to teach you what design sprint are, but to share my thoughts on how to prepare yourself, your sanity, and other stakeholders for such an endeavour as the first ever design sprint. Caught up on the basics? Then let’s dive right in.
Getting the buy-in
Like I wrote in my previous pieces, if you don’t know where things start, they probably do so at a point of buy-in. Since sprints require clearing schedule for subject experts, designers, researchers, managers/CXX level people (depending on the severity of an issue you want to sprint for), you’ll need some proper, heavy buy-in at the highest level of your company. If you’re new at your job, you might get mixed success with it, but hey — you won’t know whether you’ve failed if you never had started.
The value of design sprints lies in time. This is the argument you’ll need for getting exclusivity on key stakeholders for a week. While doing things the regular way, especially when dealing with blue ocean issues, for instance — from a perspective of a public service provider, you want to learn how do people go about establishing their own company and what kind of digitization effort you might provide that’ll help them to that end — you will need 9 to 12 weeks of an agile processes to go through ideation, prototyping, testing and discarding failed ideas. With design sprints, you’ll ditch your worst assumptions in 5 days.
Having the argument of time talked through, there’s another benefit to design sprints. They force what I like to call inside-the-box-thinking (as opposed to, you know, thinking outside of the box). Through strict, immutable timeboxes, they ensure discipline and structure necessary for tackling issues of the highest order, thanks to:
- time for thinking — during sprints you’ll have time for letting your imagination run wild, both solo and in collaboration with 1-2 people.
- time for getting your voice heard — project fatigue is a serious thing. Various stakeholders might be unconsciously frustrated that no one seems to be paying attention to the risks they’re pointing out. Thanks to the sprint, everyone will be able to put out into the front the issues they care most about, with relevance to the topic of the sprint.
- time for murder — -ing your darlings, the assumptions you knew you had or the subconscious ones. Through forcing people to define what is it they care about and how do they want to go about solving these issues, you’ll end up at a point where there might be bad ideas, but not the worst ones.
- time for insight — since the goal is to have 1 or 2 best solutions for testing with users on the last day of the sprint, you’ll need to rapidly develop and think about the weak spots of your design. This list, kinda reminiscent of a design thinking’s double diamond, isn’t it?
- time for judgement — your ideas will be tested with users. While Deciders get more votes than other stakeholders, there will hardly be any room for a HiPPO. People will empathize more with their target audience if they will see how their best held assumptions contrast with the expectations of the users.
Preparing for the big day (week)
You might’ve noticed I like to begin at an end. This ain’t an exception. While you need a topic for the sprint first, the next important thing to begin with is defining end-users of stuff you want to make. Think on how difficult will it be to recruit them for the testing day. Can it be done mid-sprint (if you’re a team-of-one, no, it can’t be)? Do you need to just recruit people beforehand, or is there a need for a separate workshop with the stakeholders about defining your target audience first?
Ensure that the sprint is narrow in scope. You’ll go down the rabbit hole real hard, real fast and if you ain’t careful, it’ll derail the sprint. On the topic of derailment, prepare for failure. Do not assume that this sprint will “succeed”, or that it has to. What you’re aiming for is to discard ideas, not to create a workable MVP.
Choose your stakeholders carefully. Select a diverse group, that will have some difficulties with arriving at a common conclusion. You want to go through the sprint’s topic thoroughly, not peacefully. Make sure they will be properly informed. Prepare a homework with all the necessary data about the topic you’ll be sprinting for and check whether the stakeholders actually familiarized themselves with the data.
Get some catering budget. It’ll probably be an insanely difficult week for everyone involved. Good coffee and even better food will go a long way. Nutritionally balanced snacks are also better than butter and flour cookies, suddenly low sugar will kill participation faster than a fire alarm.
(Don’t laugh) Remember to double check that you’ve booked the conference room for the entirety of the week. You don’t want random people storming in mid-sprint. That includes the cleaning service.
Weathering the storm
The day (week) has come, the timetables are written, post-its bought, catering delivered, schedules cleared. Now what (except for you know, following the design sprint’s structure)?
You are the facilitator. The moderator. These roles need to be taken extremely seriously by you, since you will be tested on being an oasis of calm, and you will be found wanting. The only question is whether those instances will be few enough to not crash the sprint. Researching quick meditation techniques, such as box breathing, will go a long way to ensure you can deal with running this workshop.
People in the room are not designers. Well, not all of them at least. Sometimes it’s better to go easy on those who have issues with ideation. One idea from them will be fine, there’s no need to go and force them to generate multiple. Just make sure they do this one idea properly.
User research sessions are part of the sprint. Stakeholders need to be in the observation room, to watch and learn. This will probably the one thing they’ll remember the most from the entirety of the sprint — seeing their best intended ideas meeting the wall of reality.
The last piece of advice I have for the week of the design sprint is to remember about winding down. If it’s possible, go out on the town, together. Eat, drink, dance — just get the hardships of the day out of your system, clear all the negative emotion, build up a sense of camaraderie. Tomorrow will be no easier.
What’s next?
So, you’re at an end of the week? Great! Couple of things left for you to do.
Have a showcase at the end of the sprint. Walk all the stakeholders through the process once more, showing them the enormous work they’ve done during the week. Plant the seeds of an idea that design sprints are an efficient, reliable way of doing things.
Make sure the insights from the sprint are processed and put into your knowledge base. This ain’t one and done, this will be data to inform future decisions.
Reflect on how you, personally, did. What could’ve gone better? When did you lose your calm, could you’ve prevented this, did you have the necessary information back then to act properly? Treat this as any other research endeavour.
Now, armed with knowledge about the spike pits I’ve gone through, you can go an enjoy the coliseum your first design sprint!