On this episode of Labs Live!, Dan and Tobi sit down with delivery lead Ryan Petrill to talk about Design Sprints — What are they? What’s the value of running one? Learn about the Design Sprint process, and how you can get started building the right product. Transcript below.
Learn more about Detroit Labs and get in touch today.
_____________________
Dan:
Okay. Welcome back to Labs Live! and happy 2020. It’s a new year, Tobi. I’m Dan.
And today, we’re going to be talking about design sprints with Ryan Petrill. I think I got the name right. I’m looking at it or not. I got it right. Nailed it. Before we get into that, don’t forget to subscribe to our YouTube channel, hit the bell icon to be notified and also check out our other social channels because we put out a lot of content, especially on LinkedIn, Twitter, the ‘gram.
Tobi:
The ‘gram.
Dan:
… is Tobi’s favorite. There’s also a chat room during this live stream. So if you have a question for Tobi, Ryan or-
Tobi:
Dan.
Dan:
… dare I say myself, you may post that in there and we’ll do our best to answer that. Dave we’ll read them off. We’ve had one. It was fun.
Tobi:
We’ve had several.
Dan:
We’ve had one. It was a good time. Before we get into that, one of the reasons we haven’t been around, obviously you had the holidays, you had the new year, but also we’re in Las Vegas at CES. What was one of the things that caught your attention at CES?
Tobi:
So I really enjoyed seeing the future of technology, but I have affinity for technology that’s very practical. So there’s this company based in Zeeland, Michigan called Gentex That was trying to reimagine the surgery room and kind of incorporate the lights into the surgery room, so the surgeon can control the lights with a wand. I thought that was very practical. I was very moved by it, but I might be biased because I really like medicine in general.
Dan:
Well, it’s actually kind of fun just to see technology that could actually work for a good reason and could actually come out.
Tobi:
Oh, yeah.
Dan:
Because Yes, it’s the land of connected things that no one needs.
Tobi:
Yeah, correct.
Dan:
When I think about CES, I think actually a little bit more about the relationships. So less about the show when we’re out there and the things that we’re seeing, but more of the fact that there are so many people, both clients and potential clients for us, that are there. There are a lot of relationships that we actually have in Detroit that are great to connect with there. So it was fun. We tend to be on the same flights every year with people. So it’s great to talk to them. And now, we’re back in Detroit. So we’re doing this short. This show, not short.
Tobi:
It’s a short show.
Dan:
It’s a short show. It might be. Let’s welcome, Ryan. Let’s talk about design sprints. Come on, Ryan. If you can’t hear, there was a massive applause behind the camera. It was runnable. Anyways, Ryan’s a delivery lead at Detroit Labs and is one of our folks that has run a few design sprints so far. So give us an idea. What is a design sprint?
Ryan:
Sure. So design sprints a five day process that originated at Google Ventures, and it’s really aimed at solving the critical business problems that you may have. You bring together a team of designers, business leaders, engineers into one room and you dedicate time to solving those problems. So through the five days, you’ll define your problems, you’ll start coming up with potential solutions. We prototype it out and then we put that in front of potential users so that way, you get the feedback quickly that you can start iterating on. It’s a really good way to start streamlining that original process that may take a really long time to go through many meetings with managers and the hierarchy to try to get approvals on things. You can start streamlining that in a week.
Two things I like to point out about design sprints is one, it’s a really easy, low risk way to start getting into new ventures. Whether that’s a new product, a new business, a large feature adding onto an existing product, you don’t have to commit all that development time. Instead, you’re committing a smaller amount to try to get those answers faster through the sprint.
Dan:
Who uses a design sprint? Is it just a small niche thing that just the startups can use?
Ryan:
No, it can be any size company. There’s no too small of a company. There’s no too large of a company. And it’s not industry specific either, so you’ll see it across all the different industries. I think that you’ll see small companies, mainly startups that maybe have a new business idea, they want to further define that. A sprint’s good for them to start talking through what that potential product offering could be. You see large Fortune 500 companies. Lego is a good example of a company that started incorporating design sprints. They’re a huge company and then they started with one sprint to try it out to start creating some of their new Lego kits. Then today, they run a 150 design sprints internally a year.
Dan:
Wow.
Ryan:
So it can scale as well. We here have run sprints with startups that are trying to launch the new products and we’ve run them with larger companies as well.
Tobi:
So not just apps?
Ryan:
No, not just apps either. We will tend to focus on mobile apps or websites, but it can also be run to do physical products as well.
Tobi:
That’s awesome.
Dan:
So you said five days?
Ryan:
Yeah,
Dan:
Right. So are you telling me that it only takes one week and then you’ve solved all of your problems and you have a product ready to be built?
Ryan:
No, not exactly. So what’s going to happen in that five weeks is we’re going to start defining what that opportunity that we want to focus on is, but the core thing to get out of it is that we’re going to be focusing on the main aspects that’s going to deliver that value. The sprint framework is set up in a way to where you start broad and start honing in on those specific features. As a group, we’ll start prioritizing what we want the sprint to focus on. Then what we’re prototyping out is going to that. At the end of the day, our prototype is going to be our educated best guests at what we think the solution is. Then when we get that feedback, it’s going to provide you on where to go. So it’s not going to be a silver bullet, but it’s going to get you to where you want to be much faster than if you were to invest the original methods of product development.
Dan:
I want to get in and start breaking down every single day. But before we do that, if I’m a company that wants to do this, what do I need to know before jumping in? What do I need to have prepared before engaging with either Detroit Labs or performing one of these myself?
Ryan:
So first, you need to have at least a general idea of what the opportunity is that you’re coming in to solve. We’re going to have a much more in depth discussion during the sprint and to prioritize what that’s going to be, but it’s good to have that conversation beforehand so that we can start to get up to speed on our end. The other thing is that you need to make sure that you understand the time and dedication that it takes. So the sprint, while we say it’s five days, one of the questions we usually get is do, “Do I have to be there all five days?” And the answer is no. So we have an adapted sprint. We required that the people in the sprint are there for at least the first two days. That’s where a lot of the core value comes out of the contextual information that we need.
So we need to make sure one, that the right people are in the room. We want to make sure we have representation from the team. And then two, we want to make sure that the time is available from those people. We want to be able to dedicate those full two days to this problem. Then after that, our team can start prototyping and testing, and then we’ll get back with our results, but it’s not going to require that full five day span.
Tobi:
So what kind of rows make up a design sprint team?
Ryan:
Yeah. So the maximum number of people advising the sprint is going to be seven. So of that, you’re going to have a handful from the client that’s going to be able to talk through if there’s an existing product, what’s the user base, what’s the current flow like, people that can talk to the decisions that have been made thus far. You’re going to want someone who can make decisions on the direction of the product is going to go. Every sprint is going to have a decider in it, and that means that that decider is going to have the ultimate call on when we start solutioning out ideas, what direction we’re going to take. So that’s what we need from the client side.
From our side, we’ll also provide product designers. We can have engineers if we start talking through some of the technical capabilities. We’ll have certified design sprint facilitator. You’ll have a mix of different roles and disciplines in it.
Dan:
All right. So bought in, ready to go, teams assembled. I do like that one of the things that we’ve worked really hard at Detroit Labs is taking a what is an ideal process and slightly modifying it for realistic, real world type challenges. And that’s the five days dedicated down to two days from the client because realistically, a lot of things happen. Yeah, schedules and businesses have to keep moving, so I like that. But now, I’m bought in, I’ve got the right people at the table, let’s go through every single day. What happens day one?
Ryan:
Yeah. Day one’s kind of split up into two parts. So the first half of day is really about defining and understanding the problems and opportunities why everyone is here. The second half of the day is split solutioning. So in that first half, we’ll start it off with getting everyone in the room. We’ll just start doing interviews with the business leaders in the room. That’s an opportunity actually where if you’re a participant in the sprint, you’ll be in these interviews, but it’s also an opportunity to start bringing in people who might have more narrow focus at your company as well. We can bring those people in, but it’s just really for us to all get on the same page of what the problem is that we’re talking about.
So we’ll ask questions to try to get a better understanding, how the current flow of the app or of the process that you’re trying to solve is working and then we start writing out what are the problems then that we could start tackling in the sprint and what do we want to focus our efforts on? So that’s like the first half. Then in the second half, we’ve we’ve come together, we’ve decided on those, we’ve talked through like, “This is what we want to prioritize and focus on.” Now, we start coming up with potential solutions. This is where we start incorporating some market research. W look at what competitors are doing. We, ourselves, have our own expert to use in the client. You have your own business expertise, and so we come together and start coming up and drawing out potential product solutions. We’ll come up with concepts that look like maybe the core pieces of a user flow that we want to incorporate into this prototype. We’ll vote on those at the… We’ll create those throughout day one and then move into day two.
Dan:
So day one’s very much unpacking, establishing that foundation, the ground rules, if you will, for how this thing’s going to go. Let’s jump into day two. What does that look like?
Ryan:
Yeah. Day two starts out with basically voting on the solutions that we’ve come up with at the end of day one. At the end of day one, everyone’s put together their best ideas for potential solutions to the problems that we’ve decided upon. Then in day two, we’ll kick it off and we’ll go around the room and start looking at what everyone has created. Then we’ll start voting on them, and ultimately, we’ll pick one that we want to move forward with that’s going to lead into our prototype.
So after the decider has chosen which solution they’d like to move forward with, then we’ll actually do a more in depth round of white boarding where we’ll take that concept as our starting point, but then build out screen by screen, “Okay, what is this prototype going to actually look like?” That way, it informs our designers and the next day, “This is everything that needs to be in the prototype. These are the interactions we want. This is the data that we want.” We want it to be as realistic as possible. So the majority of day two is really refining and defining out what that prototype is going to look like.
Dan:
Help me understand a little bit what a prototype is because I think you’re about to cover that in day three, but just kind of a flavor of what that might look like.
Ryan:
Yeah. So a prototype is just going to be as real, a bit… Trying to get something as close to what the end product might be. Design tools now, allow us to create experiences that can mimic very, really mimic how an app would function if you were to actually code it without requiring any code. So for us, it might be designing out a web experience or a mobile app experience, but you can actually, for a mobile app for instance, the prototype would actually be on your phone. You can launch it, you can go through different… You can interact with it, you can scroll, you can go through different flows of with it. It’s going to allow you to put something in front of your user that looks real without investing all of that money up front to actually build it out.
Dan:
Let’s expand a little bit on day three because I think that’s where there’s a little bit of a shift at this point? That’s the day where the client is not as involved, right?
Ryan:
Correct. Yes. So day three, the client no longer needs to be onsite. This is really for our team to focus on building out the prototype. The designers are pretty much heads down all day building out the prototype based on the screens that we’ve drawn up from day two. We’ll ask the client questions throughout the day to any clarifying questions. But other than that, it’s really just starting out in, “Okay, we’ve got the flow down.” Now, we’ll start adding some of the visual elements to it, making sure the interactions look right and just polishing everything up so that we can get ready for user testing.
Dan:
So the team’s heads down, working hard on this prototype, prototype is getting close to being ready. What does day four look like?
Ryan:
Day four is user testing. So we come in, we make sure that the prototype is as good as it can be and then we start putting it in front of actual users. So working with the client, we’ll start identifying, “Okay, what’s the target audience for whatever you’re trying to build?” And then during that sprint process, the facilitator is going to be recruiting a group of users to then test out the prototype. All of day four, the facilitator will be moderating user testing sessions where users will start using the app. We’ll take notes on, what are they like? What do they not like? Is there anything confusing? Is it solving the problems that we identified in day one? We start taking notes on all of that, and we have five testers that we run the app with that we run the prototype through on day four.
Tobi:
So why five? Why five people?
Ryan:
Yeah. So five is the number where you start to see patterns emerging when you’re testing. There’s a publication from the Nielsen Norman Group that you’ll find 85% of your usability issues with five users. So it’s a good amount to where you start seeing people going through the app and suggesting things, or either liking or not liking things. Once you see enough of those happening, it gives you a good sense then when you start having… When we’re done with testing, we can start providing recommendations based on those.
Tobi:
They come on real life scenarios. Sometimes you have clients who might think or believe that like, “Oh, I know a lot about my users. I have analytics.” Is the steps necessary? Why do we do user testing?
Ryan:
Yeah, it is still necessary because no matter how much your user, you’re normally not the user. Even if you are, you’re a single point. So it’s critical to put your app in front of users. Similar to when you have five users will get you 85%, zero will get you to 0%. We’re putting it in front of people so that you get some of that more information, so you can have a broader range of input.
Dan:
So we’ve identified the problem, we’ve identified the prototype, we built the prototype, we’ve done some user testing, a little bit of iterative user testing to really understand if that works. Now, we’re going into day five. What does day five look like?
Ryan:
Day five is going to be the team will get together internally and we’ll summarize all the findings from user testing. We’ll put together a sprint report with the findings and the prototype, and then we’ll hold a meeting with the client to discuss then how the sprint went. So we’ll do a recap. We’ll walk the client through the prototype that’s been created. We’ll walk through the user testing results, and then we’ll also talk through our recommendations based on those findings. From the client perspective, all of that is then delivered to you as well. So you get the prototype, you get all the results. So if you want to run more testing, if you need to show that to people within the organization to further sell your idea, all of that becomes yours that you can then share as you will.
Tobi:
Is this onsite as well, or is it remote friendly?
Ryan:
We prefer onsite. There have been designed sprints run that have been remote friendly, but I know from experience, we’ve done some and it’s definitely smoother when people are onsite, at least for those first two days.
Tobi:
Got you.
Dan:
So everyone’s tired at this point, end of day five, probably happy of the outcome and of the amount of work that went into it. After this is all done, are you ready to jump in right away and build that thing that you prototyped? Is that the next step or is there something completely different there?
Ryan:
It depends on the results of the sprint. The sprint’s not going to be your 100% guaranteed answer to get everything right. In reality, what it’s going to do is allow you to take a stab at something that you want to pursue, and then it’s going to give you the opportunity to use those results to decide, A) do I want to continue pursuing this based on those results? And that may look like an iteration sprint where we follow up with another design sprint-esque workshop to go through those findings and create another prototype to further get those testing results done. It might be if it’s a larger project, more into a discovery and user research phase where we start building out new projects or new potential products. If it is very well defined and it’s maybe a smaller feature that you’re building, you could go into a product phase, but typically, it will result in some sort of followup that’s going to require some further definition. But it does get you much farther on that path than if you were to not do it.
Tobi:
What’s your favorite thing about design sprints or most significant takeaway from them?
Ryan:
I think that one thing I’ve seen with design sprints is how hyper-focused you become because in this day and age, very rarely, do you have the opportunity to set aside that much time to solve a problem. I’ve seen when you get the right people in the room that are spending those core two days to solve this problem, we limit the distractions, so phones outside meetings, et cetera. If this is truly a core problem, then we should be able to devote this time to it. So much can happen in that small amount of time that you don’t even realize because we’re constantly having to switch between things. It’s pretty amazing to see the results that come out of that.
Dan:
We’ve had design sprints go a couple of different ways, too, right? We’ve had some that have moved on to a discovery phase. We’ve said, “You know what? This is a really great problem that we can potentially solve and build something around. So let’s move that into a discovery phase.” And then we’ve also seen some where it’s like, “You know what? This maybe isn’t the best problem to be focusing on right now.” Both of those are successes because one group is marching towards a potential great product. The other one is there avoiding investment into something that likely would not have been successful anyway. So design sprints are really neat because in a lot of ways, no matter what comes out of it, it’s success. It’s kind of like a win-win in that situation.
All right, Ryan, thank you so much for joining us breaking down the five days that going in to a design sprint. Design sprints are incredibly valuable. Like we said, it is a win-win. Sometimes you move forward and you build the product. Sometimes you say, “You know what? Let’s pause. Let’s rethink this,” which also avoids lengthy and heavy investment. Design sprints are part of an engagement that we have called our get started engagements; design sprints, discovery phases, which we talked about a little bit and we’ll talk about more later on, but also our proof of technology engagements. It’s all part of this whole get started package that we talk about a lot because quite honestly, getting started on a digital solution on a product is the hardest thing. That first step is extremely difficult. The design sprint allows for that baby step before you have to learn how to crawl before you learn how to run.
Tobi:
And it’s validating whatever your plans are.
Dan:
There will be a link in the description to learn more about those get started engagements. As we’re wrapping this up, I got to say thank you to everybody that worked extremely hard on this. Thank you to Ryan, Tobi, Dave, Diana, Elise, Jacqueline, Derek, not Billy, but he’s got his headphones on. He always likes to come and watch us, which is really beautiful. We have a lovely audience here that I will tell you is about 50 people. Don’t forget to subscribe to the channel, hit the bell icon. Don’t forget to go check us out on all of our other social channels. We have a lot of different content, different video content going in, especially LinkedIn, some lovely photos of Tobi on Instagram. There’s always a little bit of love on Twitter, not so much on Facebook
.
Tobi:
No, no Facebook.
Dan:
No, we don’t do that. All right.
Dave:
Want to answer a question?
Dan:
Oh, we have questions?
Tobi:
Yeah.
Dan:
We got way too excited. That shows that we’ve only had one before.
Dave:
Can you do back to back, back to back to back design sprints?
Tobi:
Love it.
Ryan:
Yeah. Actually, one of the typical patterns that we’ll see is we’ll do one design sprint and then we’ll follow that up with what’s called an iteration sprint because the findings from the first one will start to bring to light some of the questions that maybe we are target’s here and we got really close. We got really close to the target, but we see the race on the feedback, how we can incorporate some of that to get even closer. So we’ll do an iteration sprint and incorporate that feedback and then start prototyping out from there.
Tobi:
That’s a great question.
Dan:
Were there any others?
Dave:
That’s it.
Dan:
Two total. Two total, Tobi. All right, well that’s good. Hey, you have the badge of having-
Tobi:
Two in a row.
Dan:
Yeah. Okay. Yeah. You have that badge now. All right. Thanks for tuning in. We will talk to you in two weeks. Bye-bye.