Co-creating and Hacking Empathy

Design methods for rapidly prototyping complex health care software

Kwame Green
Clover Health

--

This blog post was originally a PechaKucha-style lightning talk (20 slides shown for just 20 seconds each) given at the 2018 Patient Experience: Empathy + Innovation Summit. The audience was mostly clinicians and others in the health care industry who were curious about using Design methods in their work.

When I think about “co-creating and hacking empathy,” I think about this article. (It’s a really good, long read. Worth your time, but not necessary as background for this post.) There’s a lot of promise in software, but we have to build it well. We need methods that help us create the best tools as fast as we can, so we can avoid harming people. Those of us who build software need to be as familiar with “first, do no harm” as we are with “move fast and break things.”

Clover Health is a Medicare Advantage insurance company and a health tech startup. Neither insurance nor tech are known for having a lot of empathy, but I promise you we do. I’ll show you a few Design methods we use to build quickly and incorporate empathy in order to avoid harming people.

Some of you may be wondering “What kind of impact can a Designer have on our health care system?” That’s because this image is typically what people think of when they hear “Designer,” but Designers don’t just make things look pretty!

Here’s the prettiest diagram I could find of the US health care system. But it’s still a complex, overwhelming mess. Most people don’t see this and instantly think “We need Designers!” If you only think about bringing Designers in at the end, this is what you get: a prettied up mess.

This book looks useful within health care, right? This is a
Design book! This is part of Design Thinking! Designers express things visually, but this — making sense of a mess — is what’s going on in our heads. We love simplicity, so we’re well suited to take complex concepts and systems, like health care, and make them as straightforward as possible.

Take Starbucks as an example. How they present themselves has gotten simpler and more human-friendly, even though the business has gotten more complex. The Starbucks mobile payment system has more users than either Apple’s or Google’s! You can’t do that without empathizing, and using Design to make things simple and orderly.

The output of Design is simple, but what goes into it is not, and at the foundation is “user needs” — or empathy. Starting here and building up is how Starbucks can get more complex, but still feel approachable. This is also a great place for Designers to start bonding and working with clinicians and others in health care.

We all care about patients. No one discipline knows enough to tidy up our messy health care system on their own, so everyone has to come to the table early in the process. We come together around needs, then we stay together to build multiple versions of something until we think it’s right.

We don’t hack, we hack together — which has two meanings. First: to build hastily, usually because it’s a temporary solution. Second: to build with others because they know something you don’t. You want speed and inclusiveness, so you can figure out which ideas fail before you spend lots of money or time on them.

Why? Because this is what happens when you don’t. A busy clinician was tasked with updating a prescription in a very non-human-friendly system. This was a data entry problem, which is hard to prototype and test, but incredibly important. So I’m sharing three methods we’ve used to hack together data entry.

Method one is really common: paper prototyping. First, draw a User Interface. I made this in software, but you don’t have to. Then, print it out, and cut out the individual parts. Don’t include the dashed lines, or you’ll make cutting everything out harder on yourself… :)

Now you have a kit of parts you can use to test your application. Making new parts is easy. But data entry is super easy; test participants just write! You can quickly create different user interfaces, but the key is setting up the kit to test lots of scenarios with multiple types of people. (Role playing and bodystorming are good alternatives to single-user usability testing for complex scenarios.) Including more people and scenarios generates more variety in your input, which helps find more edge cases. Uncovering edge cases enables you to plan for them, and that reduces the risk of harming people.

If you make the components really basic, it’s easy for anyone to contribute new ideas, too. You get speed and inclusivity. Just make sure your component sizes fit each other. The height and width need to be multiples of a base length, like lego blocks: 1 by 2; 2 by 2, 4 by 8, etc.

Method two is a little harder: spreadsheet software. Our Customer Service team is encouraged to help our members with anything that comes up. Phone calls don’t have a predictable path, so it’s hard to test different data entry workflows. We hacked together a version of our call logging software in Google Sheets.

With this, we can try different call scenarios with different people. It’s not as flexible as the real call log; each tab is a pre-determined combination of things. But you can hack this together in a day or two! And test participants can actually type and select options from menus.

The data they enter is stored the cells, so you can use formulas to reference data entered in other parts of the spreadsheet. It’s great for testing multi-step workflows where future steps depend on prior entries. Or for testing conditional workflows, like when you don’t know how many grievances a member has.

Method three is the hardest, and needs more background. Our Field Outreach team has a hard job. They have to find and engage the members who are hardest to reach. Then, over days or weeks, they have to keep track of each interaction as they try to build a relationship with the member.

To help the Field Outreach team enroll more members in our Complex Care Management program, we tried Google App Maker. You drag and drop pre-made components into your app, and do a little programming to customize them. We’ve been able to hack together a really high quality prototype.

Design and Field Outreach worked in one week sprints. Each week, they decided which outreach methods to try, and which features the app needed to support them. The next week, they iterated on both. The app and methods evolved together as they learned more. They went from nothing to fully working app in one month!

Remember: hack together. Eliminate bad ideas early so you can be clear, simple, and right. And, finally, Design Thinking alone isn’t enough. Hire trained Designers. If you’re not sure why, here’s an analogy: I know the principles behind giving an injection. I could give you that life-saving drug. But, do you really want me to? … or would you prefer a trained expert?

Interested in working to fix health care? Clover is hiring for clinical and non-clinical positions!

--

--