The Clearleft Podcast

This is the Clearleft podcast. And this is my colleague, Chris How.

My name is Chris. I work at Clearleft as a UX consultant.

My name is Jerlyn and I’m a product designer.

Jerlyn used to work at Clearleft. And here’s Tom, a contractor who’s on Clearleft’s roster of trusted designers.

My name is Tom Prior and I’m a digital product designer.

At UX London a couple of years back, Chris and Jerlyn ran a workshop all about design sprints.

Sprints? That’s like an agile thing, right?

It’s not like an agile sprint. You’re not going to be shipping at the end of this.

So design sprints and agile. Yeah. They get confused a lot.

The word sprint is so loaded.

It can be a bit of a tricky one because it’s almost setting expectations about how you might work and what the outcomes and outputs might be. And they’re very different to an agile sprint.

It’s not about speed.

Do your work of explaining that this isn’t the sprint you’ve heard of. It’s nothing like the kind of agile sprints that you’re doing.

Design sprints are really good for exploring, investigating new ideas, having some time to do that and a time pressure to do it. But I think there’s a worry if you start using design sprints with the idea that all design problems can be tackled in a five day period, and you’re using them merely to crank out design quicker.

A five day period, you say. I asked Chris and Jerlyn to break this down for me. What happens on each of those five days?

On the first day, you understand the problem.

The purpose of the first day is to get the team together to end up at the end of that day with a "how might we?" statement, so taking a design challenge, probably doing some interviews, some investigations, some activities to end up at the end of the day with a focus.

How might we ...?

On the second day, you explore some solutions with people. And you sketch.

The second day is a day of sketching.

Typically when we do this at Clearleft, we’ll start the day with everybody doing some presentations around the topic that we’ve picked. So we can fill everybody’s heads with some insights, some information as a group.

We then do some design exercises to get everybody comfortable with the idea of design. Typically at Clearleft, we will facilitate design sprints with people who don’t typically think of their job role as a designer. So we want to get them used to making marks on paper, used to iterating. And we do some exercises to do that. And then the rest of the second day, everybody works in the same room, but on their own design to meet the design challenge, the "how might we?" statement that we’ve got.

At the end of the day, everybody has ended up with a design that we can put in a gallery.

On the third day, you decide together what the solution will be.

We, as a group, go and view the gallery. View everybody’s designs, dot vote on the bits of the design that we like.

And then we invite a decider, somebody who is invested in the project, but hasn’t been in the design sprint so far and they come in and they vote on the one idea to take forward into a prototype.

The rest of the third day is breaking down the design that’s being selected and then building out as a group from the ground upwards.

Ideally at the end of the third day, we want to end up with fairly detailed wireframes.

On the fourth day, you build. That’s either designers or developers working together, or you got paper prototypes. You’ve got people working to create the artifacts that represent the solution.

And the fourth day goes by in the blink of an eye. Nobody ever believes me when I say this at the start of the design sprint, everybody believes me by the end of Thursday, where they go, where did that day go? It disappeared.

We create a prototype that we can use in testing. And that will involve everybody in the team, pulling together the content, the visual assets, the design, the interaction, whatever the prototype is that we’re going to create. And equally there’ll be some people in that team who will pull together the facilitation guide that will help us with the structure of the testing sessions.

And then on the fifth day you go out and you test it on the field.

The fifth day we bring people in to evaluate, run through the design, the prototype with. We get feedback from that user group.

The morning we will run five or six tests to get some feedback on the design. We then have lunch as a group. And then in the afternoon, we will conclude findings on what to take forward, what to change if and when we do another iteration of the prototype that we’ve got. And then at the end of the day, we have a wrap up, documenting what we’ve learnt so we can pass it on to other people and, wrapping up as a group, the feedback from the week.

And that’s it in a nutshell.

So is it really exactly five days?

What often gets ignored when people are planning design sprints: beforehand, there is some time needed in order to plan and prep the design sprint. Recruiting users for the usability test would be one thing, gathering together some assets that we know we might use. If a company has a brand tone of voice, any design assets, a visual library that we can lean on, icon sets, all of those things. We will prep those beforehand.

There’s usually some work after that to make a decision on what we do with that prototype. Do we take it forward? Do we run some more experiments on it now we’ve got a more highly tuned hypothesis? Whatever the outcome is often needs some work and some communication around what we’ve done.

So you’re messing with the formula?

I don’t think I’ve ever done like a really classic, like what maybe could be by-the-book. I’ve never done it by the book one. No.

Certainly over the last couple of years, I haven’t done that many by-the-book design sprints.

The one I did for Virgin Holidays with the Clearleft team was actually three weeks.

It was actually a little bit of a larger team than you might typically have. So that meant we needed a little bit longer to work through a bunch of workshops and processes. But the first week was really about getting under the skin of the brand and doing a lot of user research. So a lot of that first week was spent understanding customers more effectively and deciding where we were going to put our efforts in week two.

So it was really a discovery week. The end of that week, we felt like we had a really strong picture of what the challenge was ahead of us. And that puts us in a really great place to hit the ground running with week two. Week two was very much more like the traditional sprint. But it flowed so well because there were fewer unanswered questions about the challenge and the domain and customers, because we tackled them week one, given ourselves a really strong grounding.

We did some iterations on the prototype in week three. And we tested again, I think it was on the Wednesday. So much, much shorter turnaround. We shortened that loop a lot in the third week. And then the last couple of days were "Okay, how are we gonna play this back to the business and show the business case for taking this work further?" Because we had seen that it was worth further investment.

A design sprint sounds like an almost magical approach to problem solving. But surely it’s not the right technique for every kind of problem.

One of the potential pitfalls is going into a design sprint, thinking that at the end of this you’ll have something shippable.

So that’s also something you have to say up front is that it isn’t about coming up with something that you’re going to be able to release into the world immediately.

Picking the right challenge is so crucial.

Jerlyn would always say it was the Goldilocks problem.

Sometimes the challenge is too big and too amorphous that it doesn’t give you a focus. It doesn’t give you a hook. And sometimes the design sprint challenge is so small that you can’t think of many different ways of tackling it. So all the solutions are going to look the same. They’re often the kind of businesses as usual sorts of challenges.

But you want that sweet spot in the middle that is a challenge that is small enough to tackle in a small period of time, but interesting enough that you can think of a myriad of solutions

Design sprints are not good if you were looking for a very specific buildable solution.

It’s not reliable product design and It’s not the level of evaluation and product validation that would mean you’re in a place to release or even start developing. It’ll give you really clear signals of where to go next, but where you go next is not going to be launching.

It’s about unpacking whatever the problem is to get to the core assumptions. What are the core things that we need to find out and learn about to enable this project to launch successfully?

I do genuinely think the most value is what it’s advertised for, which is de-risking an investment in an idea that’s potentially risky.

I like to tell the teams that I’m working with in a design sprint, that what we’re trying to get to is to build a prototype that allows us to get some questions answered.

The aim is to have a tangible asset that will allow you to test the hypothesis. And the hypothesis is more important than the assets you’ve created.

I think if you can avoid investing money and time in something that never really had legs, then you should be celebrating that. And I think is so important to prime the team that this might be one of the outcomes. And if it is? Fantastic. We’ve avoided weeks and months of work.

Whatever you create is a prototype. It will get scrapped. I don’t think a single pixel or a single line of code or a single line of text has made it from that prototype into the finished product, if that gets launched. But what has survived is the learning from that prototype. And I think that’s important. You are building a test.

All right. So that’s the purpose of a design sprint. To test a hypothesis in five days. But it sounds to me like there are some other benefits to working this way. Listening to the way people describe it, it almost sounds like a team building exercise. A way of bonding. And it helps demystify the process of design. That’s gotta be a good thing.

The issue with design thinking, I think is it can feel quite vague as a mindset and a methodology, which it is. It can feel maybe a little uninclusive because it has sometimes a little mysterious kind of way of doing things and all these workshops and tools and mindsets.

And the thing I like about a design sprint is it kind of makes it a little more procedural, maybe a little more cold, but you follow these steps and you’re going to get somewhere and it gives a bit of validity to design thinking in organizations.

The best thing that comes out of a design sprint is sort of the way of working, collaboration and the learning.

My favorite makeup of the team is a diverse team from around the business.

It’s designed to try and allow everyone to have a voice in the process and you intentionally are trying to bring in different perspectives into the room. So it’s not just the designer and the developer and the product person. You’re hearing from people more broadly in the business.

I think that’s the most important part of a design sprint. That’s what makes it really work is that you’re doing the things that you never get to do normally at work. Everybody just sits there with all their assumptions and all the business as usual ways we work. And the design sprint pulls you out of that. So you’re in this elevated moment with everybody. You’re outside of your normal practices. You’re not at your desk, you’re not with your normal calendar. You’re now in a room for a week with people and you’re changing the rules for one magical moment.

The design sprint does a great job of allowing everyone to have a voice in that process.

Every body in a company who makes a decision on an app or on a website is involved in the design process. It’s not just the designers or people, you know, with design and their title who actively design it.

Everyone is participating in that design process. And I think it’s also just making everyone pay attention and become really aware of that when you’re in a design sprint.

There was a definite sense of ownership of that outcome for that project that I don’t think you would get using other techniques. If you had a series of meetings, I don’t think people would have the same vested interest in it, but everybody saw something in that prototype that they had been responsible for creating.

I think that’s the best part of the design sprint.

The design sprint is useful in breaking down department based silos, getting people from different disciplines to work together.

Maintaining that is somewhat harder.

At the end of one design sprint, I had a conversation with one of the participants and she said to me, "Oh, it’s going to be a real shame next week when I have to go back to doing proper work."

And I recall saying to her, "Well, isn’t this proper work? What we’ve been doing this week?" And she said, "No, this isn’t proper work. This has been real fun."

And it was that moment of thinking there is something wrong in a business where work and fun are either ends of a spectrum.

And I think the design sprints, they are fun. They are engaging. They are the hard work, but they are definitely proper work.

I’m sold on the benefits of design sprints for tackling the right kind of problem. But where did design sprints come from?

It’s a few years ago now that I first heard the word design sprint in terms of Jake Knapp’s book and being encouraged to read the book and use this as a technique.

It was probably around 2016. I think the book had probably been released at that point. There was a bunch of blog posts doing the rounds about this kind of new concept of applying design thinking, but in this nicely packaged up way. I think I watched a few YouTube videos maybe from Jake Jake Knapp and thought this is something I think could work with some of the clients I was working with at the time.

I would probably say that design sprints, I wouldn’t say they’ve been fetishized.

The design sprint isn’t a trick.

They’re a symptom of Jake Knapp’s fantastic charisma and his ability to market very well.

It isn’t something you have to memorize or learn to do.

Because, you know, honestly, Google Ventures design sprints, they are very good at simply consolidating what we’ve been doing for quite a long time. And when I say we, I mean, most agencies have been kind of thinking in that mindset of, you know, divergent and convergent and then testing with users. Right?

It’s a really nice way to work with people, collaborate, iterate, design, and test.

Having read the book, although I think it’s a fabulous book, I realized I had been doing design sprints for about a decade as part of the design process.

As a designer, you’re naturally constantly articulating your process. You’re naturally always thinking about the project and what are the right solutions what are the right approaches to what you’re trying to do. And I feel like a design sprint is a nice framework for doing that.

But it feels like a natural way to work already.

I think the absolute genius stroke that Jake Knapp had in writing a book is actually two fold.

The first one is it’s a book that would appear in airport bookshops and C-suite executives would buy it and they would have an introduction to design. Now that’s a double-edged sword because you then have lots of executives thinking they know everything about design, having read Jack Knapp’s book. And they also think that design can be done in five days as in the title of the book, solve big problems in five days.

The other stroke of genius, and I don’t know if this was deliberate or not, but it’s the first time in my career that, having often talked about the maker and manager dilemma, maker’s schedules, manager’s schedules, Jake Knapp’s book I think inadvertently has made the maker’s schedule come to the fore. It’s given people that opportunity to concentrate as a unit of people on a problem in a short period of time.

And I’d like to thank Jake Knapp for that actually.

This name keeps coming up again and again.

Jake Knapp

Jake Knapp

Jake Knapp

Alright. Alright. Fine. Here he is.

I’m Jake Knapp. I’m the inventor of the design sprint, and the author of the book Sprint. And nowadays I’m continuing to teach the design sprint, talk about it and write and just do various projects.

I wanted to hear straight from the source: what’s the origin story for design sprints?

This is the 10th anniversary of the first design sprint.

Some of the inspirations for me were, I guess it was a combination of projects I had been a part of or seen up close when a project failed, and also projects that I had been a part of that that seemed to go well and trying to figure out what was the difference and how do you make it work. And I had seen inside Google how difficult it was to start new projects.

Part of it then was me thinking about all of these different ideas that I wanted to apply and trying to take bright spots that I had seen and reproduce those.

And then I had these other two experiences that I didn’t notice how special they were at the time, but it was this idea of getting a team together for a week and, and really focusing on producing a prototype at the end of the week.

I was a designer on Gmail. We had done that to produce the early prototypes of what became this feature called Priority Inbox. We did like four of these week long sprints. And then I had done it on what was the 20% project that a couple of other folks and I were trying to start, and that became Google Meet.

And I had those two experiences and it was like a year and a half between that and the first design sprint during which time I was back to business as usual and the slow slog of meetings and churn and everything.

And I guess during that time, it just took a really long time for all these ideas to kind of settle together.

And then even once it started, the first design sprint bears very little resemblance to the recipe that is finally in the book. It then took another five, six years of experimentation on that process to get it to a point where it was really durable and seemed to work every time in every context.

Every time? In every context? Surely Jake isn’t suggesting that a design sprint is the right tool for everything? Isn’t there a Goldilocks-sized nail that suits the design sprint hammer?

The design sprint works best when you have a big challenge that you’re about to start you’re at the beginning of it. And you know what the challenge is.

It’s really optimized for that. Specifically it’s optimized for these projects I had worked on at Google that were the inspiration. It’s a 20% project, meaning we have this exciting idea. We want to turn it into a product so how do we start that off in a way that catalyzes it and gets it going?

You’re starting off something, you know what it is. But if you’re before that moment, if you don’t know what it is yet, if you’re just like, we need to do something, but we don’t yet have even a hypothesis about what that is. The design sprint is not set up to handle that.

There are a whole bunch of categories of problems that are too small to make sense for a design sprint, but there are a bunch that fall in between, you know what you’re going to do. It’s big and it will be costly if you get it wrong. And one of the thing, the Goldilocks thing, I sort of think Oh, if you have a team of people and you’re going to spend six weeks or more working on this project, you ought to consider doing a design sprint at the beginning.

You might decide in the end that you don’t have to, but that’s usually a good threshold to start thinking about it.

I told Jake about all the ways that people have been messing with his formula. Like Tom’s three week design sprint with research at the start and playback at the end. How does Jake feel about people mixing things up like this?

I think that it is very doable to do a four day design sprint. I still prefer five days, but four works well.

And many of the sprints that I’ve run, we did do research ahead of time. I would never say you have to do that, but it definitely makes it better.

And there are definitely improvements and more specific tools to give people for what happens after the sprint.

There are a bunch of new improvements on making a map or improvements on the storyboard that you use to set out how you’re going to prototype that folks have come up with since the book came out and that I’ve learned from other people. And I’m like, “Wow, that’s definitely better. We should do that.”

And there are a couple things that either we always did before and didn’t include, or there’s a better way of tracking what you learn in the test at the end of the sprint that I came up with right after the book went to press. So it’s not in the book.

I do think there’s a lot of opportunity to make the sprint better. I think my biggest concern is when people start to mix it up before having done a couple by the book because it took a really long time to come up with what’s in the book. It’s not just haphazardly slapped together. There are reasons why it’s five days and not three or not two. And there are reasons why we don’t share our work while we’re working. All those things are there for a reason. I always ask people to try the recipe by the book first before they experiment.

Jake would be the first to tell you that there’s nothing particularly revolutionary in any of the individual steps in a design sprint. As you’ve heard from the other designers, all the pieces were already in the design toolbox.

But what Jake did that was new was he wrote it down. I think that’s the real lesson here. A design sprint is a framework, a recipe, a list of instructions, an algorithm, if you will. A design sprint is a checklist.

This article that I read maybe in 2007 about checklists really inspired me. And this idea that if you make a list of the things that you should do every time, then you can be sure that you go through and you do all the right steps before you take off.

And I thought, man, I should try to apply that in my work because I can see that it’s hard to apply all the things I know are the best way to do things or these new ideas I want to try, but maybe a checklist could help me. And I started to use checklists when I was doing presentations at work. I started to use them when I was doing my design work.

That was one of the big things that carried into the design sprint was this idea of making a recipe.

Take this idea of ”we’re going to make a recipe, we’re going to make a checklist for this thing that we do.”

And when you start to look at your work in the form of a checklist, then good things happen.

You’ve been listening to the Clearleft podcast. Thank you to Jerlyn, Chris and Tom. And thanks to Jake Knapp, the man who will almost certainly have an epitaph that reads “here lies the design sprint guy.”

I think that the longer I live with it, the happier I am with being the design sprint guy. Because the truth is that it’s a topic I don’t really get tired of. It’s kind of shocking to work on something for 10 years and still be like, I mean, you heard me, like, I can’t stop talking. You can hardly get a word in edge wise because I’m like “Oh yeah. Jeremy, this, Jeremy that.” I’m like, I’m so excited about it. I just like, I’m fine with continuing to talk about it for the rest of my life.

Thank you, Jake.

And thank you, yes, you for listening.

This was the last episode of season one of the Clearleft podcast. But stay subscribed. We’ll be back with another season before too long.

If you’ve enjoyed this first season, please help spread the word; share the podcast on Twitter and in your Slack channels. It would really mean a lot to me.

This is the Clearleft podcast signing off for this season. Thanks for listening.