Published on | Prototyping: From UX to Front End — Medium Design by Howell

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.

on your marks… get set… SPRINT!

Being a UX Designer in an ever expanding world of customer centric design thinking, I’ve recently had the opportunity to facilitate a couple of design sprints in my work with Sunsuper. In the spirit of sharing and learning, I thought I would take you through what I’ve learnt about design sprints, both the good, and the not so good.

What’s in a sprint?

Firstly, I need to berate Google a bit for calling it a design sprint, latching on to such a well established term as a ‘sprint’ is actually really 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 any kind of scrum process.

A design sprint is a methodology for solving business and customer problems in a focussed and measurable way. I could go into great lengths explaining what a sprint entails, but the best guide for it is already out there at Google Ventures Design Sprints, please review if you’re unfamiliar and come back.

So you wanna sprint…

How I became involved with a design sprint was mostly luck, there was a project that needed some serious UX and CX input, the project lead asked the CX team for help, they pitched the idea of having a design sprint, and I had time available to help the lead CX 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 what that the real work of a sprint is actually in the preparation, in order 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 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 in and setting up tasks it’s busy, but then as you supervise and listen you have to take a back seat and let the sprinters do the work themselves. 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 really necessary (within reason of course). If you’re getting some really good Q&A from a lightning talk, let it continue. If people are still madly 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 that they have to work through on their own in order to realise the full benefits of the sprint.

Another vital component of an effective design sprint is the Decider, there needs to be one person in the room whom everyone can defer to when a decision needs to be made. 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 quite easily, but just 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 something along the lines of “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 here and there during their sketch sessions to encourage them to add visual elements to their sketches.

Something to keep in mind though is that the detail or refinement of your sketches really depends on your challenge, some challenges need a sketched UI, some need a user flow and some require a storyboard. The better the understanding of the challenge, the easier your sprinters will find it to be creative and explore ideas within that space.

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 very closely 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. Firstly, making sure that you are servicing the original design challenge and incorporating the best parts of the sketches that meet that original challenge. Secondly, keeping in mind what you want your test users to do with your prototype, ensuring it has the required functionality to prove or disprove the solutions to the challenge that your group has designed.

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 included in the sprint as a whole, otherwise the briefing process you would need to do would take up too much of their time.

Testing

Getting everything ready for user testing is quite a big job, which is why I believe it is best handled by one person assigned to this role for the duration of the sprint.

From the moment you have your design challenge and have spent day 1 unpacking your assumptions, the tester can start recruiting testers who match the user who have been experiencing problems or are targets for the new feature.

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 may be used for measuring 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 maximum that will best ascertain 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 very much worthwhile and the participants were really thrilled to have been a part of the process and as a company we are now seeing a big uptake in design led thinking now 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.

Facilitating a Design Sprint was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Facilitating a Design Sprint

Cool stuff, every week

More Articles