Q&A With Teresa Cain

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

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.

Breaking a problem down from five days to two hours

[00:00:00] Host: All right, thank you Jovi. Hi Teresa, we're going to start off with you. How are things?

[00:00:07] Teresa: Doing well, how are you?

[00:00:09] Host: Fantastic. I'm looking forward to this, I'm fascinated. For those of you who haven't had a chance to look at her talk yet, Teresa has spoken about designing a successful sprint in two hours, and I found it really, really interesting. The first question I have for you: cutting down from five days to two hours is the obvious one. You need to break it down and reduce the scope of the problem you need to solve. But who breaks it down? Who's the person in charge of breaking down a problem from five days to focusing for two hours?

[00:00:47] Teresa: That's a really fantastic question. Most of the time it's the product manager or the UX team that we've had a lot of success in doing that, and actually we have had the most success when the product and UX teams work together to break down that problem. For any design sprint that doesn't fit into that two hour model, what we'll do is a series of two hour design sprints, so maybe you have three two-hour design sprints, which effectively would still be less than the five day period. So really a collaborative effort, again, between product and UX.

[00:01:23] Host: Really great. And how do you tackle the big problems? You're looking at something over two hours which is solving a lot of smaller problems. Who and how do you tackle the big problems that arise?

[00:01:37] Teresa: Sure. We do additional design sprints outside of the two hour model, so we do recommend, for those larger problems, doing a longer length of time. We've had success with four hour design sprints doing large problems, but also one to three day design sprints. We still fundamentally, as an organization, feel the five-day model is a little too much time, even for some of the large problems, from a stakeholder involvement point of view.

Stakeholder involvement and the 50-minute ideation

[00:02:06] Host: And on stakeholders, if you're running them more frequently, how do you schedule them so as not to overload stakeholders?

[00:02:14] Teresa: That's a really fantastic question. We're really fortunate to have a lot of stakeholder input. Over the last year and a half we've run a little over 25 two to four hour design sprints. By creating that less time for the design sprint we have really allowed the stakeholder input and participation to go up. When we would do three or five day design sprints, we were not able to get stakeholders to stay that entire time, or even show up at all. So this has really dramatically changed that engagement level, as not only are they participating but they're able to see those sketches coming out of it and be a part of it, so they get more excited about that buy-in and that future release.

[00:03:00] Host: I really like that. I have a question here already from Scott: in the 50-minute ideation, how much time do you set aside for presentation versus discussion?

[00:03:13] Teresa: Sure, that's a really fantastic one. I only set aside usually about the last 15 minutes for presentation. I usually give each stakeholder around a minute and a half to present their idea to the group. For anyone that's had to do any pitching to your executive teams, or getting buy-in on a new product or solution, they really have that minute to a minute and a half to sell the why behind their solution, on why it should be moved forward.

[00:03:39] Then the rest of that time is really on the ideation focus, that sketching across the different stakeholders, so that every single participant in that two hour design sprint is able to ideate and come up with that visual design or written workflow to be able to present to the group. And then obviously there's a little time for voting after that, and usually what we find is there's a handful of solutions that you're narrowing in on, that you're kind of marrying together, that become the successful solution.

Are the outcomes better than a longer sprint?

[00:04:12] Host: I really like that, it feels very collaborative. Often, if you're doing these shorter sprints in two hours, is the outcome often better than you would get for a larger one?

[00:04:26] Teresa: Actually yes, for us as an organization it has been more successful. In my career I've run or participated in a little over 50 design sprints, and half of the five-day design sprints, we ended up throwing out the idea. The reason is, design sprints are not necessarily meant to take that idea and run with it into implementation. It's meant to really understand and problem solve and really make a decision on whether it is really the best solution to bring to your users. So sometimes what that means is you might get feedback from your users that's negative and you're not going to be taking that into the release cycle. A majority, I would say over 80 percent, of the design sprints that we've performed in the past year and a half, which again was over 25 two-hour ones, have all gone into live releases already.

[00:05:22] Host: Those are phenomenal stats. Jake Knapp needs to be messaged so we can write another book. I have an audience question here: can you share some examples of the types of problems that you would tackle in a two-hour design sprint? Great question.

What kinds of problems fit a two-hour sprint

[00:05:39] Teresa: Absolutely, that's a fantastic question. I've done a number of different problems. I talked about in the presentation small and medium problems, so what does that mean? What's really great for this, for anyone that's building like a dashboard concept or mobile app, or they have a handful of one to maybe a max of 10 screens that you're building out for that concept in terms of testing, these design sprints are really successful. With these problems that you're trying to solve, problems that really do have a visual design focus, you could go into with a web page or a mobile app, do really well with these.

[00:06:21] But I will say we actually don't just use this for our product and technology organization, we use it to solve company problems as well. We were actually just looking at redesigning our SharePoint site as a product and technology organization, so we decided to take it to a two hour design sprint and pulled in stakeholders from all departments, and we came out of that two hour design sprint process with a brand new web design and solution that we're moving forward with. That's what's really versatile about the two-hour design sprint: the commitment is so little that a lot of people go in wondering whether there will be an outcome, and as mentioned, with ours, 80 percent have had a really positive outcome, and that's what allowed us to really tackle a number of complex problems in addition to screens.

Challenges along the way, and running sprints remotely

[00:07:10] Host: I really love that. You talked about some of the problems it solved. What are some of the challenges that you encountered along the way in doing this, and how did you overcome them?

[00:07:24] Teresa: Yeah, absolutely. Obviously during COVID this is all done by trial and error. Once our offices shut down in March of 2020, which is crazy to say, we're actually still, we still haven't moved into our office yet, so I'm in home ops[?]. When we had first shut down, I actually had a design sprint I was going to be conducting for one or two days in the office that was around a predictive modeling analytics dashboard, and I really pushed it off every couple of weeks wondering, okay, maybe I'll just do it the following week.

[00:08:02] What I ended up doing was just throwing together a three-hour design sprint. At the time I was using InVision Freehand and there weren't even any templates available at the time, and so it was really through trial and error that I just tried to create something virtual. There wasn't really anything I could find online on how to successfully do this virtually, so I just created it for the most part.

[00:08:25] What I learned, I look back at that original collaborative tool design sprint, that very first one, compared to the ones we have now, and it's a hot mess. It's like a messy whiteboard of post-it notes, virtual post-it notes all over it. So really what I've learned over time is how do we become more efficient using those collaborative tools, and that's not really just with the design of the design sprint but also stakeholder interaction. When we started out as an organization we were actually doing three to four hour design sprints, and we've become so efficient that two hour design sprints are the new norm for us.

[00:09:03] Host: Wow, that's unbelievable. Just talking about remote sprints as well, that's a challenge in itself. Is it harder or easier to get people involved?

[00:09:14] Teresa: Actually, I think a little better. With the in-person design sprints, everyone has priorities with their roles, and so you would ask everyone coming into the room to leave their laptop, but there's always going to be distractions. You've got devices nearby, I took my watch off for today, but you've got all kinds of devices and technology and distractions around us. What's really great is everyone that we have going into these two hour design sprints, we have them agreeing to what we call a design sprint agreement. So you're agreeing to no distractions, full dedication and focus for that two hours, and we've had a lot of success. That means your video camera is on, you're inside the collaborative tool, and you're working and committed to those two hours to make sure you have that positive outcome.

[00:10:04] Host: Brilliant. Teresa, that's absolutely amazing, thank you so much.