Using Design Sprints As A Collaboration Tool

Shriya Shekhar at UXDX Community: India. Video: https://youtu.be/FcaNdy0zGZM

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Norman doors and design thinking

[00:00:01] Hi, hello everyone. This is Shriya, and I'm a product designer at Flipkart. In today's talk I'm going to be discussing how design sprints can be used as a collaborative tool. This is something which I have been experimenting with in my past companies, and we're going to be diving deep into what the benefits of a design sprint are, how it is different from agile sprints, and how they can possibly go together. So let's get started.

[00:00:33] I'm sure most of you have looked at this door in malls or in other places. If you know what it is actually called, it's called a Norman door. What a Norman door is, is it looks opposite to the way it is supposed to be interacted with. You would think that the handle is outside so you want to pull it, but actually you have to push through the door. So why is the design this way? Was there no thought process behind this? A design which requires explanation is really not thought through and is probably badly designed.

[00:01:17] These are the things in the practical world. Now let's get into something which we as designers experience every day, that is design thinking. If you just do a simple Google search, if you just type design sprints on Google and go to the image tab, you would see a bunch of images which talk about a five-step process which goes from empathizing, defining, ideating, prototyping and testing. This is a very clear-cut process which many companies and lots of designers use to put ideas into practice in front of their users.

Building an exam system at a startup

[00:01:58] Let me take you all a little bit back in time and talk about a time when I was interning at a startup. The idea there was that we were building an exam system product, and this product was supposed to have two different interfaces: the examiner interface and the student interface. In the examiner interface, the examiner is supposed to create questions of different kinds, multi-select, single select, and the students are supposed to attempt them. It looks very easy to understand. So let's see what happened there.

[00:02:33] What we were thinking was that we'd go from idea to launch and build that MVP, and it was going to be a simple three-step process. We already knew the requirements, and we would go on and build it and then launch the MVP. Probably after launching the MVP we would do some learnings, and then it would become an iterative process and go back to the idea. But it turns out that the building process obviously takes a very long time. It is not a short process. Building the entire examiner portal and the student portal was a very long process, and then launching, going back to the learn stage and back to the idea, was obviously going to take a very long time.

[00:03:24] What we want to instead do is iterate between idea and learn very fast: do step one and step four instead of going through the entire circle. When you do this with your idea of an exam system portal, you test it out without having to build it, and then learn from the shortcomings. Learn from what your users are saying about it. Learn whether they actually understand your exam system portal. How are the students feeling? What do the examiners say? Are they able to create questions? Are students able to attempt those questions or not?

[00:04:00] We want to shorten the process of going from idea to learning. How can we do that? Should we do agile? Should we just do Scrum? There are lots of words if you look on the internet. You have to innovate faster in order to learn faster. Reduce all the waste, reduce all the features which are not needed to go into the MVP, and hence become more efficient. These are all the kinds of jargon we usually hear. But what we have to instead do is take a step back and think why we are doing this, who we are building this for, and what value the solution is going to provide to the customer. And do we really need to spend our engineering effort and time and all that money building something which might not work for our users?

Where design sprints fit between design thinking and agile

[00:04:58] What design thinking says is that it's a human-centered approach to creative problem solving. It's a mindset, a philosophy, which has been around for a very long time, and you have to figure out how this design thinking process of ideating, prototyping, testing and validating is to be used. It's just a philosophy that you still need to apply to your company. You still need to have a process in place. But here is where the design sprint comes in, which is a clear process. It is step by step, like a recipe. It tells you what you have to do over a five-day process, it is very clear in its approach, and it has a clear objective and goal. So let's see what happens when we follow it.

[00:05:44] A design sprint fits exactly into the puzzle between design thinking and agile development sprints. When you have the design thinking philosophy connecting to an agile development environment, a design sprint will play an instrumental role, so that agile can be used to become more and more design-driven and more and more customer-centric. How that's going to happen, we are going to see ahead.

[00:06:18] While design thinking is a more fragmented approach, in sprints we are collaborating and we are coming together. While in design thinking we think that we are just building an MVP, taking a very long time to build something and test it out, and spending a lot of money, in design sprints we are trying to fake it. Fake an idea, fake a feature, fake-build it, and then get a response from your team and from your users.

The five days of a design sprint

[00:06:49] Let's see what this design sprint, built by Google Ventures, actually is, and now we are going to understand how you can conduct a design sprint. The journey of trying something new like a design sprint can be very intimidating for anyone. A company who's been just following an agile UX process will first find design sprints very intimidating to start with. To give you a little bit more in-depth knowledge of what a design sprint is: it's a clear five-day process which goes from mapping, to sketching the solution, deciding the best option, prototyping it and testing it.

[00:07:33] It sounds very simple, like design thinking, but it has its own clear agenda for five days, and at the end of five days you're going to have an output. You're going to be more confident about the feature that you're going to be rolling out. You're going to be more confident about what your customers are going to see, and whether it will answer your critical business questions or not.

[00:07:57] Let's say you are trying to build a travel application, where the users that you are targeting are trying to make a trip, and you're trying to have a trip builder inside the application where they can plan a free and easy tour and trip for their families or for their friends, whatever they're going to be needing. Let's say that's your goal. What you have to do on day one is gather your team, your PMs, your designers, your researchers, and understand why you are doing this project. If you are building a travel application, who are these users going to be, and what problem are you solving? Let's say you are going to solve the problem of a free and easy trip. What's the success metric of that? A success metric for that can possibly be that your users are able to create a custom itinerary for themselves.

[00:08:51] Let's go ahead with that and move into what day two says. On day two, your sprint team is going to be generating as many ideas as possible, and they are going to be experimenting with various ways in which a user can make a possible itinerary. How can they understand what places there are to look for around a particular travel destination? What are the different food options? They're going to be sketching all the possible ideas for making a custom free and easy trip for your users.

[00:09:24] On day three, all of those generated ideas that have come in to build a free and easy tool for your travel application have to be dot-voted by all the participants, and that has to be done based on certain criteria: that you found a particular idea very interesting and that it can be taken ahead based on certain reasoning. You dot-vote them, and all the members of the team are going to select one of those ideas.

[00:09:53] On day four, if you have a few solutions, you're going to be creating prototypes for your travel application: these are the most important places to go, and a flow for that. How can a user build a free and easy trip? How can they add destinations? How can they purchase tickets for nearby attractions? A representative solution of this concept has to be built by your team, and all the interaction touchpoints are going to be developed. Day four would be more rigorous from a design point of view, because designers have to spend more time making this prototype good enough to test with your users.

[00:10:40] On day five, you're going to be gathering feedback on this prototype from your target audience. Remember, obviously day five cannot come abruptly. You need to shortlist your stakeholders before you start day one, so you definitely have to do background work before you come to day five, so that you can get your users on board and start testing. Evaluate your product, evaluate the idea, and most importantly, evaluate the goal which you had set on day one for this travel application.

[00:11:13] What's the outcome? Do you stop here or move ahead? It's just a prototype. You've just spent five days on it. Maybe you can scrap it, or maybe you can go ahead with the idea. Understanding what the gaps are at the end of day five with your customers is very important to see whether you want to continue or not. Your product team or your leadership team would appreciate it more if they can see a tangible output at the end of five days. Five days is a very short time, so they can see if it's going to be worth investing a long agile development sprint into this idea or not.

Convincing your team to try a design sprint

[00:11:58] Now, how do you convince your teams to try a design sprint, if this is something new that they have to try? If they are into agile UX and they want to try a design sprint, how would you convince them? You definitely have to wait for the right moment or the right project. It doesn't even have to be a complete project. It can just be a small idea that you want to test for your product. Let's say, with this travel application, only that you want to build a custom itinerary for your users for free and easy trip planning. Maybe this is something new which your company is trying, and you want to see if design sprints can help here or not.

[00:12:37] You've also got to understand how the whole team is structured and whether it's right for your team structure or not. Most importantly, once you have run one design sprint, document the design sprint. Document the learnings that you had at the end of five days, so they can practically think about whether they really want to invest in something like a design sprint or not. We are going to see ahead how we can insert design sprints into our agile development space.

Bridging design sprints and Scrum sprints

[00:13:04] Now let's see how we can bridge the gaps between design sprints and Scrum sprints, that is, turn the prototypes that you have built, which are the fake product, into working products. Obviously we do not run design sprints in a waterfall process. We are working in an agile space. Continuous improvement is the agile manifesto, which we are going to be following in design sprints as well.

[00:13:28] When we are incorporating design sprints into agile sprints, we need to understand the right moment when you need to include the design sprint. Again, let's say, for example, for the travel application you run two sprints, and you have a good understanding of what the users want at the end of sprint one and sprint two, and you are building your custom itinerary. Two weeks of dev sprints, four weeks of dev sprints have happened, and then you suddenly realize, maybe I also need to collaborate with, let's say, a cab booking facility. That's an interesting feature that would go in a travel app. You're going to a new place, you are not sure about logistics and the travel options that are available in a new place. Let's say you want to introduce that feature now, after the end of four weeks of dev sprints. Now you can run a design sprint again, test that idea within five days, and see whether you really want to invest in it or not in terms of development.

[00:14:30] Finally, when a design sprint handoff is happening at the end of five days, you have a validated learning or your prototype. All of these will go as entries into the backlog of an agile sprint, and this has to be done clearly in the form of user stories. Let's see this mapping with the help of an example. Let's take the example of the same travel application, where the user activity can possibly be adding tourist places of attraction to build a custom itinerary.

[00:15:04] For that, they have to visit the product pages of those tourist attractions. They have to see the prices, they have to decide the timing, and then they have to keep adding all of that to a custom itinerary which they want to build for a day. Those will become the user tasks. User subtasks can probably be making payments for all those different tourist attractions, and definitely there are going to be empty cases and dependencies. Essentially, what you have to understand is that you have to break a huge user activity into sub-activities, and all of these sub-activities are going to go into the backlog of your development sprint.

[00:15:40] You have to think in a very modular way, so that when you are communicating this to your engineering team, when you are collaborating on this, you are building a shared understanding of why this breakdown has happened and why this split has been done into user stories. Coming to collaboration with the development team, you have to be working very closely with them. When you are at the end of day five, you might have to spend a couple of days more to make the flows even more detailed as a prototype for your development sprint.

[00:16:13] Also understand the technical feasibility of the design. Obviously there will be some gaps, which your engineering team will help you understand, and incorporate the feedback into your next design sprint. When you are understanding how your teams are working and how your engineering is working, you can incorporate that feedback into your design sprint if it's needed.

[00:16:35] Finally, the takeaways. What I think is a great learning from design sprints, since we are talking more in terms of the agile space, is that you fail fast and learn, and take better decisions in the next iteration. Your ideas and suggestions from different stakeholders, be it engineering, be it the product team, be it your business team, play a very important role in that five-day process, where on one of the days you're going to be dot-voting the ideas. So ideas and suggestions are key to understanding how collaborative design sprints are. And a strong feedback loop obviously goes a long way to nurture your designs and build a better program, and finally a better product tomorrow. On that note, I come to the end of my presentation. It's a wrap. Do feel free to reach out to me on any of the social media platforms. I'm available on all of the handles that you can see. That's it, thank you so much.

Q&A

[00:17:42] Host: Excellent, thank you very much. That was a really great overview of the design sprint process. I have a question, actually, because I thought it was quite interesting that you brought it up at the end: that the engineers might have a challenge with the feasibility of some of the ideas that you have. Do you have any examples of that happening, and have you ever brought the engineers in earlier to actually participate in the design sprint itself?

[00:18:08] Shriya: Yeah. When you're having that first design sprint and you're ready with very wild ideas and fancy ideas for an MVP, it might not come to market because of the technical challenges or the timeline challenges there might be. Maybe they are able to build it in consecutive sprints, but in the beginning they wouldn't be ready to spend so much time on a complicated requirement. I have faced such challenges as well, where the engineering team says, see, we cannot do this flow, but we can possibly do a shorter version of this for V0 and then improve it going ahead. Because learning from what we did in the previous design sprint is the key going ahead. So yeah.

[00:18:56] Host: Excellent, that's very good. And the other one that I've often heard people say: the engineers are one side of the design sprint, and the other one is, I don't have time for this. This is five days of focus on this one problem when I've got 20 other things that need to get done. So how do you handle that kind of scheduling issue?

[00:19:21] Shriya: We always have that pressure of deadlines. And as designers, we think so creatively, and then if all of those ideas are shut down, if they are not taken ahead, we may feel that the hard work we have done over that time is not going live. I think what is essential here is having that influential attitude in you, so that you can convince your team: hey, this is the feature that's going to make or break the experience of the user. If you put it that way, then even if it's a very crazy feature which takes a little bit of their time, they would take it. That's what I have observed. You have to have that influential attitude in you to convince them first that this is going to make a huge difference. Users are going to be feeling very excited if they see this. This is going to be the differentiating factor. If you can attain that sweet spot, then there's nothing like it. Once you start convincing them, then even for your bigger ideas they'll get convinced.