It's Not a Marathon, It's a Design Sprint

Elaine Lim at UXDX Community: Winning Feedback and Solutions for Design Innovation. Video: https://youtu.be/7aTJGm2sepY

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.

What a design sprint is

[00:00:00] Hello again, I guess, and thanks, Sarah, for taking over when it's a Murphy's Law day. As mentioned, what I'm trying to drill into everyone right now is that throughout this 30-minute short sharing, I hope you're able to take away a taste of what a design sprint entails, and also explore how it could potentially be applied in your own organization.

[00:00:28] Just a little bit about myself. I'm currently a UX instructor at General Assembly and a partner at AI Shophouse [?], a consultancy specializing in design thinking as well as UX design. Having implemented design sprints across multiple industries, including education, public safety and trade finance, I'm happy to be able to share my experience of implementing design sprints with you today.

[00:00:53] Having had that short introduction, let's get right into what a design sprint is. Essentially, a design sprint is a structured process that enables a cross-functional team of six to eight people to work together to solve complex problems in a short amount of time. The design sprint process was developed by ex-Googlers Jake Knapp, John Zeratsky and Braden Kowitz, and it was adopted by Google Ventures for the startups in their portfolio. The thing about startups is that they tend to have limited resources and a limited runway to get things right. The design sprint process was the right fit for them, because it allows them to get results and test ideas in a short amount of time before they decide to commit to them.

[00:01:48] Through design sprints, teams benefit from effective collaboration in a time-boxed and structured process. The optimal size of a sprint team is usually six to eight people, and this allows them to contribute ideas as well as opinions in a very meaningful way, and they also feel very vested in the sprint outcomes. Secondly, because they are focusing on a single challenge, they are able to develop a solution and evaluate it from different perspectives for feasibility and potential, and this increases the chances that the solution or idea will be successful. And as I mentioned, the ability to test these ideas before committing resources to build is a great one to have, especially for companies with limited resources.

The five days, from goals to testing

[00:02:46] With that in mind, let's dive deep into the design sprint process. As mentioned, it is a five-day process, and each is a full day. A design sprint typically runs from 10 a.m. to 5 p.m. every day, and it covers five days of work. Each day of the design sprint has a different theme, and this mimics design thinking, from problem discovery to solution design.

[00:03:22] We typically start a design sprint on a Monday, when we start to set goals for the whole sprint as well as for the team. Secondly, we also try to do discovery of the problem space through activities such as expert interviews, where the team gets an in-depth understanding of the subject matter or the problem space from experts. This creates a common ground from which teams can take off and move on to the other stages of the design sprint. At the end of the first day, they decide on a focal point, a single challenge for ideation and problem solving.

[00:04:07] Bringing the challenge into the second day is where all the ideas come. The team brainstorms through a process called the four-step sketch, where they work alone together. This concept is an interesting one, because they are encouraged to work individually, so that there is time for them to develop ideas, get inspiration and think deeper into the problem space itself. This also prevents groupthink, where the team comes together to form a single solution. The resulting outcome is that on Tuesday you get diverse ideas that can work to solve the problem.

[00:04:56] Once that's done, the team goes into Wednesday, which is where they decide what solution they will be choosing. At the start of Wednesday, the team puts their individual ideas up and conducts an activity called a gallery wall, where they assess and review each item individually again, and without talking. What this does is that the ideas need to speak for themselves. They need to be self-explanatory, because the owner will not be there to provide any supporting explanations. The team then assesses and chooses the idea that has the highest potential of addressing the sprint challenge as well as the sprint goal itself. That is followed by an activity called storyboarding, where the team aligns on how the solution will be used in the problem space context.

[00:06:04] Come Thursday, the team splits up into different roles to produce a mock-up of the solution to be tested for the intended usage. This is where you create a Goldilocks-quality solution to test out and communicate the concept to potential users. We call it Goldilocks because we don't want to spend too much time on it. If we spend too much effort building this prototype, we feel that the team will get too vested to pivot away from the initial solution or to iterate on it. The interviewer, who will be conducting the usability testing or user testing, will also be scripting the test and doing a trial run of the testing for the next day.

[00:07:00] Now we've come to the last day of the design sprint, and this is where the truth is revealed, because it is the testing of the idea or solution with potential users. We do qualitative testing with five users. During this testing we present the prototype to the user and ask them to perform a series of tasks while thinking out loud as much as possible. The interviewer is encouraged to ask open questions, so that the users are able to provide as honest an opinion as possible. Behind the scenes, the rest of the sprint team is observing and taking notes of the user's reactions and thoughts. At the end of the day, all these insights are aggregated and used to inform the next step for the solution.

The sprint team and when to run a sprint

[00:08:04] As you can see, the design sprint process is actually quite simple, but it is really intensive. So it's of utmost importance that you assemble a team that is purpose-driven as well as vested in the outcomes of the design sprint. In every team there should be a facilitator who is responsible for driving the agenda of the overall sprint process. This not only means managing time, but also encouraging each sprint team member to participate fully, and establishing mutual understanding within the team. They also need to be taking notes and creating group artifacts, the shared memory.

[00:09:02] You will also need one or two deciders, who will be the decision makers for the whole sprint. This is like the CEO of the sprint: when there are any decisions to be made during the sprint, those decisions are deferred to the deciders. This helps ensure that the team does not get stuck or hung up on making decisions and is able to progress with the agenda of the sprint. Once those two roles are decided, you will need to find five or six team members from different functions, because that is the true value of a design sprint: bringing people from multidisciplinary teams together to solve problems. Depending on your problem space, you might have one or more of the experts we've listed here, or even none at all.

[00:09:59] You might be thinking: are all problems suitable for a design sprint? Mostly, but there are situations where the design sprint is most suitable, because it can give the best outcomes. In particular, the design sprint process flourishes in problem spaces that would benefit from multidisciplinary expertise or perspectives. If you are thinking about using a design sprint for a visual design problem, it might not be such a great idea, because the problem space is really specific, and you might be better off getting a team of designers to come in, provide some ideas and decide during that session. Design sprints also work great when there is a huge potential impact on the customer as well as on your organization. In these scenarios it is also easier to get buy-in from your management, because of the potential return on investment.

Adapting sprints for small, remote and large organizations

[00:11:10] With all this in place, there are some inherent challenges in every organization that make adopting the design sprint challenging. The good thing is that the design sprint methodology has been around for some years now, and a lot of teams and organizations have been able to adapt it to their own specific use cases. These are some of the ones that I've experimented with and tried.

[00:11:38] The first challenge comes from small organizations, where your colleagues can't afford to take time away from daily work for a full design sprint. Coming from a startup previously, I truly appreciate this challenge. What I've tried to do is spread the activities of a design sprint out over two weeks, and only include the wider team for the activities covered in the first three days. That leaves the prototyping and the testing to a product team or design team. The only catch here is that for the team not to lose steam, you will want to complete all the activities within the two-week period, and also create an engagement strategy where you encourage them or remind them of the progress that has been made so far. Lastly, you also need to create a socialization strategy for updating and engaging sprint team members when the testing has been completed and decisions need to be made about the next steps.

[00:12:49] Secondly, a lot of organizations are now fully remote. The original design sprint was designed for an in-person setting, where the group spends time together in an enclosed space for the whole five days. However, with COVID there are now a lot of resources on how you could conduct a remote sprint. One thing is to utilize a virtual whiteboarding tool, such as Miro or Mural or even Figma, for the workshop. You need to limit each session to a maximum of two hours, due to limited attention spans in a remote setting versus an in-person setting. Another pro tip: to familiarize everyone with the virtual whiteboarding tool, especially if it's their first time, you might want to run a short orientation consisting of a game, to let them use the different tools on the board.

[00:13:52] The third challenge comes in huge organizations, where there are just too many candidates for a sprint. Unfortunately, the sad reality is that you need to be selective. Get recommendations for participants who are looking to proactively contribute and are invested in the outcomes for the problem space. If needed, you could also include some of these stakeholders as experts on the first day, during the expert interviews. That way they are still able to contribute fully to the design sprint. Lastly, because it's a huge organization, you want to have a socialization strategy to communicate outcomes to a wider audience.

Legacy organizations and physical products

[00:14:45] If you're in a legacy organization, chances are you'll be met with siloed ways of working as well as closed thinking. The way to go about it is probably to go with the grain and put up a proposal indicating the cost benefits of an initiative like this. Alternatively, you could start small and slow by adopting little sprint methods in your regular meetings, where decisions need to be made or where brainstorming sessions need to be held. The hope is that by introducing these small steps, your colleagues might see the gains in efficiency and might lower their barriers when it comes to adopting new processes.

[00:15:37] The last one is if the problem space is about a physical product or an experience. A design sprint can still be used, because a prototype can be digital, it can be an object, or it can be a prototype of a space too. If a pamphlet, brochure or pitch deck is one of the marketing channels through which people get to know about the product, you could also use that to test the concept of your idea.

[00:16:10] We've come to the end of this sharing, and I hope you've taken away the knowledge that the design sprint methodology is a time-boxed process that empowers cross-functional teams to solve problems effectively, and that each stage of the design sprint works cumulatively to build a common understanding. Lastly, I hope you also take away the fact that a design sprint is flexible enough to be adapted for organizations of all sorts and sizes. If you are inspired to take the next steps and start adopting this process, I found these resources really useful, and I hope you will too. That's it, and I'm happy to open the floor for any questions I can help answer.

Q&A

[00:17:06] Host: Thank you very much. I'm a big fan of design sprints, so I'm always happy to see other people picking them up and implementing them. Thank you for sharing.

[00:17:18] Elaine: I love them too.

[00:17:21] Host: Excellent. If anybody does have any questions, please put them into the chat box on UXDX or on any of the platforms you're watching, and I'll put those questions through to Elaine. To get started: one of the challenges I've always faced with design sprints, and you touched on it, was getting the time commitment from people, because it's very hard to get. One of the challenges I've had is that you get the initial commitment, but then when it comes to running the sprint, they're like, "Oh, I have to step out for this meeting I can't miss," or "I have to step out for this," so you get people dipping in and out throughout the day. Does that happen for you, and how do you try to solve that and avoid the disruption it could cause?

[00:18:10] Elaine: Absolutely right, you're spot on with this, because I've experienced it quite a bit during my experience running design sprints. It really depends. What happened once was that one of the stakeholders had to run out for a meeting, and that was for a few hours. In those cases it is still possible to bring them back by going one-on-one with them, just to let them know what has happened since then. There are also some situations where the stakeholder or participant has to go out for a prolonged period of time. In that case we usually have to tell them, "Sorry, but because this is a really intensive process and things move really fast, we won't be able to include you back," especially if they have missed the second day, because the second day is where your ideas come out, and for me, if you are not contributing, it's really difficult to bring you back in. But how about yourself?

[00:19:15] Host: I've only really worked in one organization that did them, and they would host them off-site. That was the solution. This was pre-COVID, when we were in the office. We found that if it was ever run on site, it was just too easy for people to step out, or somebody knocks on the door because some fire has started that needs to be addressed immediately. So the solution was to take people off-site, and I also found a secondary benefit: it gets people a bit more free-thinking when they're in a new space.

[00:19:59] Elaine: Definitely, I agree.

[00:20:00] Host: And what kind of frequency would you be running your design sprints at?

[00:20:07] Elaine: Usually what happens is that after the initial sprint you might have an iteration cycle, so that's where you would probably have a shorter sprint cycle. It depends on what the issue is. Maybe you didn't understand the problem enough, or maybe the prototype needs a bit of tweaking before it's tested again. So I would say in general the sprints get shorter and shorter, until everyone signs off and says, "We're ready to develop it," and then it goes into the proper product development process for us.

[00:20:44] Host: Okay, so you have a very clear "We've finished, we've signed off this prototype, now it moves over." It's a separation.

[00:20:53] Elaine: Yes, because this is for the concept validation, and once you're done with it, it should move on to the product development cycle. That's my experience.

[00:21:03] Host: And do you involve the people who will ultimately be building it in the development cycle? Are they involved at all in the sprints?

[00:21:15] Elaine: Usually what we do, if it's a digital product, is have a tech person, be it a developer or maybe... we try not to get the CTO, because usually the CTO is really busy, but if you can, then why not. The tech expert there is really responsible for ascertaining the feasibility of the idea itself. So we do include them, but other than that, it's only when we go into the product development cycle that we start to engage more of the development team.

[00:21:51] Host: Great. And can you share a little bit more, because you touched on it, about how some things don't need to go through a sprint? How do you balance the workload between "We've decided these things need to go through a sprint, these things don't," and how does that all funnel through and get prioritized when it gets to delivery?

[00:22:14] Elaine: I think the example I used was if the challenge or problem space is really visual design related, for example if you're looking at what the best layout for a certain website is. These are usually very niche areas where a multidisciplinary team does not provide much additional value, and therefore it shouldn't be a design sprint. In my experience, it usually works best when it is a bigger issue that impacts the organization's goals, because in that case people become more vested in it, and more vested in the outcomes as well. That's how you get people to come together to solve a problem.