Designing for Emergencies - When product success is a matter of life and death

Grethe Thilly at UXDX Community: Rapid Discovery. Video: https://youtu.be/LbPjsYcdc1M

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.

A call from Dr. Nancy

[00:00:09] Grethe: Hey. I'm talking a little bit about our situations and what we're designing for. About three years ago, in the fall of 2020, I got a call from my dear friend Dr. Nancy Feltic [?]. We had grown up together, and she was an oncologist in a hospital in the greater Boston area. She called me, and that was not unusual, but she called me and she was really, really upset. Now, this is a woman who deals with young people and terminal cancer, so she's not easily shaken. She's not easily upset. But this day she was livid, and she was telling me why she was so upset.

[00:00:59] I don't know if you remember what was going on in the fall of 2020, but we had a massive influx of patients and crowded hospitals because of COVID and COVID-related symptoms. What had happened at the time was that so many patients were at the hospital that some patients were put in the hallways. That was just something they had to do, given so many people. Unfortunately, one of Dr. Nancy's patients, a young woman, was put in the hallway, and given her poor and weakened state from cancer treatments, she went into cardiac arrest with COVID symptoms and responses in her breathing.

[00:01:46] Luckily she was in a hospital, so everybody wanted to respond. Immediately the call went out: we have a situation here, come quickly. The emergency response team got pulled together, ready to focus on that patient. But what happened, and why they didn't get there on time, unfortunately, was a miscommunication. With so many hallways and so many different floors, the wrong location had been communicated to the team.

[00:02:23] This is what had really upset Nancy that day. She had lost her patient not because of care, not because of speed of response, but because of poor communication. "We can do better," she told me. And I believed her.

Joining Mobile Heartbeat and setting the goal

[00:02:46] We're dealing with a lot of really intense situations, and we really need to help make sure that these doctors and emergency response teams can focus on the work they need to do, and take the communication, trying to figure out how to get to the right person, out of their hands so they can do their work. After talking to Nancy, this really hit me hard, and I wanted to see if we could do something better.

[00:03:17] As providence would have it, I was invited to come and join the Mobile Heartbeat design team and lead their new product. This was really exciting. I joined on, having just dealt with Nancy, and was like, let's do something. I was really excited to get on board with Mobile Heartbeat, because they are enabling the current health system to communicate and collaborate more efficiently. We work on our mobile products to do that, and to be very patient-centric with our designs and our products. I was brought on to steer the new design of our newest product, Banyan. This was my chance to do better for Dr. Nancy and her patients, and really for all of us.

[00:04:10] I knew this was going to be a really tough sell. We're dealing with clinical communications; it has to be perfect. So the first step I took was to ensure that product was on board and product owners were involved from the very beginning. When I started, we got together and took a look at all the different use cases: what were the different clients talking about? We noticed that this emergency response workflow, and the updates needed to the current product, were requested across multiple clients.

[00:04:46] I also got to share Nancy's story and the situation we had found ourselves in, and other product people and stakeholders shared their stories as well. So we built a combined, collaborative vision of what we really wanted to fix, very early. We got it talking and got it formed. We got a goal. Our goal here, with my push-code-blue button, was how can we improve on this really simple design that was built around a very physical location?

[00:05:27] It had a very simple UI. You can't improve on a single button to press and get a response, but things have been changing. Hospitals are moving with lots of influx. So how could we improve on this? How can we keep it simple and improve it with this new, smarter technology? How can we turn this into a more advanced, flexible and smart easy button?

Going on site

[00:05:57] At this point, with that clear goal in mind, full team buy-in on it and alignment with the business, our approach was pure user-centered. We started early getting ourselves on site, figuring out what was happening with our end users in their environment. Luckily, partnering with HCA, Mobile Heartbeat got ourselves on site in clinical situations and environments. I would say this was soft-touch contextual inquiry while we were shadowing. We weren't in live emergency situations, but we got to ask our questions at a good time, as well as sit back and watch and shadow clinicians on the floor.

[00:06:53] We participated in new hire orientations and got all the same training that a lot of the new nurses and new doctors and other teams get. We also got to go and see different environments. We found ourselves in hospitals in large metropolises, large cities, but we also spent time at small clinics out in rural areas as well, trying to see what was common across them.

[00:07:26] After spending time in all these different environments and seeing these different stories, there were two real big consistencies that I wanted to bring up. Emergencies happened everywhere, not just in patients' rooms. Emergencies would be in large collaboration spaces. They could be in the hallways. They were at the Starbucks at the entryway. They happened everywhere. And even though these emergencies were consistently anywhere, we didn't always have the infrastructure to get that emergency call out. But everybody had mobile phones on hand. So we were like, hey, we can do something with this.

Design grounded in current patterns

[00:08:12] Next we moved into the design phase, where we really got to play. We took a look at some of these best-in-class communication patterns: what are the big apps doing, and how are they handling it? We built our early prototypes based on those. But we really had to take into mind what the vocabulary was, and how we could improve it for our clinical workflows as well. We grounded ourselves in current patterns first.

[00:08:47] I was also helping share our research with our team, always bringing it back so we could build buy-in, sharing our learnings with the full team, with our product managers, even with engineering. So it wasn't just the design team going off. We would do our research and bring it back, and that's a big theme: do your work, but always bring it back to the team.

Three rounds of validation

[00:09:12] Once we had a really good prototype together, a really good start at it, we moved into one of my favorite phases, the validation phase, where we really get to test it. Because we're dealing with applications that will be used in emergency situations, there's building up the trust. So first we did a lot of testing in-house with our own Mobile Heartbeat clinicians and subject matter experts, people who are the best in their fields and really know the hospital experience, who work for us now.

[00:09:54] That gave us a lot of good feedback on how we could improve these best-in-class patterns: modify things a little bit, remove some steps, or even expose more data to make better and faster decisions, especially when you're in a rush. This helped us get out a lot of our low-hanging fruit, designs that weren't going to work fast enough, that didn't take into account that you need to make decisions quickly. That really helped us in our first round, as well as building in-house buy-in on our designs.

[00:10:36] Next we got into our second round, testing with client subject matter experts. Going back to the clients now: it's very hard to get to end users, and they weren't ready for us to test with end users, but we got very close to the end users. The administrators, the client stakeholders, people who used to be administrative nurses and now lead tech departments, ensuring that the local technology at the hospitals is best for the clinicians and for the nurses and doctors.

[00:11:16] This really helped us fine-tune our designs and ensure that we were capturing not only the use cases we had thought of, but a lot of edge cases we hadn't thought of. At this point our prototype was getting a little tighter. We'd got better vocabulary, and we'd streamlined that navigation to be able to handle a response in emergency situations. And all this time we were building that buy-in with our own leadership, our own development teams, our own product owners, and then we started building it with the clients. They were excited about this. They saw something that worked.

[00:12:01] That was really the key to our third round, finally getting to test this with end users. We started with end users and we got back to end users in our validation. At this point we had a very advanced prototype, lots of use cases in it, lots of clickability. It looks and acts very real. We'd also been working with engineering along the way, where they'd got a proof of concept built. It's not all the bells and whistles in our prototype, but it's a really good base and it works.

[00:12:36] With this very advanced clickable prototype, as well as our proof of concept application, we were able to go back and test in clinical settings. Again, not emergency ones; nobody's using a prototype during an emergency situation. But we got it in their hands and saw them actually work with the application. At this point we really got to fine-tune our UI, keeping in mind where the thumb use is, and what data needs to be brought up and highlighted in actual decision-making scenarios.

[00:13:16] All of this sounds like a lot, but this project really only lasted about three months. At that point we had a very stable North Star design, the beginning of development on it, buy-in in-house, client support, and ultimately validation with end users.

The Banyan Reach designs

[00:13:44] I'm going to give you a little view into the actual product that we came up with, and this is called the Banyan Reach. This is where we started off, with some good patterns. How are we going to improve that emergency button on the wall? Well, we'll put it into the mobile. We'll give them these buttons again, and we'll give them a couple of options, more than just one. That's what we started with.

[00:14:12] But we learned early on that that wasn't enough. There wasn't enough context, and it wasn't matching the very specific world of clinical workers, which is very fluid. They can move to different departments. They can move to different facilities. They can change roles. It really depends on who they are that day, what hat they're wearing. So just having those buttons wasn't enough. We needed to provide more of that context, more of that fluidity to follow the user as they go through their different roles and different facilities in the day.

[00:14:51] Then we moved on to our second concept, a little smarter this time, with more context. Not only giving them some panic buttons or emergency response buttons, but telling them the other information and letting them know it's them, it's their stuff, so they can respond within the bigger application. Hey, this is great: not only can I send out an emergency notification, but I can be getting some as well. Providing that flexibility of following along: these are the emergency response codes when I'm at the Maxwell Hospital, but when I'm at a different hospital there'll be something else. And we can design a widget that can follow that user along in real-time location.

[00:15:49] Then finally we got down to one of the more final versions. We've got a lot of designers here; we know how final "final final" is. But this is one of the last versions we had before final branding, and this was really well received by our users and got into the hands of our clinicians on the floors, our end users. This was exactly what they were looking for at the time: something in their hand, something that knew where they were going and knew where they were, not sending the code blue to the wrong department because they're in the wrong facility.

[00:16:33] And it lets them know, hey, this is them, they're logged in, because there are a lot of shared devices among these resources. It brings it all together, so that they have that very smart emergency response button right in their hand. I was really pretty proud of this: an upgrade on the big red wall button that utilizes smart technology to get the right code to the right people for the fastest response.

Lessons for designing for emergencies

[00:17:16] That's a little of the journey: showing you the approach that we took and the designs that we came up with. And a little bit about what I would want to share after three months, if you're thinking about producing an interface that's going to be used in very intense emergency situations. I know this is true of design everywhere, but in situations like that you are going to get a lot of pushback at every step. Everyone's going to question your design decisions. So do the testing. Bring them along on the journey; don't go on it alone. Show why you're making these decisions. Any time you go out and talk to users, bring that back to your team. Include engineering. Let them know the why behind the design decisions.

[00:18:20] Another one: it's great to rely on those best-in-class expectations and common design UI patterns, and that's a great beginning. You can utilize a lot of it, but it is not going to work as-is in the clinical setting. These people know how to make phone calls. They know how to use directories. But their needs need to be more supported. They don't have as much time to think. So go ahead and begin with some common design patterns, but get out there and validate with real people.

[00:19:04] Then, automation is definitely the future: being able to do these tasks for our users, doing the heavy lifting of the thinking. They didn't want to have to know what hospital they're in; the app should know it. Take that out of their hands. These people are very focused on their patients, on saving lives, on responding to intense situations. They do not have time to fiddle around and do thinking on their mobile apps. It's not 15 minutes to figure out your own life insurance. This is, I've got five minutes to find where there's a surgeon on call right now. So anything you can do to make searching and finding easier, bringing things to light, is really what's going to support them, because they ultimately have to stay focused on that patient.

[00:20:06] To bring this story full circle, I definitely got to test with Dr. Nancy. She was a test subject throughout this project. One of the reasons why I'm feeling very secure about our product right now, the designs and what we're building and releasing, is that when I got it to her at our final stage, I heard: "In that situation I talked to you about last year, this application, this emergency Reach widget, would have saved a life. We really could have used it."

[00:20:50] Thank you very much for listening to my talk today about designing for emergencies. Any questions that I can address?

Q&A

[00:21:06] Host: Great. Thank you very much, Grethe. That was really interesting, to hear more tangible outcomes instead of social sharing or those kinds of things. I have a couple of questions, but if anybody has questions, please do post them on whichever platform you're watching this on. We're monitoring all the platforms. Two things in particular jumped into my mind around this product. The first is testing, because of something like location tracking. If it literally is life and death, how did you make sure that there were no bugs? All software has bugs. So how did you validate to make sure there were going to be no problems?

[00:21:53] Grethe: That was a huge technical feat, beyond just the UX department. Luckily, Mobile Heartbeat already had a history in that, being able to send broadcast notifications in a real-time fashion. So adding tracking to that location was really the next step for Mobile Heartbeat. It was a large effort, partnering with other technologies to do that. I'm not the best person to answer for that, but I can say it was a large undertaking for us, and part of what we want to do and provide at Mobile Heartbeat.

[00:22:44] Host: Brilliant. It's always nice to know there's somebody looking after that, at least. The second one: with a big red button, it's there, it's always going to be there. But phones have batteries, and batteries can die. I'm sure this came up. What was your approach for what happens if somebody's phone is dead?

[00:23:11] Grethe: That can always happen. But to say, hey, sometimes someone's phone isn't going to work, so we shouldn't build the widget at all, that wasn't something we considered. We still have these buttons on the wall. You can still get to them. You're still in clinical settings where more than one person is nearby. There's still a lot of shouting at times. Just because one person's phone is down didn't mean there isn't somebody within shouting distance whose phone could be working, or who is closer to the button. That's what came up in those situations. But to be honest, there are fewer of those "my battery is out" situations. We are exceedingly attached to our phones nowadays, too much to let it go down that far. So it wasn't a stopping point for us. I hope that answers your question.

[00:24:14] Host: Well, it's just me personally: my phone is over two years old now, and I think I need a new one because the battery is fading very quickly.

[00:24:26] Grethe: They also have a lot of shared devices in these settings. You pick it up when you come on shift, and you drop it off after shift, so they go back into the charging stations. With the bring-your-own-device users, we've got to rely on them. But the shared devices that were used by the heavy workers on shift were pretty well charged, because they had to be returned to and picked up from a charging station.

[00:24:56] Host: Great. And I guess it's one of those where it's very hard to get real data on the outcomes that have been achieved. I'm assuming it's more anecdotal. Do you have real data?

[00:25:09] Grethe: Well, this product is still in development, so we're excited to be releasing it soon, this year or early next year. So we only have the responses from our clients that have been testing with it right now. They really like it, and we're excited to get it out into the market. We have great loyalty to our brand already. This is providing clinical workers with getting to the right specialist quickly, being able to get a nurse in the room quickly, and providing all their directories. So they're very happy with it right now.

[00:26:01] Host: Brilliant. I think that pretty much brings us up to time. Thank you once again for sharing. It's a wonderful story. When people talk about the mission and the purpose of what they're working on, it's a good one when it's literally life and death and saving lives.

[00:26:20] Grethe: Test, test. It's what I'll always say. Thanks, everyone.

[00:26:25] Host: Thank you very much. Thanks for tuning in with us today. We genuinely hope that this video sparked some fresh insights and ignited inspiration for changing the ways that you work. But as with all things product development related, there is no one-size-fits-all, so please do share your thoughts in the comment section below and let's keep the conversation going. Finally, if this video resonated with you, please do us a favor and hit that like button and subscribe to our channel. This not only keeps you up to date with all of our latest content, but it also helps us with the YouTube algorithm. Last, if you want to keep learning, we have a couple of videos suggested here. But otherwise, until next time, take care and enjoy the rest of your day.