Facilitating a Design Sprint
If you’ve been reading anything in the world of design recently you will no doubt have heard of Design Sprints. Formalised by Google Ventures and now the darling of the design and tech industries, the golden key to unlocking innovation and customer centric problem solving… mostly.
As a UX Designer in the ever expanding world of customer centric design thinking, I’ve recently had the opportunity to run a few design sprints in my work with Sunsuper & Bank of Queensland. In the spirit of sharing and learning, I thought I’d take you through what I’ve learnt about design sprints, both the good, and the not so good.
What’s in a sprint?
I need to berate Google a bit for calling it a design sprint, latching on to such a well established term as ‘sprint’ is annoying when talking to anyone within a digital company. They all think they know what sprints are, they’ve been doing them for years. Not to mention the confusion it throws up around agile design, lean UX and all those other design trends. A design sprint is a closed system, it’s one sprint to solve one challenge and achieve one outcome, it’s not part of an iteration and it doesn’t go through the scrum process.
A design sprint is a method for solving business and customer problems in a focussed and measurable way. I could go into great detail explaining what a sprint is, but the best guide for it is already out there at Google Ventures Design Sprints, please review it if you’re unfamiliar and come back.
So you wanna sprint…
How I became involved with a design sprint was mostly luck, a project needed some serious UX and CX input and the project lead asked our CX team for help. The team pitched the idea of having a design sprint, and I had time available to help the CX lead out. So the first thing I had to do was research, I read through the sprint guide from Google Ventures as well as the great article on FastCompany and a few other go to design sites had some guides and examples as well.
The most surprising thing I found out was that the real work of a sprint is actually in the preparation. To have your sprint run well and achieve it’s goals, you need to make sure you have the right people and the right challenge with a clear direction. Once you are in the sprint, it pretty much runs itself thanks to Google’s very simple guidelines.
Mise en place
‘Mise en place’ is a cooking term. It’s all the work you do before you start cooking; the cleaning, chopping, heating, pouring, measuring and so forth. When it’s time to start cooking, everything is ready to go and all you have to concentrate on is the act of cooking your dish.
As a Design Sprint facilitator your job is to get all your ‘mise en place’ ready before sprint week. meaning you need to:
- Lock down the roles for everyone in your core team (facilitator, decider, prototyper). It must be clear to everyone what their role is and what’s expected of them
- Define the challenge, you must be able to clearly and easily communicate what problem you are trying to solve in your sprint
- Find your experts, find your 3 to 5 subject matter experts who can provide your sprinters with the insights they need to understand the challenge.
- Select your sprinters, try and have as broad a cross section of your business as possible, good ideas come from everywhere.
- Pick your prototyper, make sure you have the right person for your protype, be it wireframes or interactive.
- Find your testers, recruit your end user testing candidates, make sure they are a good representation of real users from the real world.
- Book your location and gather your supplies, find a room with plenty of wall space for notes and sketches and bring all the usual supplies for creativity and sketching.
Running the sprint
For me sprint weeks tend to run at 2 speeds: full-on and measured. When you are briefing people and setting up tasks it’s busy, but then as you supervise and listen you get to take a back seat and let the sprinters do the work. Keeping a balance between guided activity and organic discussion is in my belief the true job of the facilitator.
The formula for the 5 day sprint is very clear, however I find that sticking to set timeframes for lightning talks or sketch sessions isn’t necessary. If you’re getting good Q&A from a lightning talk, let it continue. If people are still sketching awesome ideas after the eight minute mark of your ‘crazy 8’, give them a minute more. The facilitator’s job is to curb the bad and foster the good from the sprinters in the room to get the best out of them.
I have a brief yet insightful background in tutoring and teaching at the tertiary education level, and I found that facilitating the sprint is a lot like teaching a classroom of adults. It’s not about dictating a schedule of events like a meeting agenda, it’s more about guiding a group of people through a process.
Another vital component of an effective design sprint is the Decider. There must be one person in the room to whom everyone can defer to to make final decisions. They are able to settle debates on scope and park ideas for future sprints. As a facilitator you will often be able to field these problems, but having that role defined for all can often save time.
Sketching
More often than not you’ll find that some of your sprint participants will say “I’m no good at drawing” or “you won’t want to see my sketches” or the worst one, “I’m not very creative”. This is where the facilitation role has to step up and help people understand that it’s not about drawing or sketching, it’s about ideas, and ideas can be represented on paper in many forms. I found it helpful being able to wander the room and give people small pointers during their sketch sessions encouraging them to add more visual elements.
Something to keep in mind though is that the detail or refinement of your sketches depends on your challenge. Some challenges need a sketched UI, some need a user flow and some need a storyboard. The better you understand your challenge, the easier your sprinters will find it to be creative and explore ideas.
Prototyping
For the sprints I have facilitated so far, I have been responsible for building the prototype to be user tested. This has allowed me to work with the user testing facilitator to develop testing scripts in tandem as the prototype unfolds during the day.
Deciding what your prototype needs to have in it is driven by 2 main factors. Making sure that you’re servicing the original design challenge and incorporating the best parts of the sketches that meet that original challenge. And keeping in mind what you want your testers to do with your prototype, ensuring it has the required functionality to prove or disprove the solutions to the challenge.
This is why you have a full day to build this prototype, and if you are getting a developer or separate designer to prototype for you, then they must be part of the sprint. Otherwise the briefing process you would need to go through would take up too much of their time.
Testing
Getting everything ready for user testing is quite a big job, which is why it is best handled by one person outside of the sprint participants.
Once you’ve defined your design challenge and unpacked your assumptions, the tester can start recruiting testers who match your end users.
Then during the next 2 days of sketching, they can start to rough out scripts on what the testing will need to prove or disprove, what metrics will measure success, and further refine the candidates list down to the 5 needed.
Whilst the prototype is being built they will be finalising the scripts and getting their location and tools ready for the next day’s testing. This is where the testers ‘mise en place’ needs to come together so that on the final day, they can be in full service of their testers.
The testing itself should be very straightforward, for a design sprint you need 5 testers who are as broad a representation of your target users as possible to complete 3 tasks that will best demonstrate if the prototype meets the design challenge and user needs.
Each test should be no more than 1 hour long, you’ll need a note taker and having the sessions recorded both on screen and via webcam is the best way to get a complete picture of each test for review.
For the sprints I have facilitated, the tester has reviewed the testing notes and footage on the following business day and produced a report that is then used to refine the prototype which is then presented back to the sprint group along with a final outcome of having solved the challenge or not.
Final thoughts
So that’s how my experience of facilitating design sprints has gone so far, however, I haven’t told you how they’ve actually performed in the end.
I have had one big win, and one miss, although the miss was more of a “we need to fix a lot of underlying systems first” scenario. In both cases the sprint was still worthwhile and the participants were thrilled to have been a part of the process and as a company we are now seeing a big uptake in design led thinking for customer and business problems.
I look forward to continuing to facilitate design sprints as a collaborative ideation tool.
If you’ve been running design sprints, I’d love to hear your thoughts on how that process has gone for you.
