BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts The Two-hour Design Sprint

The Two-hour Design Sprint

In this podcast Shane Hastie, Lead Editor for Culture & Methods spoke to Teresa Cain about the Two-hour Design Sprint.

Key Takeaways

  • It is possible to get many of the outcomes of a design sprint in a short, highly focused two hour session
  • Design sprints are about bringing a group of stakeholders together to collaboratively solve a problem
  • Two-hour design sprints do not include the prototyping activity
  • Prework is vital for the facilitator to ensure they have a clear understanding of the problem to be solved
  • There are some common pitfalls which can be identified and avoided

Transcript

Shane Hastie: Hey, folks. Before we get into today's podcast, I wanted to share that InfoQ'S International Software Development Conference, QCon, will be back in San Francisco from October 2 to 6. QCon will share real world technical talks from innovative senior software development practitioners on applying emerging patterns and practices to address current challenges. Learn more at qconsf.com. We hope to see you there.

Good day, folks. This is Shane Hastie for the InfoQ Engineering Culture podcast. Today I'm sitting down with Teresa Cain. Teresa is the author of Solving Problems in 2 Hours, and she's the director of product management, user experience and design at TreviPay. Teresa, welcome. Thanks for taking the time to talk to us today.

Teresa Cain: Thanks for having me on the show, Shane.

Shane Hastie: My normal question to start with is who's Teresa?

Introductions [00:58]

Teresa Cain: I'm still learning that as I get older every day, Shane. But I'm Teresa Cain and I've been in the product and technology space for a little over 15 years across B2B and B2C SaaS solutions. And I'm very passionate about really helping organizations and teams find more efficient ways to solve small and complex problems, which is the premise of how the book came about.

Shane Hastie: I've heard it described as the two-hour design sprint. Many of our audience will recognize the design sprint as the five-day process. How do you compress that down to two hours and make it useful?

Reducing the design sprint from five days to two hours [01:34]

Teresa Cain: There's a lot that went into reducing it down from five days. And while most have probably participated in a five-day design sprint for those that haven't, there's a lot that goes into those five days, 40 hours and really getting stakeholders together.

And the biggest catalyst for this reduction was actually the COVID pandemic. A lot of offices shut down.  Having teams in Australia, the Netherlands, and in the United States, it was very challenging to be able to solve complex problems and be able to do that in five days when no one could travel.

And so, I ultimately created this concept that really took the best of both worlds from design thinking and design sprints and allows organizations to really use this model along with a collaborative template on Figma FigJam to be able to walk through the same problems in only two hours.

Shane Hastie: What does it feel like? I'm sitting here going, "Wow, that must be so intensive."

Teresa Cain: It's funny. I've worked with, at this point probably over 400 organizations on two hour design sprints outside of TreviPay. This is been going on for a couple of years now so I've had the opportunity to do this.

And some organizations that I'm coming in and talking to about the process, they're a little skeptical of it. There's no way this can be done in two hours. And so we'll take a problem and I'll run that problem with their organization. And there is a lot of surprise and dismay that we are coming to the end of that two hour designs sprint with the solution.

But it's not without active participation. I recommend not having more than 15 to 20 stakeholders. That really is a key differentiator and making sure that you have a focus problem. You have no more than 15 up to 20 stakeholders. And everyone is there for that two hours, whether virtual or in person, and is there to solve the problem that you're focused on as a stakeholder group.

Shane Hastie: Take me through the steps.  First I suppose, what type of problems would people bring to this?

This works for a wide variety of problem types [03:32]

Teresa Cain: It's actually been a variety. Most are familiar with this design sprint process solving product and technology problems. You're taking a feature from your backlog, maybe you're using Jira or another tool. And that's really the focus of that design sprint. Or maybe you are looking to build out a dashboard or go from a responsive webpage to a native mobile app.

Those are a lot of problems that I've run design sprints for this process over the years. And what's been really interesting with this two hour design sprint process that I've been running now for over three years, it's actually morphed outside of product challenges and into any organizational challenge. And so, one of the unique challenges that I most recently ran in the last couple weeks actually was an organization that was wanting to create a multi-year vision for their organization.

Really it was a group of stakeholders that was mainly executive stakeholders, being able to come together in a room and talk about the problem being we're not aligned on this three-year plan. Let's get alignment. And at the end of it, what the two-hour design sprint does is it allows stakeholders to really get that vision of how to really align in the importance of the two-hour design sprint.

If you think of the regular design sprint process, it's five days. You're understanding,, diverging, deciding prototyping and the testing. With the two-hour design sprint process, you're actually not doing the prototyping and testing. Really it's in three stages. You're empathizing with the customers, you are exploring the problem and you're ideating solutions.

And with that, you are sketching and coming up with a solution, but you're deciding as a group whether or not that is the right solution before you spend more time prototyping and testing. Which is really the biggest differentiator and the biggest buy-in of working with organizations as they like the time savings and the efficiencies out of that process.

Shane Hastie: If you did it twice on the same problem, would you get a different outcome?

Teresa Cain: Absolutely. And I've seen it happen. I've run a number of workshops and I will say yes and no. It depends on the stakeholder group. If you have the same problem in different stakeholder groups, absolutely, but even with the same stakeholder group, sometimes you get more ideas than what you've come up with before. And so, you're not going to have the same outcome. And that's regardless of whether you have a two-hour design sprint or a five-day design sprint. It really depends on the engagement level of the users.

But the best way to really prevent that from happening is to make sure you have a clear problem statement so that everyone in the room is understanding what you're trying to solve. For instance, ChatGPT is a super popular topic right now. And so I ran several workshops and I'll just say, "Hey, let's take ChatGPT, which everyone's familiar with, simple search box and talk about how we would go about improving the experience for ChatGPT."

And I'll run the same workshop across different groups and get three completely different recommendations of where we'll go. But they're all in the same family of a positive recommendation of how to improve the experience for ChatGPT, which some of the complaints that that's gotten is the data is only compiled to 2021. No one knows where the data is being stored.

Those are some of the solutions that the group is able to come up with. And all the great ideas that could solve the problem, but the ideas are solving it in different ways that might not have been thought of from the other two-hour design sprints.

Shane Hastie: Walk us through. What happens in two hours? And I suppose what happens before? Because I'm assuming somebody has to get things ready for the two-hour sprint.

The need for preparation [07:03]

Teresa Cain: Yep, great question. I have a template out on Figma FigJam, which is a collaborative whiteboard tool called Two Hour Design Sprints. Pretty simple. It's a free template out there if you go there. And ultimately, in addition to the book, I have this template out there paired with the book. And for those that use the Udemy course I have as well.

And really what I recommend is doing some pre-work. The pre-work is really going to allow you to understand who your problem is and who your target user persona is. Because oftentimes the key difference between a two hour and a five-day design sprint is you don't really have time to go solve for multiple personas. You need to focus in on the problem and focus in on the persona that you're trying to solve for.

In our conversation about ChatGPT, let's just say you have a user as a student versus someone that's working in the technology industry, your answer of problems is going to be different from plagiarism to copywriting on code depending on how it's being used. You need to make sure that you solve it on that user persona. That's the pre-work. And since it's a two-hour process and I have a template that's already available and ready, really they're just filling out the template, making sure the agenda looks good.

And then next, when they go to conduct that design sprint, they want to have already sent out and communicated to all stakeholders you need to be focused for two hours, you're in on this. And here's the problem that we're solving. Reach out with any questions beforehand type of mentality. So that everyone in the stakeholder group comes in there.

And once you start that two hour design sprint in the Figma FigJam template or there's lots of other collaborative tools out there, InVision, Miro, MURAL, you could just recreate that template. Really you are getting the whole group together. Oftentimes why I am seeing organizations need these two hour design sprints is because they don't have stakeholder buy-in. And the two-hour design sprints aren't so much about coming up with a solution as a group, as getting agreement and buy-in to move forward with the solution.

Bringing a large group of stakeholders together to collaboratively solve a problem [09:01]

A lot of the organizations I've worked with, including the many design sprints that we're running at TreviPay, are really meant to bring a large group of stakeholders together to move in the same direction on solving a problem. That's what these next three steps and phases do during the two-hour design sprint and they're time boxed.

You're agreeing on the problem statement, you're agreeing on who your target customer or persona is, and then you're starting the exploration stage of, well, what exactly is the problem? How do we really reframe what's going on? And then comes the solutioning stage, which that's actually the most exciting stage, and that's the stage where the entire design sprint starts to come together because everyone's able to visualize how they're thinking about solving the problem.

That could be a workflow, that could be a drawing, that could just be a simple whiteboard drawing as well, depending whether this is virtual or in person. And that exercise is almost like a two-hour team building exercise where you've gotten to hear what everyone's saying, you understand it, and everything's right in front of you on a virtual whiteboard. You're absorbing the information at a rapid, efficient pace and not walking around a room during a five-day design sprint.

And the beautiful outcome is, regardless of whether you need a more high fidelity design of what your solution is, you have agreement as a group on 80% of the time that this is the right solution. When you don't have agreement, then you go back and say, "We need to reframe the problem," and you run another two hour design sprint.

Shane Hastie: looking at that template, I see a lot of Post-it notes and some space for free form I suppose at the end.

Using collaborative tools [10:38]

Teresa Cain: Yes, It's almost replacing the physical Post-it notes, which I still use a lot at my desk. You have this concept of a virtual Post-it note that you're now able to use that. And the efficiency that's created is you're not walking around the room putting Post-it notes up on a wall and reading everyone's handwriting.

You have everything in front of you, you're encouraging everyone to participate and talk about what's going well, what's not going well, and really working on reframing the problem and solutioning together. That's part of the efficiency is making sure that users are using a template that will bring them forward to solving that solution.

Shane Hastie: How can it go wrong?

Teresa Cain: It can go wrong in a lot of ways.

Shane Hastie: Has it gone wrong?

Some potential pitfalls to avoid [11:19]

Teresa Cain: Yep. No, absolutely. And whether it's a five day or two hour, I've had both gone wrong, but I'll talk about the differences and when it goes wrong. When a five day design sprint goes wrong, actually one of the last five day design sprints I ran ended up needing to be three separate five day design sprints for the same problem. And what could go wrong there is that was a very expensive wrong, over $150,000 wrong.

When you have a go wrong situation in a two hour design sprint, you haven't spent near that amount of the time because most likely you're not using a third party to run this. You certainly can and there are third parties out there that will, but you're spending a lot less money and you're also spending a lot less time on the stakeholder group. That goes back to the efficiency of moving fast.

You're also able to schedule these quicker and have things go wrong a lot faster. Oftentimes when you're running these longer processes, you're scheduling it out several weeks, several months ahead of time. But let's talk about some failures a little deeper versus the comparison. One of the biggest ways for a two hour design sprint to go wrong is to have individuals, which I'll always say is usually executives, come in with very strong opinions and guided solutions before the team is able to solution together.

And when that happens, it's as simple as that executive trying to take over the moderator during the meeting. And again, that could be either a two hour or five day design sprint. And so, what's really critical is making sure every stakeholder regardless of a CEO or executive understands that this is a collaborative process. I've seen this happen many times. And ultimately what needs to be done and how I recommend avoiding this type of situation is making sure you sit down separately with your executives and you talk to them about the process and how their valuable opinion is there, but you need to get the group opinion for the solve.

And sometimes I like to capture some of the ideas and pre-fill the template out so they feel heard beforehand and during the meeting as well. But those are some of the biggest things that could go wrong. You could also have a stakeholder group that's not as engaged. Maybe they're not engaged in how you're leading it or they don't agree of working on that problem. Or you could have those just not paying attention or not attending the whole time or even the wrong stakeholder group. Maybe you don't have the right mix there.

That's really the purpose of the pre-work of making sure that you have everyone there that you need to, but there's going to be 20% of the time. And I would say 20% based on all the design sprints I've run over the years where design sprints aren't going to work for your organization and you're not going to come to a conclusion. And that could be whether it's a two hour or a five day design sprint.

Shane Hastie: What makes a great facilitator for a design sprint?

The facilitator needs to have subject matter expertise [14:00]

Teresa Cain: One of the key differentiators of the two hour design sprint process is you don't need a third party moderator to run it. My recommendation is that anyone that is the subject matter expert makes a great moderator because they're able to bring the group to the conclusion and understanding the subject matter and the problem that you're talking about and that you're trying to solve as a group.

And so, as part of that, and part of why I have this template created is to really help guide and remind those that are moderating. And one of the things that I've learned, so I have the book, I have a Udemy course. Oftentimes, why I even created the Udemy course was to show how to guide a little more through that process because not everyone wants to moderate and they don't know how to be a moderator.

That's why I ended up creating additional tools in addition to the book, because what's happened in the history of design sprints is a lot of organizations were having these run by third parties or specific groups like UX and design organizations. And now this has opened it up to be run by product managers, engineering leaders. I work with a lot of startups, so the entrepreneurs are running them as well.

With that, they're learning how to go run and participate in a design sprint in addition to moderating it. Being engaging, I would say, and setting expectations are probably the two number one things that are important. Making sure you have your agenda set, you're engaging the whole team and you're explaining that. And what's interesting is these two hour design sprints I've been running with TreviPay and other organizations, I said for over three years. And over the last year especially, I've started to work with organizations outside of product and technology.

And that's what's been really telling because those organizations have had no exposure to any design sprints whatsoever. This is a brand new process. And what they've come into it as is this is basically a two hour workshop, and I love that I'm able to get everyone together in two hours and come up with a solution. They're not so much as focused on I'm using a design sprint or design thinking technology. They're using the steps of the template to be able to guide the team in a decision from beginning to end. It's been an interesting journey.

Shane Hastie: Without breaking confidentiality, of course, what's your favorite experience from doing some of these?

Examples from Teresa’s experiences [16:18]

Teresa Cain: Yes, I probably can't go into complete specifics, but what's interesting is I have run the two-hour design sprints with startups that might not have a team of more than five. And then really large organizations, so like 10,000 plus. Obviously there's several in between and over that as well. But what I think is super interesting is I had different expectations going into the startup versus the large organization solve.

And so, what I love the most is working with a startup that is able to come up with a solve. I'll say one, there was a mobile app and ultimately there was a problem with location services, which everyone's familiar with that. But the ability to basically type in a search box, your zip code versus having it automatically track you. And the users did not want to be automatically tracked. They wanted to just type in the address instead.

And so, one of the problems that had come up during this design sprint was how do we solve the problem of getting users to use the search box when they don't want the location services? Ultimately, they just weren't using this part of the app at all. They were just avoiding the tab altogether.

And this was a native iOS app. And so, that was a really interesting one because it was very particular. You have a certain subset of users. And ultimately where we landed during the end of that two hour design sprint was something as simple as what the user was doing that prompted them to go into the app. And it actually ended up in an integration with another app to be able to have it prompt them within it.

But that's one of those focus problems where, when you come in as a group and you're solving that particular problem, the team was able to go right with that problem and figure out the solution next. The final solution that we had come up with, they took it right into the backlog and started working on it. That was one of my favorite ones because it was just so simple.

I've had really complex ones also where you're moving and migrating an entire website. And I will say those are a little too big for a two-hour design sprint. What I ended up doing there was breaking it into three, two hour design sprints. And that's something I've been doing more frequently for larger problems is creating a stacked process where you're solving it by persona instead of just trying to solve it all in one.

And that's worked out really well. But that's been another favorite one, figuring out the stages of a migration and whether or not users weren't happy with the website. Their response times were low. And ultimately, one of the solutions there was users basically want the website to load and they want to find exactly what they're looking for right when they get to the website. That was the emphasis on some of the screens that ended up coming out at the end of it. And then further having higher fidelity screens after.

Shane Hastie:  And that you broke up into multiple sessions for this.

Teresa Cain: Yes. And so, for that one in particular, there was different user roles for the website. There was a super admin user role, an executive user role, and then like a company type user role. And so, every single persona had a different expectation, but every single customer, our user was not happy with the load times of the website. And so, there ended up being a unified solve across everything of we've got to get these page load times up to make everyone happy, and that should really be the number one thing that's worked on next.

And then, the focus is having that user experience. And so, when you're deciding on whether to go build a brand new website with less functionality or slowly migrate features of a website in iframe, it becomes a very large decision and you have to piece it out by your highest priority users, which in this case was the super admin users. The decision for that one was to move forward with building the new website with the super admin and then slowly migrate the rest of the user rolls over for it.

Shane Hastie: Great examples. If people wanted to continue the conversation, where do they find the book? Where do they find you?

Teresa Cain: The book is on Amazon search for 2 hour design sprints. I also have a website called 2hourdesignsprints.com, as well as a Udemy course called 2 Hour Design Sprints as well. You can also find me on LinkedIn. I'm always happy to answer questions. I have people reach out every week asking me their thoughts on how to refine problem statements for their design sprint. I'm always happy to answer questions.

Shane Hastie: Teresa, thank you so much.

Teresa Cain: Thanks for having me, Shane.

Mentioned

About the Author

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT