Facilitating Design Sprints in Healthcare

The healthcare industry has some unique challenges. It’s highly regulated and people’s lives are on the line. This leads to a lot of risk averse business behavior––and rightly so in many cases. However, one challenge I frequently encountered working in the space is that we would usually only validate our product ideas if patient safety was at risk. I took it upon myself to champion the design sprint methodology to show we could work faster and reduce project risk.

Role

Over the past several years, I have served as lead design sprint facilitator, chief evangelist, and coach to fellow designers interested learning the methodology. Apart from just running sprints myself, I also gained experience pitching the methodology to project teams across the company to solve thorny design problems. In addition to personally teaching the methodology, I put together an internal training wiki to help scale our sprint capacity since 1-on-1 instruction is time-consuming. Cerner had no prior experience with design sprints; now we’ve run many and have multiple designers that are trained at facilitation.

Background

To back up, I read The Lean Startup shortly after it came out in 2011. This was when I was still learning the ropes of design. Reading that book coupled with my startup experiences significantly influenced how I view (most) products should be built—and how it affects the design process.

The tech world has mostly moved to an agile product philosophy to varying degrees. This agile-ish way of working was born out of the emerging tech industry and codified in Ries’s book. No longer would we spend an eternity designing and writing functional requirements. The age of just building something and observing how the market responded to it had arrived. This was an improvement over waterfall but brought its own issues.

Even with all the automation, fancy new tools, and APIs engineers have at their disposal, shipping code is still expensive. On top of that, in healthcare, regulatory requirements and market expectations generally mean that minimum viable products are closer to maximum viable products.

A solid, repeatable method to de-risk projects before any code ever got written was needed. Enter the design sprint. Jake Knapp’s famous book Sprint was released in 2016, and I was immediately hooked. It combined everything I liked about lean startup and human centered design.

So I did what any new design sprint enthusiast would do: I ran a design sprint with a project team. And it was bad. I mean real bad. I didn’t know the first thing about running one effectively. I clearly didn’t know enough. So I dove in head first determined to figure it out because I was convinced of its value. I read everything I could, and I eventually participated in the AJ&Smart sprint masterclass to learn directly from Jake himself.

That training was a game changer. It provided a lot of context around the process along with a lot of little tips and tricks. But most importantly, Jake was transparent about the fact that design sprints are hard and learning to be a good facilitator takes time. So I kept at it. And each time I ran a sprint, it got considerably better. Based on my experience running many design sprints in a challenging environment like healthcare, here’s an overview of what it takes to successfully advocate for and run quality sprints along with some of the successes we’ve had running sprints at Cerner.

Planning

The masterclass experience made me realize that the biggest reason behind our early failures boiled down to a significant lack of planning. The most important piece of wisdom I could offer pertaining to design sprints is that they take a huge amount of planning to be successful. Here are a few of those planning changes I made to our process that made a significant impact on our success. The process map below shows all the key planning stages and activities that need to occur.

Pre-Work

Design sprints don’t start on Monday of your sprint week.They start well ahead of that. Due to the nature of some of our solutions at Cerner (and probably any team that is dealing with highly complex products), we needed about 1 to 2 months of lead time before running a sprint. This extra time is largely due to the nature of highly specialized participant recruiting and scheduling.

To kick off a sprint, we would propose or a project team would propose a design sprint and then we have a quick meeting with some of the stakeholders to determine if a design sprint is necessary. If we decided to do the sprint, we would then log some JIRA subtasks to track the work. Next, we would have the team fill out a sprint brief.

Sprint Brief

The sprint brief makes the team think about a lot of necessary questions beforehand that helps out with planning. It also serves as a reference guide to ensure we stay on track throughout the sprint. Come sprint week, it’s dangerously easy to get off in tangent land and deviate from your original aim. Having this doc to refer back to can help keep everyone laser focused.

Once we have the brief filled out, we hold a kickoff meeting with all the important stakeholders. In this meeting, we determine who all needs to be present. We also bust out the calendars to discuss dates and book the sprint room. It’s really important to stay in the same location during your sprint week so all the whiteboarding and stickies can stay up on the wall.

Finally, we start to think about contingencies. What happens if one of these key people doesn’t show up? Someone MIA on particular days of the sprint can be extremely costly. Do we get a replacement or postpone? These questions need to be asked and answered by the collective group to prevent a major curveball during the sprint.

Recruiting

Next, we would meet with our design researchers to discuss usability test participant recruiting. Recruiting for enterprise design sprints can be way different than for a typical B2C startup. Some of our specialty solutions had only a handful of users in the entire world. Finding them and working around their extremely busy schedules to do usability testing isn’t as easy as posting on Craigslist.

For our clinical solutions – where nurses and doctors are the users, our design researchers generally needed at least one month prior to the sprint to adequately recruit test participants. Our consumer solutions were easier to recruit for but still needed at least 2 weeks notice to make sure we would have a full cohort to test with. It’s also worth trying to get a few more participants than you think you need…it’s inevitable that you’ll have some no shows in our experience.

Schedule

While participant recruiting is going on, the week before the sprint we would meet with everyone participating in the sprint. This meeting is critical and in it I would distribute and go over the detailed schedule. This lets people mentally prep for everything they’ll be doing. It also may be necessary to accommodate late or early lunches or meetings that more senior folk can’t get out of. It’s not ideal to rearrange schedules but it can be unavoidable with more executive level roles.

As you can see below, I block out time to the very minute. Time boxing the activities and staying on task is extremely important to get through everything.

Next, I would briefly outline some of the activities to set expectations that might be really unfamiliar to some participants. It’s very common that sprint participants have never done a design sprint before and certain participants usually need a lot of coaching on key activities like sketching and HMWs.

Following that, I go over ground rules for the sprint. Repeated expectation setting is required at several points in a sprint. Things like “shut your laptops at certain points”, “take phone calls outside”, “be present and keep your energy up”, etc. We also revisit our contingency scenarios and goals for the sprint to make sure everyone is still on the same page.

Finally, it’s important to discuss the potential sprint outcomes. There are typically three types of sprint outcomes: the epic win, the meh, and the epic fail. The epic win is when you knock it out of the park. Testing goes great, and it’s obvious you should build the thing. The epic fail is the opposite. Testing is horrible and all the participants hate it. The meh is harder. Testing results were mixed and there’s not a clear path forward. This means you need more research and design iterations. If the team isn’t prepared for one of these types of outcomes, they could be disappointed or worse if you don’t get the epic win. So prepare them for these scenarios.

Sprint Deck

It’s really important to have a solid slide presentation aid to help you facilitate. It helps show activity examples and is a helpful tool to remember all thing things you have to keep track of as facilitator. Here’s an example of the deck I use.

Sprint Kit

Having a good sprint supplies kit is a small thing that can be easily overlooked but is incredibly beneficial––especially if you have to walk all over a large corporate campus (are those even still a thing with COVID?).

When conducting an in-person sprint, I would generally try to have at least 2 big screen TVs or projectors. One to display the sprint deck and another to display participant screen sharing. For conducting virtual design sprints, this is all irrelevant and you should be working exclusively in Miro.

Usability Testing

Speaking of Miro, in my opinion, it’s absolutely the best way to take group notes during the usability testing portion of a sprint. It can be a challenge to get non-designers to use a tool like Miro, so in those cases, I will have participants write out physical sticky notes and add then to Miro later. Below is an example of how I have the group do Miro note taking.

Wrap Up

Once usability testing is complete, it’s important to very quickly meet with the team and discuss the results and agree on next steps. I started creating after action reports to save sprint contents for posterity and hold groups accountable. The most important things to include in these AARs include the key usability findings and what next steps the team will take. Here are some examples from a sprint around creating a health challenge feature within a wellness program.

Results

Of the many sprints I’ve run, I think the biggest impact I’ve had is showing project stakeholders outside of the design team that there are some radical new ways of working that are significantly faster and more impactful. I always solicit feedback from sprint participants on what worked and what didn’t to make improvements. I routinely would receive overwhelmingly positive feedback on their experience, however.

As far as bottom line impact, in several cases we have sped up design time considerably. In one example with an in-home care solution, we arrived at a prototype concept within a week that was originally planned to take several months. In another example, we decided to pause efforts on a project after realizing the vision way off the mark, which then got picked back up several quarters later when market conditions changed.

Success with design sprints can look pretty unique across different types of projects, but one thing is consistent: the team will feel more empowered about solving the problem.