From Sticky Notes to Survival Rates: What Design Thinking Actually Does in Healthcare

14 Aug From Sticky Notes to Survival Rates: What Design Thinking Actually Does in Healthcare

Posted at 14:21h in Uncategorized by Anne Reinke

Design Thinking shows up everywhere in healthcare innovation: workshops, empathy maps, sticky notes on every wall. But how much of that actually leads anywhere?

Embrace: the incubator that almost wasn’t

In the early 2000s, a group of Stanford students got a brief: build a cheaper incubator for premature babies in developing countries. They had funding, engineering talent and a clear problem to solve.

Then they did their fieldwork in Nepal and found something the brief hadn’t accounted for. Most premature babies never made it to a hospital with an incubator in the first place. The problem wasn’t the incubator. It was the journey to get there.

So they scrapped the original question. Instead of “how do we build a cheaper incubator,” they asked “how do we keep a baby warm on the way to care.” The result was Embrace, a low-cost infant warmer that has since reached hundreds of thousands of babies.

Key takeaway? The part of this story that actually mattered wasn’t the empathy interviews. It was the willingness to throw out a perfectly good brief once the research showed it was solving the wrong problem. That’s the uncomfortable step and it’s the one most teams skip.

What the critics get right

Design Thinking has no shortage of fans in healthcare, from Mayo Clinic to IDEO’s medical devices to hospital layouts that cut infection rates. What gets said less often is where the method actually has limitations. Four points are worth taking seriously.

It tests whether people like something, not whether it survives contact with the system.
A study on Design Thinking in intensive care units makes the point directly: the stakes of a failed design in healthcare are high enough that the method’s limits deserve as much attention as its promise. In practice, that means Design Thinking is good at answering “do people want this?” and has almost nothing to say about “will this get regulatory approval?” or “will anyone pay for it?” Those are the two questions that usually decide whether a healthcare startup survives.

“Learning from failure” can be a way of dodging the real question.
A well-known critique of the field points out that teams love talking about failing fast, but rarely ask afterward whether the system actually got better or whether patients ended up healthier. A prototype that tests well in a workshop is not the same thing as a better health outcome and treating “failure” as automatically instructive lets teams skip that harder check.

“The user” is rarely the person who needs the most help.
Design Thinking teams tend to interview whoever is easiest to reach, not the people who are hardest to reach and often need the most support. If your empathy research only includes people who show up, answer emails and speak the same language your team does, you’re systematically missing the people the work is supposed to serve most.

The risk is when the workshop becomes the finish line.
There’s a name for this: Innovation Theater. It describes teams that stop at the surface rituals of Design Thinking, sticky notes, a well-run workshop, good photos for the pitch deck, without letting any of it change a real decision. As one long-time practitioner puts it, people doing innovation theater use the workshop tools and nothing more, mistaking the workshop for the method itself. A well-run workshop is a genuinely useful start. The pitfall isn’t running one. It’s treating it as the finish line instead of the first step toward a decision or a test.

Key takeaway? None of this makes Design Thinking useless. It does one job well, which is finding the right question and understanding what users actually need. The mistake is treating it as a complete method for building a viable healthcare venture, when it’s really just the front end of one.

Eysz: what happens after the empathy phase

The gap Design Thinking leaves open, whether the product actually works for the people paying for it, whether it holds up outside a workshop, gets closed by testing, not by more empathy interviews. A good public example comes from Dr. Rachel Kuperman, a pediatric epileptologist who spent ten years directing the pediatric epilepsy program at UCSF Benioff Children’s Hospital before founding Eysz, a company using patient-generated data to improve epilepsy care.

Kuperman has written about applying Steve Blank’s lean startup principles to the process. Her team built a minimum viable product and tested it with hundreds of pediatricians and child neurologists to figure out exactly what data they needed and when. The first version of the product matched what doctors said they wanted: detailed, granular data. But once it was actually in front of them, the doctors said they didn’t need that much detail after all. Instead of treating that as a failure, the team used the feedback to rebuild. The result was a simpler smartphone app where patients record short selfie videos, giving doctors exactly the data they actually needed, not the data they’d said they wanted in an interview.

Key takeaway? The empathy interviews didn’t get this right on the first try and that’s normal. What made it work was building something real quickly, putting it in front of the actual people who’d use it and being willing to throw out a product that tested fine on paper. That loop, not the initial research, is what closed the gap between “clinicians said they wanted this” and “clinicians will actually use this.”

So, does it work for healthcare startups?

Not by itself. It has little to say about regulation, reimbursement or clinical safety, exactly the risks healthcare startups carry more of than almost anyone else. Used alone, it can produce a prototype everyone loves that never survives a regulator, a payer or a hospital’s procurement process.

Used as the front end of an ongoing testing habit, the way both Embrace and Eysz did it, it earns its place. It gets you to the right question before you spend real money answering the wrong one. That’s genuinely valuable. It’s just not the whole job.

Practical tips for applying it

Separate the three types of risk before you build anything. Desirability (do people want it), feasibility (can you build and deliver it, including regulatory constraints) and profitability (will someone pay for it) are different questions. Most healthcare startups over-invest in desirability, because it’s the most comfortable one to test and leave the other two until they’re expensive to fix.
Turn assumptions into statements you can actually prove wrong. “Clinicians will like our app” doesn’t tell you anything. “80% of the clinicians we interview say they’d use this weekly” does. Research on testing minimum viable products in healthcare makes the same point: assumptions should be made explicit, prioritized and tested empirically rather than left as background beliefs.
Test the riskiest assumption first, not the easiest one. Ask which belief would hurt the business most if it turned out to be wrong, and which one you currently have the least evidence for. That one goes first, even when it’s the uncomfortable one.
Reach for the cheap test before the expensive one. A landing page, a short interview, or a rough MVP can kill a bad idea for a fraction of the cost of a full build. Save the expensive tests, clinical pilots, full builds, for assumptions that already survived the cheap ones.
Don’t trust what people say over what they do. Eysz’s first version matched what doctors described in interviews, and still needed a rebuild once it was in their hands. Stated preference and revealed preference are different things. An MVP is what closes that gap.
After every workshop, ask what decision it actually changed. If the honest answer is “none,” it was probably Innovation Theater: activity that looks like progress without being backed by evidence.

The bottom line

Design Thinking didn’t build the Embrace incubator. Reframing the problem did. And it didn’t get Embrace or Eysz to where they are now on its own. Testing did. The framework is a strong place to start. It’s just not the whole method.

Further listening

“Healthcare Design: Evidence-based, Business Fluent, and Change Prepared” with Matt Van Der Tuyn (Penn Medicine), Design Thinking 101, episode 140 fluidhive.com/dt101-140