Designing A Successful 2 Hour Design Sprint

Teresa Cain at UXDX Community: USA East. Video: https://youtu.be/PHbinBZWXjc

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.

Introduction and why two-hour design sprints

[00:00:01] All right, welcome to Designing a Successful Two-Hour Design Sprint. Today we're going to talk a bit about some of the successes we've had at TreviPay with two-hour design sprints, but before we get started I wanted to talk a bit about my background.

[00:00:17] I'm Teresa Cain and I've been with TreviPay since 2018. I'm the Director of Product Management and UX Design. I've been in the product technology space for about 15 years, in both B2C and B2B products. I do a little startup advising on the side. I also volunteer for a women's non-profit organization called Central Exchange that focuses on professional opportunities for growing women in their career and personal lives. And in terms of this presentation, I have led, coached or participated in over 50 design sprints.

[00:00:53] So I wanted to start this presentation off with a quote that really resonates with me in terms of how we think about design sprints. "In a turbulent age, the only dependable advantage is a superior capacity for reinventing your business model before circumstances force you to." Why this is really critical is, as we think about the history of design sprints and where it came from in terms of design thinking, we've really iterated on this process and reinvented our business model during the pandemic, which forced our organization to be remote for the last two years. So as we go through this journey I wanted to talk a bit about how that business model impacted the process that we have done for design sprints.

[00:01:36] So why two-hour design sprints? What we've learned is two-hour design sprints create more opportunities for success by increasing the frequency and speed that we're able to deliver on problems or iterate on features as an organization.

Where design sprints came from

[00:01:52] For those that aren't familiar with the history of design thinking and design sprints, a design sprint is really derived from the design thinking methodology. You'll see here on the screen they each actually have five stages, and the key difference between these two concepts is really the amount of time that is dedicated to those stages. The design thinking process could take months to years, where you're focusing on a problem as an organization, really investing in a lot of deep research and time and problem solving.

[00:02:25] A traditional design sprint was invented by Jake Knapp and the Google team, which really put some time boxing around those design thinking methods and focused it in a five-day design sprint period where you understand, diverge, decide, prototype and test. What we've been able to do as an organization is we've really expanded the evolution of the design sprint in a time where we have been remote the last two years as an organization, really trying to problem solve.

[00:02:55] As you look here, design thinking really actually started much earlier than before Stanford's design school or IDEO popularized it in the 1980s and 90s. There are several books on design that came out in the 70s that really inspired that. And so as we look at this evolution, going from these books on design and moving into IDEO and Stanford's design school, moving into Jake Knapp and the Google team really being able to execute a five-day design sprint, releasing a book on it that many organizations have taken and used.

[00:03:31] So what we've really done is we've modified that, and we've taken a hybrid methodology where we've taken concepts from both design thinking and design sprints, and we've successfully been able to complete over 20 two-hour design sprints[?] in the last two years.

The successes we've seen

[00:03:49] So what's some of the success that we've seen from two-hour design sprints? The biggest value is we've been able to push high value features to our clients faster and cheaper. It's allowed us to conduct multiple design sprints in a month. Prior to utilizing two-hour design sprints we would only be able to get a handful of five-day design sprints in a year.

[00:04:10] We've been able to create more buy-in with internal stakeholders. Stakeholders weren't really excited about the fact that they couldn't get something we were working on for several months, sometimes three to six months after we would have that design sprint. So creating that buy-in, having them be involved in that two-hour design sprint, really connected them to the process and we got much more positivity afterwards.

[00:04:32] And then really building a hybrid methodology as a team has really allowed us to adapt that process across all of product, UX and design, and be able to replicate that process on multiple problems as an organization.

The challenges with five-day design sprints

[00:04:47] So this is what a traditional five-day design sprint schedule would look like for us before the pandemic, and while I don't expect you to read everything on the screen, what I do want you to take away from this visual is there is a lot of detail that goes into a five-day design sprint. Each day has its own focus, and sometimes you don't even finish all the steps in that day. So those are some of the items that really allowed us to understand that we were having a lot of challenges with five-day design sprints and we needed to modify what we were doing as an organization.

[00:05:23] Some of the challenges that we saw were, in addition to it being expensive and not as friendly for remote collaboration, it was really hard to get stakeholders in the room to commit to five full days. I know myself, I've been guilty of having to leave for a meeting during a five-day design sprint, maybe several meetings. But really taking that time to commit, sometimes even beyond an eight to five schedule, an eight to eight schedule, where you're focusing in on all of the steps that we just looked at, is very, very hard for some organizations.

[00:05:56] You also can see loss of productive time from the team. We definitely recommend including engineers in this process, or your architects and team leads, and when you do that you're actually taking away from the productivity in the sprint cycle, so you could see an impact in the upcoming sprints or releases just based on that. But you definitely need them in there as well to be able to provide feedback on the feasibility of what you're looking at to solve for that problem.

[00:06:23] We also found prototypes were not always ready for testing. There was actually one time where we were working on a prototype until the wee hours of the morning trying to get it ready for testing. Really you're trying to get that prototype in a state ready to get that feedback from the user, and sometimes you may want them to be able to click and test in that prototype, so this really became a challenge.

[00:06:50] We also had a challenge with users showing up. Sometimes they would not be able to make it last minute, or they would try to delegate it to another user, which can really complicate the process when you're trying to focus on a specific user to test that out. And then additional design sprints are sometimes needed, for five-day design sprints or two-hour design sprints, so you really are adding to the amount of time and investment that you're spending as an organization.

Condensing the sprint, and going remote

[00:07:17] So what we learned was really through trial and error. In terms of condensing a five-day design sprint, we actually did this before the COVID pandemic hit and we reduced design sprints to one to two days. We had a few three-day design sprints as well. Some of the things that we learned from that is we still had key stakeholder availability issues, and we still had issues scheduling users for testing, and also getting those prototypes ready to go. So we weren't really quite able to have the success and momentum we were wanting out of those.

[00:07:48] So fast forward to now, in a state where as an organization we have not gone back to the office and we are 100 percent remote. We have been utilizing video and collaborative technology to successfully implement two-hour design sprints. You'll notice here a little photo on the right, actually from a design sprint we just did a couple weeks ago. One of our designers, Colin Williamson, did a really great job running this.

[00:08:16] One of the key things about us as an organization is we don't just use two-hour design sprints to solve design problems, but we use them to really solve any complex problems we're having as an organization. This particular design sprint was on a problem around how we can become more efficient as an organization with SharePoint, a collaboration document repository that we're able to share documents in across different departments.

[00:08:46] One of the key things that you'll notice here is you see these little square boxes, and one of the efficiencies created out of these two-hour design sprints and using these collaborative tools is you no longer have Post-it notes. You look here to the left: when you're in a room you're trying to read the different Post-it notes, everyone's writing in their own handwriting, posting it up there, and if it falls to the ground you're never going to know where that went. Oftentimes you're not really absorbing all of the content right in front of you, you're having to walk around, you're probably not reading everything on those Post-it notes.

[00:09:24] So what's really great about these collaborative tools is it's all right in front of you on the screen, allowing everyone on the call to understand the problem and problem solve together as a stakeholder group. Stakeholders love this. We've had really great success getting multi-department stakeholders together for two-hour design sprints, and because of this we're able to run multiple design sprints in a month, and these are usually led by either our product team or our designers. So it's been a really, really great process.

When to use five days and when to use two hours

[00:09:55] So when should you use a five-day design sprint versus a two-hour design sprint? Five-day design sprints are really great to solve large problems. It allows you, maybe in a process where you have the flexibility, to schedule one to three months out. If you have a complex problem you're likely going to need many stakeholders in that group to be able to come together and talk about that problem, and this could mean from a schedule standpoint that it could be one to three months out, maybe even six months out. It becomes very challenging, and so if all stakeholders are not able to attend that five-day design sprint you may be missing out on opportunity for different ways to solve that problem. So that's something to keep in mind in terms of how you look at and use a five-day design sprint.

[00:10:39] When you should use a two-hour design sprint: this is really great for small to medium problems. And as I mentioned, we don't just use this for design challenges for our users, we use this for any complex problems we have as an organization. These are really great for when you need to schedule a design sprint within the next few weeks and you need participation from all stakeholders.

Our hybrid five-stage methodology

[00:11:03] So what have we done at TreviPay in terms of our hybrid methodology? We've really taken a lot of the standards that have come from Stanford's design school and Jake Knapp and Google's book on five-day design sprints, and we've conducted it to make our own five-stage methodology.

[00:11:20] As part of that process, during the two-hour design sprint we focus on three stages: empathizing with customers, exploring the problem, and ideating solutions. What we've done is we've taken those final four and five stages and we've moved them to after the two-hour design sprint, so we'll talk a bit about why we did that and why we're seeing success with that process.

[00:11:43] So this is what a typical two-hour design sprint schedule looks like for us. A pre-meeting checklist is always key. This just takes a few minutes, should already be items that you have, but we definitely just recommend that you have, whether you're in person or remote, make your meeting mandatory and always use video and audio recordings. This makes people more engaged, whether they're remote or in person.

[00:12:07] Make sure you send out a three to five slide PowerPoint summary of the opportunity, or just a summary statement of what you're going to be talking about as an organization. Make sure every stakeholder is thinking about the problem statement before they come in. There shouldn't be a question as to why a stakeholder is attending that design sprint. They should know exactly why they need to be thinking about that problem.

[00:12:28] And then we'll talk a bit more about collaborative tools here in a bit, but each stakeholder should have an account to whichever collaborative tool that you're using, and have a login to that and be ready to go to start the design sprint. So what we'll do is we'll walk through the different stages that we've created and talk a bit more about the time boxing within each of those.

Stage one: empathize with customers

[00:12:49] So the first stage that we really time box to about 30 minutes is empathize with customers. What's really great about empathy is it is not only the first stage in our hybrid methodology, but it also is very core to us as an organization. We use empathy in everything that we do in terms of how we work with clients and our users.

[00:13:11] What's really great about this stage is it allows you to review both the opportunity and the user personas. You'll see here a couple of user personas we have posted to the right. These are really the users that are going to be using the features that you will be releasing, or who will be in a situation with whatever you're going to work with as a problem as a group.

[00:13:35] So if you don't have user personas today, what you should really be thinking about are what problems are your customers encountering and how often. You really need to be defining what you do and don't know about the problem. This is very important and is also why you include multiple stakeholders in the design sprint. Any holes that you have in that problem should be answered by the stakeholders that come there, and if they're not, this is where you really find additional answers from the users that you will be testing with later.

[00:14:07] For those that haven't had the opportunity to execute user personas in your organization, user personas are a collaborative effort between product, UX and marketing to better understand your customers. We're very fortunate at TreviPay that we have a head of UX, John Kelly, that has driven this process for several years, and we have about 18 to 20 user personas that exist across all of our solutions at TreviPay.

[00:14:33] Really the key focus with the user persona is to understand who the user is that will be using your product, and the best way to do this is to interview your users directly for each user role. So we really recommend interviewing at least five to ten customers for each user role that you create. In addition to demographics you'll be creating a bit about their goals, understanding their pains, needs and solutions. What's really great about these user personas is these are not just used for design sprints. We actually take this into our agile cycle and we write our user stories and features around those users that will be using the features that we're developing.

Stage two: exploring the problem

[00:15:17] All right, so on to the next stage, exploring the problem. We usually time box about 40 minutes for exploration of the problem, and this is really where you finalize the problem statement as a group for the design sprint. So what's really key here is focusing in on one problem if you can, making sure that you're understanding the assumptions that you've now learned as a group from stakeholders.

[00:15:40] So again, going back to, instead of Post-it notes you're doing this in a collaborative tool, so these are your notes that everyone is able to absorb and add to together, and as they're adding they're also learning. What's even better with these collaborative tools is you're able to group all the ideas that are similar. That's what's really great about these design sprints. What you'll notice is you do have a lot of the same ideas across the team, and that's what really helps you come together to come up with the best solution for your problem statement.

[00:16:12] Another key item is you are not solutioning here, you're only refining the problem definition. But this is really what sets you up for success when you go to solution, which is the next stage that we're going to talk about.

Stage three: ideating solutions

[00:16:25] So this is actually my most favorite stage of all of the stages, well, one through three, or one through five. We dedicate about 50 minutes to this stage, and this is really where you brainstorm and discuss and vote on creative solutions as a team.

[00:16:41] What's really fantastic about this stage is it allows you to see how everyone thinks about solving problems. Some folks like to draw their ideas out on paper. I'm really big on paper myself. I like to solve a lot of problems in design sprints and out of design sprints by drawing just on paper at my desk. You have low fidelity sketching from some stakeholders, high fidelity sketches if you have designers join the design sprint, and then you're able to really vote on the solutions or sketches that speak to you as a group and decide which is really going to be the best solution to move forward.

[00:17:18] One thing to really remember here is every idea is an opportunity to problem solve. Don't let anyone hold back on trying to share their idea because they feel like they're not a designer. Any of the ideas that come out of this design sprint really do create opportunities to solve the problem that you're focusing on, or, what we'll talk a bit later about with the parking lot, take those ideas and talk about them at a later time.

Moving prototyping and testing to after the sprint

[00:17:47] So we moved stages four and five, prototyping and testing, to after the two-hour design sprint. So why did we do this? What we really saw, whether we were performing a five-day, three-day, two-day, one-day or two-hour design sprint, was that more design changes and testing are often still needed after any of these design sprints.

[00:18:08] From a prototyping challenge perspective, we saw there's just too much pressure that's put on the designers and team to get that prototype ready in time for testing. What this could mean is you're not really designing to the full extent that you need to get that correct user feedback, so that really created some challenges for us.

[00:18:27] And then oftentimes designers are staying up the entire night to prepare the prototype for feedback the next day. Actually there was a five-day design sprint I participated in several years ago where we were up till three in the morning finalizing prototypes for testing the next day, and to make it worse we had a few users back out on that testing. So you could see some of the challenges and the pressures that are put on a handful of people on the team instead of the entire stakeholder group, that make prototyping challenging when you time box it to a day or several hours.

[00:19:01] We also experienced the same with testing challenges as we talked about earlier, which is the prototype might not be ready, you might only be able to get a handful of users to show up, and if a user delegates from that organization to someone else you might not be testing the correct persona for that prototype that you're building. So we saw a lot of experiences with this, and that's what really made us move it to after the two-hour design sprint.

[00:19:28] Some of the benefits that we've seen, and how you'll execute the prototyping and testing after the design sprint, really comes down to what kind of design system you have in place as an organization. We're very fortunate as an organization to have a design system in place, as well as several screens that we're able to build features on top of, or be able to take previous screens and change a little bit. So this actually has allowed us to create high fidelity designs and build prototypes much quicker. I've dedicated one to two hours for each of these, which is usually what it takes, but sometimes this can be done in 15 minutes because we already have the core of the screens created.

[00:20:08] And then the testing stage is similar. It depends how robust of a prototype that you are testing with the users. So you can see here, this is just a simple screen that users are able to fill out in a few minutes, so you wouldn't really need to dedicate half an hour to one screen for five to seven users. But if you had multiple screens that you're wanting to get feedback on, this is where you really would want to dedicate half an hour for each user, and definitely recommend testing with at least five to seven users.

[00:20:41] But ultimately the biggest takeaway here is, no matter whether it's a two-hour design sprint or a five-day design sprint, additional design changes and testing are going to be needed outside of the process to be able to vote and move forward as a group on the best solution, and really the most exciting part, which is bringing that into your grooming and into your roadmap to release that to your users.

Setting up: collaborative whiteboarding tools

[00:21:06] All right, so now for the fun part. How do you set up a two-hour design sprint? So first and foremost, and what has made us most successful as an organization, is collaborative whiteboarding tools. We actually use two tools in-house depending on the preference of our team, so we use both InVision Freehand and Figma FigJam. Both of these have free accounts for three projects or less. Freehand has up to a hundred active collaborators and FigJam has unlimited collaborators. Where this is really important is you are going to have a lot of stakeholders that you're wanting to give feedback or participate in this design process, and this is where those collaborator accounts come into play, to log in and really give that feedback and engagement in those design sprints.

[00:21:57] So the next part, and again this is the fun part, setting up the virtual whiteboard. I remember a few years back before templates existed in tools, and we were trying to create our own virtual design sprint when the pandemic started, and it took several hours for me to create my first whiteboard on my own using one of these tools. What's really great is there are templates now. You can save a lot of time by using an existing template, and in fact there are two templates that are specifically for design sprints. Freehand has one called Design Sprint and FigJam has one called Async Design Sprint. While these do have modifications for multi-day design sprints, you're able to quickly trim down and narrow it to two hours. So this is really great and we've had a lot of success, and you'll see these same out-of-the-box card Post-it notes, virtual Post-it notes here, that we were seeing earlier with some of the design sprints that we talked about.

Creating the agenda and timing each stage

[00:22:58] So next step is creating your agenda. These are actually two agendas from design sprints we've run in the last couple of months at TreviPay, and you'll notice they're a little bit different. What's really great is, while we've recommended time boxing for each of those stages, depending on the problem that you're solving as an organization you've got a little wiggle room for how much time you want to spend, and that really varies on how much you understand about the problem that you are trying to solve.

[00:23:25] So first and foremost, review the agenda with the team at the start of the design sprint. Make sure everyone understands why they're there and already has that idea of the problem coming in, which helps make things go a little faster and more efficiently.

[00:23:39] We definitely recommend setting a timer for each stage in the process, and what's great is these tools offer timers to do that right there on the collaborative board, so you're able to see that timer countdown. It's a lot better for the whole team to be able to see, okay, I've got one minute left and I'd better hurry. What's really fun is as an organization, when we have these in person, we actually have the timer over there on my bookshelf. We have a timer that we would have the countdown in place as a team. So we've always recommended a timer regardless of whether you're virtual or remote.

The parking lot and recording the session

[00:24:15] So another key item is anything outside of the problem goes to the parking lot. Why this is so important is you are there for two hours to focus on a key problem you can solve as an organization, so anything that's not part of that problem solving needs to go to the parking lot.

[00:24:33] For those that aren't familiar with what a parking lot is, besides getting your groceries and heading to the parking lot to go into the store, a parking lot is really a technique to keep your design sprint on track so that you can really only focus on items that are in that design sprint. We like to joke a bit as a team, for those that haven't seen Disney's latest movie Encanto, that the things we don't talk about are parking lot items and Bruno. So there's a song, if you haven't seen that movie yet, that'll be stuck in your head for months, so I recommend it. It's a really great movie.

[00:25:07] The next key item is to make sure that you're recording your session. So whether you're remote or in person, having a recording of your session again allows engagement. Everyone realizes, okay, this is being recorded. It also allows you to have a reference item for when you go back to that recording. I mentioned earlier that we've recently been working on a SharePoint design sprint as a group, and that's really part of our reference point: we're going to be putting all of our design sprint recordings and designs into one place on that page. So whether you're including that in a document repository, or whether you're sending that out to others in the org that couldn't attend, or just a reference point, definitely record your session. We use Zoom or Teams for this, but there are several tools out there that you could use as an org if you didn't have either of those.

The attendee list

[00:25:58] So create a diverse attendee list. This is what a typical attendee list looks like for us as an organization. We definitely recommend not inviting more than 15 to 20 participants to the design sprint. If you have over 20 participants, that's really when you see stakeholder engagement start to decrease. So if you can keep it succinct with no more than 15 to 20, definitely recommend it.

[00:26:23] What we typically have here as an organization: our product managers and designers have been the moderators for all of the two-hour design sprints, so they're usually the moderator, and the product manager representing as the subject matter expert. You could have additional product owners or business analysts that join, designers, developer, architect. And then making sure that you have people that understand the users that you are solving for there is critical, so this is your customer experience, our support teams, account managers that work with the clients directly, marketing, or any other group at your organization that could add value to solve the problem that you're going to talk about as a group.

The design sprint team agreement

[00:27:09] So this is a really critical step that we feel is important: creating a design sprint team agreement. With this agreement you're agreeing that you are there for two hours as a team to focus on that problem, and you're not going to allow distractions to take you away from that two hours. So this includes silencing phones, and also attitudes, for two hours.

[00:27:31] So how you do that is make sure every attendee is logged into Figma or InVision, or whichever whiteboard tool that you plan to use for that design sprint. Remind the group of no emails, phones, surfing the web or leaving for meetings, minus emergencies of course.

[00:27:49] And then in terms of attitudes, just a reminder, design sprints are a safe place for idea sharing. Every idea is really an opportunity and should be celebrated as one, and if someone brings up an idea that isn't there to help solve that problem you're there to talk about, move it to the parking lot and solve it as a group later. But make sure that you're celebrating the wins of the ideas that people are sharing in that design sprint. That is really important for camaraderie, and also that team building that you're doing during that two-hour design sprint.

Wrapping up

[00:28:22] All right, so now you're ready to conduct your design sprint. You've got all the tools you need for a successful two-hour design sprint, so now you just need a problem that you need to solve as an organization. If you haven't conducted a design sprint before, whether it be a multi-hour or multi-day design sprint, a two-hour design sprint is a really great place to start. What's great about that is you can be the moderator or choose one from the team, you can set your agenda and stay on task, and you now have all the tools that you need to go execute on that in terms of collaboration, agenda, creating user personas and being able to understand the problem.

[00:29:00] Some of our success at TreviPay that we've really seen has allowed us to release features faster, conduct multiple design sprints in a month, create more buy-in with internal stakeholders, and overall build a hybrid methodology that worked for us. And if we recall the quote we talked about earlier in terms of reinventing your business model, we really feel that two-hour design sprints can help other organizations reinvent their business model as well, especially in unprecedented times where some offices are still staying remote and maybe not fully in person, maybe they have a hybrid remote and in person, or maybe some have gone back. But either way, this two-hour process allows you to be more efficient as an organization and reinvent your business model faster than you could have with five-day design sprints.

[00:29:54] I'd really like to thank the team at TreviPay for sharing all their latest experiences, and special thanks to John Kelly, our head of UX. If you have any questions on two-hour design sprints, feel free to find me on LinkedIn, the QR code is above, and I look forward to being able to share more information to my network on two-hour design sprints.