NOEL:  Hello and welcome to the Tech Done Right Podcast, Table XI's podcast about building better software, careers, companies and communities. I'm Noel Rappin. If you like the podcast and would like to encourage us to continue, please follow us on Twitter at @Tech_Done_Right or leave a review on iTunes. iTunes reviews really do help new listeners find our show and we thank you in advance. We also have a new newsletter where you can find interesting stories, podcast news and some of the essays from me. You can subscribe at http://TechDoneRight.io/Newsletter.

Today on Tech Done Right, we're going to be talking Design Sprints with Zeke Binion and Kai Haley. Zeke, would you like to introduce yourself?

ZEKE:  Sure. I'm Zeke Binion. I was formerly the director at Table XI. I helped set up Design Sprints there and today, I run a little site called CodeForDesigners.com. The goal of the site is really to help designers who have learned the basics of HTML and CSS and take their skills to the next level.

NOEL:  And Kai, could you introduce yourself, please?

KAI:  Yes, absolutely. I'm Kai Haley. I'm an interaction designer on Google's Design Relations Team. I also lead the Sprint Master Academy, which is our internal program to train Googlers on our Design Sprint methodology and I have trained over 200 Sprint Masters to date.

NOEL:  We're here to talk about Design Sprints and I think that the first place to start is what are we talking about? What do you mean when we're talking about Design Sprints? Who should use them? What are they good for? What actually are they?

KAI:  At Google, we think of a Design Sprint as really a tool for answering a critical business question. We do that in five phases that are organized to encourage divergent and convergent thinking. We try to generate a broad range of ideas and test them very quickly with rapid prototyping and we do this with real users in generally less than five days. Many different kinds of teams at Google use Design Sprints, ranging from your product teams to our internal tools teams that actually create tools for Googlers and we even have our training programs  use Design Sprints as well.

NOEL:  What is a specific example of a kind of problem that would be really well-suited to a Design Sprint?

KAI:  Often, one of the most common Design Sprint that we run at Google is an existing product sprint and this is where you have a v1 of your product out there and you're really looking to improve it. You have some data, some metrics to show what's working and what's not working. Hopefully, you might have some user research that would help inform the Design Sprint.

That's one of the most common use cases for one but we will also do a sprint when we are really looking to generate a shared vision for the team of what the product could be. That might be something where we want to imagine what two to three years from now we might be able to offer in a specific space and that would be what I would call a vision sprint. We do different types of sprints. We also do process sprints and that's where you might want to bring a team together to improve a process that you have and streamline that process and make it more effective.

NOEL:  But there's some structure to this. We don't just throw everybody in a room with a bunch of sharpies and post-it notes and tell them to go. What makes it a Design Sprint and not just a bunch of people sitting in a room?

KAI:  Yes, what makes Design Sprints different than regular brainstorming? We have a very clear structure and before we start a Design Sprint, we always identify "what is the challenge that we're going to be taking on". We work together as a team to define that challenge and then we set up our agenda and our structure based on the deliverables that we want to get out of the end. Everything is very targeted and every minute is actually scheduled so we will do brainstorming, we will do sketching but we're utilizing every moment that we have together as a team to really maximize our cross-functional collaboration.

NOEL:  The book _Sprint_ sets a structured process. How strictly do you stick to that?

KAI:  We at Google actually use a slightly-modified version of what Google Ventures... the method that Google Ventures uses is tailored to startups and tailored to smaller companies or companies that are able to get specific roles in the room and they don't do a significant amount of planning in advance. They allocate five days so that they can utilize the first day for a lot of the planning.

At Google, we're a much larger company, we have to do a lot of that planning up front. It's very hard to get people to come and dedicate three to four days if it isn't very clearly defined what they're going to be working on. Our sprint lengths are usually a little bit shorter and our process is more tightly structured. On the first day, we bring the team together and we do lightning talks. We invite knowledge experts from within the team or from outside of the team to help really look at the problem space from 360 degrees and we really build shared knowledge. We're creating shared knowledge, shared vocabulary and basically, a collective brain for problem solving. That's really what we do on the first day.

Sometimes, we'll actually move really fast and by the end of the first day, we'll generate sketches and ideas for what we want to prototype. The second day is where we're deciding what to prototype and beginning the prototyping process and then by the third day, we're pretty much ready to put the concepts in front of users and we spend a second part of the third day, primarily focused on putting our concepts in front of real users.

NOEL:  You actually build a prototype, usually some sort of prototype. You actually are doing user testing at the end of the sprint. That's the goal, right?

KAI:  That's where we see the most value from a sprint. There are other situations in which we might do just a portion of the process. We might do a diverge stage where we're just generating a broad range of ideas for the team but the value where we're really able to save time and know that where building the right thing comes from validation with users. When we say prototype, it's really important to understand that we're not building any functionality that we don't need. We're not building any backend.

When we say build, mostly we're putting together a facade of the experience so that we can get real feedback from users and we can make them actually feel what the experience is like. But we don't spend any time mapping out entire flows or thinking about that the structure behind it we're just trying to get that experience communicated.

NOEL:  Yeah, we used to call those 'Wizard of Oz Prototypes', don't look behind the curtain. Zeke, how did you start looking at these and how have you used them to help clients?

ZEKE:  I think it's interesting. From the origin when Design Sprints came into my purview, I think was probably around the time where the Google Ventures Team had begun writing articles about it. I think the first article I remember seeing out there in the wild was the one that was on Fast Company's website and that outlined the whole process at a broad level.

From there, I ran into a ton of people in the design community that had already begun to implement Design Sprints at their own agencies so I got a lot of the backroom chatter, if you will about the war stories behind sprints, how they implemented it at their company, how is it solving problems for their clients. 

Starting fast for a lot of the kinds of clients that Table XI works with, those startups, those smaller businesses -- it is a lot of the same problem, I think the venture's team was having so it became a really interesting model, I think for a Table XI to begin to explore. Much to, I guess the credit of Jake Knapp and his team, the book was a pretty handy instruction manual but it was really great to see it documented very well before we were even able to begin implementing it at Table XI.

I think one of the kind of interesting things I think of when I think of sprints is part of the assumption we've had at Table XI for a long time is that we're working with clients who need to take a little bit of time to explore their business and either get internal folks aligned or even just get us externally aligned with their vision. We fall in a lot more into the ventures model but I think as it's matured we're coming into the larger Google model, which has teams that have worked together, they know the business, they know what's happening what their users and they understand the problem a little bit more. I'm very curious to also hear about what that shift feels like from a structure perspective, at least for you guys on the Google Team.

KAI:  In terms of shifting from building in a lot of time into the Design Sprint to really explore your business model and your business goals, Jake has done an amazing job with the Sprint Book. It's a really, really great way to learn how to start thinking this way and the sprint mindset is let's develop a hypothesis, create an experiment and test it with our users really fast before we start investing a lot of time in building something that we don't know has value for our users.

The high-level goal with Design Sprint is to utilize design thinking methods, user-research methods, even business analysis methods to really understand your users and understand your business and create some experiments and some tests to move it forward and to really make your product more user focused. The flexing and the adjusting of that methodology is really the benefit of it so you can take a look at what does your team need right now? Do you need to have a discussion about how are you going to increase acquisition and who are your highest valued customers? Do you need to have that kind of conversation or is it one where you really just need to bring together a developer and a designer and a researcher to explore what are the technological opportunities in this space that you haven't looked at before that will really provide great experience to our users and leverage cross-functional collaboration? Or do you need to create team alignment?

As you are saying, a lot of times you have people working in parallel or in silos and you really want to bring them together to create alignment on what your product should be. I highly encourage people to think about it as a flexible process that is really intended to help you get learnings quickly from your users.

NOEL:  Kai, you train people to facilitate these kinds of meetings? That's right?

KAI:  Absolutely, yes.

NOEL:  Okay. I want to make this a little bit more specific. Let's try and train me. And Zeke, you have a lot of experience, you can weigh in too. I'm mostly developer, I have a little bit of a UX background too. I have, let's say a client that -- I want to be specific but then I don't want to point to an actual client -- they have a long-standing website, they're an e-commerce business that also has a brick and mortar. They're concerned with how their website reflects their company and maybe reflects their business values. This sounds to me like the kind of thing that would be a Design Sprint. What do I need to know to be able to facilitate one of these? What would make me a good facilitator? Is that too big? Should I ask smaller questions?

KAI:  No, absolutely. You know, being a Sprint Master, as we call them at Google is kind of a combination of things. You have to have a good understanding of product strategy so you might start with, you know, asking a whole lot of questions: what are your goals, where do you see this website in a couple of years?

NOEL:  And this is the kind of prep work we would do before the sprint?

KAI:  Yes, so you would have a conversation with your client or with your team depending on how you are starting this process to plan the sprint and usually, what we do is we'll start writing a sprint brief together where we identify what the challenge is that we want to take on, what user research has been done, what analytics might you have from that website that would help you understand, where are the break points or what's not working today?

Sometimes at this point, you might also realize that you need more user research. I often will recommend, "Let's go and do some interviews," or, "We'll run a couple of surveys to make sure that we have enough information that we can actually come together and problem solve this challenge."

NOEL:  Would this include like competitor analysis or just sort of more generic brand strategy kind of stuff like anything that we can throw into this, I guess not anything...

KAI:  When you're starting to plan a design sprint, what you're really thinking about is what content can I bring to that Understand phase, what lightning talks I'm going to schedule? One of them might be, "I'm going to ask somebody on the team to put together a competitor audit," as you mentioned before. Who else is solving this problem really well in my problem space? You might ask somebody to come and give a presentation on the user perspective. Who are the users? How do we think about them? Do we use personas? Do we look at behavioral types? In your mind, are all customers the same or are they not? How do we want to better meet their needs? Do we know what their needs are?

The Sprint Master is doing a lot of this planning of making sure that you have the right inputs to bring to that conversation, then the other thing that the Sprint Master -- it's kind of beyond just facilitation that we're talking about here, but to actually organizing this event so that it can be really successful. Part of that is making sure the right people are in the room. You might have to have a couple of meetings with your client to say, "Who are going to be the primary owners of the outputs of the sprint? Who has a lot of great knowledge to share? Who has the ability to reject the ideas?" And you want to get all of those people there in the room for the whole time.

NOEL:  You want people that buy into the outcome of this sprint so it doesn't help if --?

KAI:  Absolutely.

NOEL:  Right.

KAI:  And also, because there's such great collaboration value here, you wouldn't want to have one group of people do a sprint and then hand it off to somebody to just implement. The idea is you're all building, not just ownership but you're leveraging the skill set of your team well. If you have a developer who's working on the site, you want them in that sprint because they will then absorb all of the shared knowledge and they will have a good strong perspective on who the user is. The point of this is to be as user-focused as possible because we know that's what creates the best experiences.

But to your question about facilitation, once you actually get into the sprint, there are lots of things that a Sprint Master has to do to really help people to understand the process, to go through the process and to come out with really strong deliverables that they can act on.

ZEKE:  It seems to me a lot like Sprint Masters are almost -- they're sort of guides. They kind of help people move along, help people by answering questions or posing questions, to clarifying where we're moving inside of the sprints. I think that's a really interesting facet of the sprints overall, regardless of structure.

NOEL:  Does it help to have a Sprint Master who is going to be the project manager on this project or do you want somebody from outside? To what extent do you want domain knowledge versus sprint knowledge in your facilitator?

KAI:  Generally, we value the outside perspective and the strong understanding of the process over domain knowledge. We often, at Google will have somebody run a sprint for another product area, rather than their own. Also, it can sometimes be difficult to separate yourself from actually the problem solving and the content so if you are the UX lead or the owner on the project, you will have a lot of opinions and probably want to actually participate.

NOEL:  Yeah, I guess it's hard to run and participate at the same time. I think that would be really challenging.

KAI:  I've done it before and let me tell you, it's not advised.

NOEL:  Zeke, you probably have some experience on that too, right?

ZEKE:  Yeah, I think I've pretty much been exclusively in the position for the most part of both facilitation and participation. It's certainly not an easy hat to juggle. I think as a facilitator, I had those moments I try to train others so that they can help assist in the facilitation when I know I'm going to run into a spot where I'm more opinionated than I should be.

NOEL:  All right. I've got my client. I've identified some experts to give lightning talks. I've identified the people who can make decisions in the room. We've got our information on Day 1, what's the first thing that we do with that information?

KAI:  Well, I always follow my lightning talks with a "how might we" brainstorming session and that is during the lightning talks, we have everybody, all the participants in the sprint capturing opportunities that they hear on sticky notes. We call these, 'how might we's' because you're really trying to take challenges and pain points of things that you hear and reframe them as opportunities to be solved but they're not solutions yet. They're not ideas yet.

They're places that we're going to start sketching solutions for later and it's really capturing everything that's in everyone's heads and then putting it all together into this collective brain that we're creating. The brainstorm basically is each person reads out their sticky notes, put them up on a board or a wall one by one. Then we start to affinity map them. We look for natural categories that emerge, overlaps and we're really basically trying to develop a way to enter the problem space, what categories are important, what should we be thinking about and then we conclude that with a voting session where we actually let everybody in the team say, "I think this opportunity is probably the most important one that we should address," or, "This one's pretty important as well and then we prioritize."

NOEL:  First of all, everyone is specifying their opportunities using the specific structure of "how might we make our customers comfortable online",   
how may we improve conversion or something like that". Then the goal there is to pick the one or maybe two questions you're going to be addressing to the rest of the sprint, is that --?

KAI:  Actually, we don't do that. We're not prescriptive at this point. We're still in this divergent stage. What we do with the voting is let people express their opinion on what they actually think is the most important because when you step back and look at that board of post-its, it can be really overwhelming and there's a lot of content, there are a lot of potential spaces to problem solve around and you know that you won't touch all of them.

The other thing is we don't ask people to self-edit or craft a very specific and well-articulated 'how might we' statements. That is something that some other design thinking methods do. We're just going for quantity. We want to be as creative as possible and just get everything in there so then the voting process just helps to pull from all of those opportunities, the ones that we're that we're going to start thinking about in the next stage when we start sketching.

NOEL:  Okay. We start sketching based on the most popular subset of these opportunities that we've identified.

KAI:  We actually don't start sketching right after this. We have talked about sketching but we might do a couple of things between the 'how might we' brainstorm and the actual sketching. For example, we might do some journey mapping and take a look at how does your product actually fit into people's lives, beyond just the user flows that you have. We might take a step above and really look at what are the use cases and the experiences of your users and where are the pain points and how does your product fit in there?

NOEL:  Why the user might be coming to this website in the first place, what problem they're trying to solve?

KAI:  Yeah and outside of their first entry point to the website but what was the first time I actually had a need for whatever it is that you're offering. When did I decide I wanted to plan a trip? I was traveling on the subway one day and I thought, "Oh, I should really go to Tahiti," so where's the beginning point in a user's life of when they have the need, all the way through to the final completion of when you fill that need.

NOEL:  What's the goal of that within the sprint?

KAI:  The way that I use it, journey mapping and user experience mapping is a very mature field and there's tons of great resources on this. I'm using it just very much for the context of the sprint. What I want to do is make sure that we're not focused too much on the existing flow or experience that we've designed and that we're really looking for opportunities to meet users' needs better. We're really thinking about what users' needs are and very often, when you're building a product or a website, you get very deep into the weeds of what you've already outlined and your problem solving around these structures that you've set up that maybe aren't the best for your users. It's a gut check, a step above of what you've created to make sure that what you're working on actually really is meeting users' needs.

I do it in a very short like thirty-minute timeframe. There are some sprints, especially at Google where if you're working on a process sprint or something much more entailed, you might actually do a sprint just around journey mapping, where you'll create a user experience map for multiple users that are using your product so you can really understand how it's meeting their needs better. That might be something you spend half a day on or a couple of hours on. It really depends on the needs of the product.

NOEL:  We'll keep going with the 'travel' example. The purpose of journey mapping basically is to contextualize the opportunities that we see within what the users might be doing, is that correct? Is that fair?

KAI:  Absolutely, yeah.

NOEL:  We started with this journey map that starts with the customer that sees a picture of a sunrise, a sunset probably on the subway and decides they want to go to Tahiti and it ends with them purchasing tickets through our website. This is good. We have no travel-related clients so this won't be identifying --

KAI:  It might actually end when they get home from their vacation.

NOEL:  Oh, okay, that's good.

KAI:  And they're happy and they're done. You really have to think about the edges of this experience. It can spread out in a lot of ways.

NOEL:  That's a really good point. 

We've identified that, we've identified an opportunity. We'll say that some of the opportunity is maybe like how might we convince a user that our travel service is the one they should use, how might we give the user a feel for their vacation from our website, something like that? Does that seem reasonable?

KAI:  Usually, we would be looking at how might we make it easy for our user to compare deals for specific things. You certainly could say, "How might we reach our users?" And if you want to focus in on something like promotion of the site or there are different stages obviously in your project in your product development but you will think about the challenge that you've taken on and your 'how might we's' will be very much focused on. If your challenge is, "We'd like to design an experience for people to book travel, say mobilely on their phone," it's very easy and depending on what your product is, you will define what your challenges. Then your 'how might we's' are going to be very much tailored to that challenge.

NOEL:  Now, we start to sketch. I mean we've probably had a day boundary. Probably gone home, got a good night's sleep.

KAI:  Well, it depends. I often push people to sketch on Day 1. We might want talk about success metrics before we began sketching because it's really important that the team all agrees on what does success look like for this project, what are we going to measure after we launch, what are we going to come back and say we reached our goal? Is it X number of people, booking travel per month? Is it X number of new users? You're going to be having some of these conversations about your business goals at this point. But you really need to provide some criteria for making your decision later on what you actually want to test.

At this point, you might also talk about what sprint questions you have, if this is a tool for answering a question. What assumptions or hypotheses do you have about what your users want to do? One assumption might be, "I'm assuming that my user wants to be able to book their travel in one go and that they don't actually want to go and revisit and do this over a couple of weeks' time." Let's test that assumption. Let's put something in front of users that shows them how easy and fast it is to book.

You may find that users actually like to think about it a little bit. They like to compare. They want to do this over a two-week time period but you have a set of assumptions that you're working under that will be driving a lot of your ideas. Often before we start generating ideas, we might discuss assumptions and questions or we might discuss them afterwards. It really depends on a team, then we'll start sketching.

NOEL:  Yay!

KAI:  I know you guys are all really excited to start sketching.

NOEL:  I'm guessing is that a real thing? Zeke, in your experience too, are people are really eager to start brainstorming and sketching?

ZEKE:  You know, I think honestly the designers are. In my experience the room is always a little afraid to pick up that pencil.

NOEL:  The designers are afraid or the non-designers are afraid?

ZEKE:  Non-designers.

NOEL:  Are they intimidated? Is that something you have to overcome?

ZEKE:  I think there's a little bit of intimidation. I think there's also a little bit of comfort in the sort of doing the job that you're used to doing. If you're a developer, your first instinct might not be to sketch, although there are a lot of great developers who do. Same might be for a project managers or someone else in a business analyst's role.

NOEL:  Okay, so as a facilitator then, I guess one of your jobs is to make sure everybody is comfortable. You don't want to just sketches from the designers. You want everybody, I'm assuming, to participate so what can you do to make that process which is somewhat coded to some of the people's day-to-day jobs and not others, how do you make that more comfortable for everybody?

ZEKE:  What I've done as a facilitator -- I happen to be able to tell the story because it's true for me -- is I always begin the sketching process by telling people a little bit of a story about sketching. I'm a person who has a Bachelor of Fine Arts from an art school here in Chicago. I'm typically the worst sketcher in the room and it's very easy to see when I draw on a whiteboard. So a lot of it is about lowering the bar. They really are just a couple of shapes that you're drawing: a triangle, a square, a circle. There's not a lot of artistry to it, the point of sketching in this situation as to convey your idea, not necessarily to be a Picasso.

KAI:  Interestingly enough, I do the exact same thing. I usually give an example of how you can draw something basic with a circle, a triangle and a rectangle of some kind. I think it tends to work pretty well in terms of helping people not feel too intimidated. I've certainly been in situations where even after that, I'll have an engineer just writing bullet points of their ideas --

NOEL:  That would be me, by the way.

KAI:  Yeah, and that's not ideal because you really want to try to communicate your idea but beautiful sketches are not necessary for this at all. This process is really intended to get everybody's ideas. It's really meant to be as inclusive as possible so we use it for things where we're generating ideas that don't maybe even have a visual representation.

NOEL:  I mean, at this point beautiful sketches are -- if I'm from remembering UX research, my own history with it -- actually a little counterproductive at this point because people start focusing on aesthetics rather than the structure.

KAI:  Totally at the crazy eight stage, yeah.

NOEL:  Okay, crazy eight stage. What do you mean by crazy eights stage?

KAI:  Crazy eights is really the method that we have for getting a lot of ideas out really fast. We've found that when you apply a time pressure to people that it helps them to get past their first idea. What we do is we give people eight minutes to generate eight ideas. This way they don't get stuck on their first idea drawing it in a lot of detail like you're saying, trying to make this beautiful sketch of something that may not be the most compelling or innovative concept. We say, "Try to fill up the whole paper, eight rectangles on this paper," and it's kind of a challenge to people to see if they can actually get eight ideas down. It's really fun and pushes people really well.

NOEL:  In our travel example, we would be focusing on comparison that was one of the things that came up. You might say crazy eights -- try to come up with eight ways in which we could compare different travel options in eight minutes. I probably have one or two in my head as we're starting but now as we get further on, I'm really kind of scrambling and that's the kind of process that you're trying to capture, right?

KAI:  Yeah and once you jot one down, the next one kind of comes up. It's one of those things that it's really quiet in the room, everyone is sitting there, the timers going, you'd be surprised how many will come to you. The other thing is you have seven to 10 -- usually, we have teams of about seven people and often we have two teams -- with like 14 people, you get a ton of amazing ideas in that time period. It's really effective.

Obviously, there's overlap. People have some of the same ideas but it works really well. After that is when we start getting into the more well-crafted, very detailed sketching but this is the point where we're just trying to get the crazy ideas out there.

NOEL:  Okay, everybody's come up with their crazy ideas. We've got dozens of ideas because we've probably got eight people's eight ideas, what do we do with them now? How do you move forward from there?

KAI:  Within Google, we really like to let people share these because we see a lot of cross pollination of ideas when this happens. We do basically a presentation: you put them up on the wall, each person gets like three minutes to talk through them, you go through everybody's and then give them some sticky dots to let people express which ones they think are the most valuable to the end user or to your challenge. Then after that, people will start doing their own individual solution sketches.

As I'm sure for those of you who have read the Sprint Book, they don't share their ideas out. He's really kind of driving people towards one really, really solidly created idea per person and he explains in there the value of that. There are different ways to do it. I just want to point that out. I find a huge benefit from letting people brainstorm off of each other at this point and then the next stage you're still doing individual ideation, taking the one idea that you feel the most strongly about and creating a beautiful sketch.

I think one of the other motivations behind not sharing the crazy eights is this concern that people have about not being the most beautiful sketch. Sometimes, people might feel a little uncomfortable sharing these kind of chicken scratches. But you try to make people feel comfortable but then also understand that this process isn't always about comfort. It's really about getting the best ideas out there.

ZEKE:  You know, it's interesting. Just anecdotally I wanted to add, that's actually a similar place where we diverge from the book at Table XI. We also found a lot of value in sharing. I think we stop short of the dot-voting but we do go around the room for a few minutes, have everybody present their ideas to each other.

NOEL:  Everybody comes up within they're one preferred idea and eventually, we decide on one idea to turn into a prototype. Is that correct? And how does that happen?

KAI:  It's not quite as straightforward as that but moving to the next step is as each person --

NOEL:  I'm here to be corrected. That's my role.

KAI:  No, I mean, we talked about it and it sounds very straightforward when you say, "Okay now, let's just decide what to build," but when it comes to the deciding stage, it can actually be quite challenging to get everybody to decide on what should be prototyped. Frequently, it isn't this whole sketch in its entirety is the concept that we build. Often, you're taking from one idea and another idea and you're putting them together and that's where the storyboarding stage comes in really, really handy because you can start pulling these fantastic ideas and putting them into a flow that creates an experience.

We'll do voting at the solutions sketch stage but usually, if it doesn't yield like one clear winner, it very frequently ends up having three or four things that we're going to put together that we want to test that are going to help us get learning. Again, you're going to go back to your assumptions and your questions. Also, the other thing that I really encourage people to do at this point is go for the riskiest craziest idea because you can always build the safe thing later. But for a sprint, you want to see what could you do here to really disrupt your field or meet your users' needs better. A sprint is a great place to do something risky.

ZEKE:  Yeah, I wholeheartedly agree. I think that's actually one of the things we prep our clients with in the beginning of the sprint because we know there's a lot of hesitancy to use as much resources as you're using to run a sprint and not come out with the final solution but honestly, you'll learn so much more by exploring the edges than you do by taking the safe road.

NOEL:  Is this, then like kind of the heart of the process, this sort of winnowing down? I guess there's sort of three phases here: generate a bunch of ideas, pick one idea to run with and then test it. Is the middle one the important one for getting consensus or shared understanding of the problem, that kind of thing?

KAI:  You're building shared understanding as you go because you're having many conversations along the way. Oftentimes -- this happens really frequently to me in a sprint -- we'll end up building two things to test. The other reason why I like to have 12 to 14 people is I can have two teams and that means I can really maximize the time and test a couple of ideas. You could either pit them against each other where you say, "Let's mock one experience which shows like a super-fast way to book a flight," versus a more detailed comparison model over here where I can pull in content from three different travel sites and then see which one works. You can sometimes pit them against each other or you can set up like two parallel concepts where you're thinking about two different parts of your product. It really gives you more resources.

NOEL:  Then you go off and you prototype the idea or ideas and you're using relatively basic tools. You're using things like Keynote or PowerPoint or just basic draw tools like we're not coding for the most part. We're mostly setting up interactive storyboards, am I understanding that right?

KAI:  Of course it depends on your sprint and your products because not all of them are digital. Maybe if you're prototyping a process, you might play act something. Or if you're doing a voice UI, you would use the Wizard of Oz Prototyping --

NOEL:  Very directly then yeah.

KAI:  Yeah, you figure out what you need for your sprint and this is another important role of a Sprint Master at the beginning to make sure that you have the skill set to build what you need to build in the sprint. If you want to make a video in your sprint, make sure you have somebody who has video editing capabilities. As we mentioned before, we're not building a lot of backend but you might be pulling in some data that you want to use to try to make it as real as possible.

I generally end up in the clickable mocks realm or again, if it's a voice experience, sometimes you can actually code a voice interaction faster than visually mocking it or recording it. It really depends on your needs. But we never spend more than eight hours prototyping. That should give you a sense of the way that how scrappy we're being and how fast we're moving.

NOEL:  And then you take it in front of users and you really just need a couple of users. What are you looking for in this phase?

KAI:  Ideally the magic number is five and after five, you start to get some of the same feedback and less than five, you're not getting the full range. I believe there are some actual research out there to validate that. I usually end up doing a six -- I schedule six because almost always somebody doesn't show up. You're have to be prepared because real people have real lives. If you're coordinating users, you think about making sure that you get to that five number.

NOEL:  Are there differences between this kind of user interview and a more standard UX kind of interview? Or is it basically just a typical user interview?

KAI:  We tend to think about it as a usability study. We're usually giving them a task and having them complete it based on what it is that you want to learn and you should be writing your interview script along with making those prototypes. To make sure that they line up really well and usually, the interview is actually probably informing some of that prototype where you're thinking, "I want to ask him about this. I want to ask him about that. I'd like to see what they do in this instance," so then you want to create those flows so that they make sense.

But it's a pretty standard usability test where you're asking them, "Tell me what you think about this page and talk out loud and think out loud as you're going through it and give me your impressions and tell me what you expect to happen on the next screen." Usually, it follows that, unless you have a specific need for the type of sprint that you're running. If you're designing a space or you're designing a process, you might need to figure out another way to test that experience, either through role-playing in some way or developing an experiment that you run on a certain amount of traffic or something like that.

ZEKE:  Sometimes, for us depending on the client, I think that's when the interview day can get a little more exotic because sometimes, we'll have a client who's really just in the beginning of a discovery process so some of our introductory questions might be things we might use if we were just out in the field asking research questions in general. Trying to think of an example without being specific to the client but maybe, you have a client who's working on a two-sided market and they want to generate a couple of ideas and really think about what this product could be. But it also may necessitate us asking some questions about their own processes to the customer. I think that's a really interesting use case, especially if you're coming in without as much research as you may want going into the process.

KAI:  And it's really helpful to have a user researcher. That's one of the roles that I bring to every sprint. Somebody who has a wealth of background in this area and can help problem solve on the spot.

NOEL:  After these interviews are done, what are the sort of standard steps do you ask people to do with the information? Where do you go from there?

KAI:  We usually do a debrief at the end where everyone comes back together and talks about the responses that they saw. Sometimes, we'll do a whiteboard note taking exercise where we're capturing visually what we hear so everyone can get a sense of what worked and what didn't work and what might we want to adjust after this. Usually, it takes a little bit of time for people to synthesize what they've learned but that's generally the close of the sprint. At that point, we might talk about next steps: do you want to set up another sprint to explore a new area? Did we learn something that now we think we should be exploring a little bit more? Did you get a lot of great feedback and you're ready to go just adjust these a little bit and start building something that you're going to get actually out into the world? It really depends on the outcomes from those user tests but frequently, there's really actionable good learnings that you can take right back to your team and start working with.

ZEKE:  You know, one of the questions that I think is interesting outside of the process is giving everyone else to be able to do this process for themselves. Obviously, there's the Sprint Book for resources but I'm curious, as a person who trains people in sprints, what are common things you run into or common issues you run into in regards to people learning how to facilitate this process themselves?

KAI:  I hear from people a lot that it's a little bit scary to jump in and do it your first time. One of the things that we do with our Sprint Master Academy is we actually give people shadow opportunities or buddy opportunities so that they can do it together or learn from other people. Kind of the mentorship model where you can go and help somebody run a sprint and see how they do it. One thing that I recommend is if you know other people that are running them, actually there is really great opportunity to jump in on other people sprints.

We look for what we call wildcards to join a sprint, which is somebody who has an interesting perspective, maybe from another product area that will come and join us for three or four days and really help move the product forward by injecting that outside perspective. A lot of times, we'll invite people to come join a sprint as a shadow opportunity but also as a participant. That's one way around that initial hesitancy to jump in and people don't want to get things wrong. They get a little nervous if they want to be able to do it just right.

I encourage people to just try it. You learn by trying and that's how I learned. It can be a bit of a challenge to convince people to go on this journey with you. The other thing is to pick a challenge and a team that maybe is not the absolutely most critical for your company or at something that's kind of like a starter challenge that you can work on and has valuable outcomes and it is important. But it isn't the one that's going to be a make or break so that you have a little bit of leeway in there and you can feel a little bit more comfortable with the learning process.

NOEL:  Great. Kai, if people want to get in touch with you or learn more about Design Sprints, where should they go? Where should they look?

KAI:  Well, we have a fantastic website https://designsprintkit.withgoogle.com that has all the methods and the process that we use. I encourage people to check that out. There some template decks and sprint briefs. I mentioned some of those things people can use and you can follow me on Twitter @KaiHaley, my name and I'm always happy to talk about sprints and give feedback on planning process. I absolutely passion about this process and feel happy to talk about it any time.

NOEL:  And Zeke, where can people reach you have they want to talk to you about Design Sprints or anything else?

ZEKE:  If you want to chat with me, I'm on Twitter. It's my favorite social network. My handle there is @EBinion. Also, you can go to Code For Designers if you want to learn about coding or just get in touch with me there.

NOEL:  Great. Thank you both for being here. I really enjoyed this conversation.  

Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. You can find Table XI on Twitter at @TableXI and me at @NoelRap. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded via iTunes or wherever you get your podcasts. You can send us feedback or ideas on Twitter at @Tech_Done_Right or subscribe to our newsletter at TechDoneRight.io/Newsletter.

Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications and custom digital experiences for everyone from startups to story brands. Find us at TableXI.com where you can learn more about working with us or working for us. Thanks again and we'll be back in a couple of weeks for the next episode of Tech Done Right.