The UIE Podcast with Jared Spool

The Next Generation of Podcasts from UIE. Stay tuned for new stories and take-aways you can use in your day to day design work.

Episode #15 The Tension of Art and Science When Communicating Complex User Research

September 28, 2017  ·  23 minutes

Listen Now

Download the MP3

Art versus Science is the quintessential Left Brain/Right Brain cage match. But in reality, math factors into great works of art as much as developing a treatment plan for a patient could be considered the doctor's design.

Andrew Shipe is a developer at MEDITECH, a company that makes Health Records software. Through his research he found that medicine can sometimes be as much art as science, a fact that was getting lost in the cold, analytical research data. He discovered that telling stories helped to span that divide in understanding.

Kim Goodwin, Author of Designing for the Digital Age, joins us on this podcast to share her thoughts on Andrew's approach of using stories and how that is the first step down the road of scenario based research. Kim will also be teaching one of the full day workshops at UI22 this November 13-15 in Boston. For more information visit uiconf.com.

Full Transcript

Jared Spool: This is the UIE Podcast. I’m Jared Spool.

It’s unusual to think of the practice of medicine as an art form, but, when practiced, it is as much a science as art to diagnose and treat another living thing. When you think of the characteristics of both approaches, they might appear at opposite ends of a spectrum: one grounded in data and logic, and the other more humanistic, empathetic, and emotional. A friend may ask, “does your doctor have a good bedside manner?” What they mean is, is the physician personable and warm, instead of detached and cerebral?

We make the same assumptions about the expertise needed to build products. Engineers and engineering solutions are mathematical, governed by logic, while design is more aesthetic and responsive to human needs.

Of course, these assumptions are wrong. Dynamic problem solvers use analytical and creative methods. Science and art are intertwined, but in design we don’t always practice it that way, or even recognize it to be the case.

A recent study published in the Annals of Medicine found that physicians spend six hours (which, in the medical field, is typically half of their working day) documenting patient histories and treatment, ordering medication, and completing other required tasks within their Electronic Health Record Software (which they affectionately refer to as “EHR”). This burden takes a toll: less time with patients, longer days, weekend work, and more time navigating complicated interfaces that directly affect the health of patients. It leads to physician burnout. Some practices even hire scribes to assist in documenting patient histories. It turns out that a lot of EHR systems lack a bedside manner.

When faced with a complex problem, like making an effective EHR system, how do we, as designers, merge the humanity of art with the cold, hard logic of science?

Andrew Shipe: I think the stories have been effective because it's kind of a personality. There's a protagonist, there's some kind of conflict, which is usually our system, for better or worse, and I think we can be the heroes and we can make a better outcome for that story.

They take the complex medical decision-making and turn it into something we can all empathize with. We want to fix it, we want to make a happy ending to the story. I think that's been really motivating.

I am Andrew Shipe. I'm a software designer at MEDITECH.

Jared: Andrew’s company, MEDITECH, develops EHR software handling everything from booking appointments with physicians to documenting patient histories, treatment, ordering medication, and discharging patients.

Andrew: As a software designer at MEDITECH, we do a wider variety of things than the traditional software designer, all the way from the user research, research analysis, through the UI design, and even facilitating usability testing. We have a lot of incentive to streamline these processes as much as possible. How can we share the research we're gathering a little more efficiently with our stakeholders, and with the people we report to, the people we work with. How can we make it more clear, what we've learned, and get everyone on the same page about what the problem is.

The current software looks like it was made in the early 2000s. There's no consistency between another Windows or Mac or now iOS or Android application...It's kind of just overwhelming and disconnecting even right from there. It's very panel-navigation-focused, so our particular software is written in a bunch of proprietary languages, and so it doesn't hook into a Windows application framework or Mac or anything like that.

When our team of designers read articles and discuss them or read books about design, a lot of it's like, "Oh, but you can imagine yourself as the user," and for a lot of these situations, you really can't. You can't just jump into the mind of an oncologist and say, "Well, how are we going to treat your stage 3A lung cancer? Oh, we're going to use four cycles of carboplatin for 21 days, and we're going to throw dexamethasone in there if you have a reaction to whatever."

Without that domain knowledge, even if you're a really good developer or designer, you can't necessarily jump in and say, "Oh yeah, you just make it work this way or that way." I think in the same way, you couldn't empathize with, "Oh, we're doing e-commerce. We're going to have you check out your order." Everyone's done that before, and you can say, "Well, I can imagine me doing this or my mother doing this," like the personas and the user workflows and stories behind them become a lot more important.

Kim Goodwin: In any design process, well any effective design process, there's several different activities right? First you have to build a shared understanding of what is the problem you're trying to solve and whom. Then there's the phase where you're generating ideas about how you could solve it. Then you go through a process of analyzing and iterating those ideas to shape what you're actually going to build.

Research stories are a way to build shared understanding on the team, because in most organizations all the people who need to understand the users to drive the decision making, can't necessarily go along on every user interview with you. Stories are a great way to bring them up to speed and using a tool that has emotional impact to get them to understand at a more gut level what you're seeing.

I'm Kim Goodwin.

I'm teaching a workshop on using scenarios to solve problems at UI22 in November.

Jared: Because Andrew’s team had trouble empathizing with the habits and needs of oncologists through the cold hard scientific facts, Andrew turned to the art of creating research stories. He found these stories were surprisingly powerful at communicating what his team needed to hear. Through collecting these stories, he and his team were learning new things every day.

Andrew: We were researching how oncologists dose chemotherapy, and the drug manufacturer will say, "You'd get 50 milligrams of this med per square meter of your body surface area," which is also a thing I had to learn about. They can calculate that based on your height and weight and all these weird formulas. Then the doctor I'm talking with says, "I like round numbers so we just round it to 100." It's like, "What?" "Yeah, it looks nicer, so we round it up to 100. Or it could be down to 95, or down to 90. It's fine." I asked him, "Does that meaningfully affect their treatment?" He's like, "Not usually."

That was just really surprising, I guess, in that we think of medicine, or at least I thought of medicine as, "It's very precise, it's weight-based, it's body surface area dosed, great. We do the math, you give them exactly that much, and the cancer goes away," but there's this level of art when they're fine-tuning.

Once we got into how complicated the dosing the chemo meds was, we were telling these stories about, "Dr. So-and-So rounds to a nice round number, but his partner doesn't like to. Then at this other site in Canada, they have to report to their government body exactly how much medication they use and what patient it was for. They're much more exact with what they do." We talked with the pharmacist, and they're like, "These meds come in single use vial so you have to throw away the remainder, but these other meds come in reusable ones so you can keep using out of the same vial." Telling all these stories helped us converge on the theme that dosing is really complicated, and there's a couple of different factors that play into what they may or may not expect the system to do.

Jared: Andrew knew stories like these would be really powerful. But getting stories like these is not easy. To uncover this intricate level of detail for his team, Andrew had to employ a time tested research tool: The field interview. Other tools, like surveys and focus groups, just wouldn’t cut it.

Kim: I find that field interviews are by far the most valuable. I think that tools like surveys assume that you know what questions to ask. Whereas in field research you actually realize that you didn't know to ask about something and really unexpected things come up. If you just go in with the sense that I need to figure out how oncologists do their work, and they use information in doing their work. That's the research question that you go in with because you don't know what you're going to discover. Whereas if you say, "Which tool do you use more often", you might be glossing over, by far, the most important issue might be invisible to you.

Things like focus groups? You'll get a little bit better but they're not in the context of use and so you get a lot more self reporting error. You get a lot more loudest person in the room dominating the conversation. You can minimize that with good facilitation but you don't actually start to see the behavior patterns. You don't realize actually there are three kinds of oncologists. That gets lost in something like a focus group.

Because we're looking for the detailed flow, and structure, and mindset, and goals all those things that we need to design from, you're going get a lot more of those out of the one on one interviews. Preferably in the context of use.

Andrew: I was out in an oncology clinic for about a week in January of this year. That's far and away the best research. I got to see so much. Our main method though is just a Skype or WebEx or Zoom call. I have questions and sometimes we can have them share their screen if there's not a lot of patient information. Then they can actually show us what they do.

Just a lot of research questions, "Describe how you think about this, how do you choose what treatment the patient gets, how do you dose medications that are by body surface area versus weight versus kidney function?"

Oncologists that I've talked with are busier than even the other types of physicians I've met with before. A lot of our customers are in smaller towns, rural critical access, and they're maybe the only oncologists for 100 miles. That's actually one of the things we've been learning more and more with this kind of redevelopment project is, it's really hard to go from patient to patient, then you get a phone call in the middle of seeing all these patients. It's like, "Why are they nauseous? What's the deal? Are they on a new treatment?" A lot of that goes back to the physician's own documentation. They'll have their own unique styles about summarizing. It could be a paragraph summary that they write up every time they see the patient. It could be the three places in the system they always check, say, "What's the cancer diagnosis, what treatment are they on?"

Going deeper, there's another story where a nurse had accidentally discontinued the patient's oral chemo meds because they didn't know what they were. Like, "Oh, you're probably not on that." I told that to the team after that call, in the same kind of story."If they see these two meds, they're going to think one's a duplicate and they might discontinue it." We were starting from the user's perspective instead of how should it work, what should it do, what's good for the system, stuff like that.

Kim: I think the most important thing that Andrew and his team did was get out in the field themselves, and not rely on subject matter experts to be an interpretation layer between them and the users. I think that especially teams dealing with enterprise software, whether that's medical or accounting or whatever it is, there's an over reliance sometimes on subject matter experts. People who may be experienced users, who are part of the product management team or something, and treated as user representatives. You don't get enough diversity in that person's point of view, and sometimes their point of view is distorted because they've been too close to the product development over time. They're great resources, but teams that think those people speak for users tend to develop pretty incomplete understandings of the world. Watching people use the software. That's the foundation of great scenarios and great designs.

Jared: Andrew was talking to oncologists and their staff and collecting great stories about how they were practicing their medicine. His next big challenge? Get the team to understand the artful nature of oncology work. For this, Andrew started experimenting with the art of communicating research results.

Andrew: Every couple of weeks, we have a design critique with our stakeholders. We talk about the research we've done and how it's shaping what we're working on next. A couple of months ago. One of the designers I work with, he started making comics to describe his research findings. He works on health care, I guess, quality reporting. It can be really dry. "Dr. So-and-So met this measure for 90% of their patients, but this other doctor met it for 88%." It can be difficult to get people interested or excited about it. I'm like, "Oh, that's really cool. Let's try it out,"

We had a physician that we talked with. She took a day off of work, but to prepare for her day off of work, she had to order treatment for her patients that would be seen by one of her partners the next day. To do that, she spent three hours at night the day before her time off ordering all of this treatment for, it was 20 or 22 patients. I summarized that into the comic. That was more of a trial to see how it went.

It went well. It got them in the physician's mindset. It didn't really hit me until a week or so later that we're talking about this ordering process, and they referenced, "Dr. So-and-So is going to love this because it's faster for her." The light bulb went off that, if this is something they're engaging with and internalizing, this is a much more powerful tool than me sitting there and talking about what we heard.

Kim: I've never tried the comic book illustration of research stories. I find that photographs actually work really well in some circumstances, or video for research stories. I think that when you are envisioning the future in a scenario, sometimes a cartoon can work well. In a way, storyboards are exactly that. Rather than single static sketches, a storyboard walks you through what's happening in the screen state as the scenario progresses. It's really helpful to use those in conjunction, I always do that. Whether it sort of takes a step back and looks at humans moving through space and what the layout of the physical environment is and so on, depends on the design problem. If you're doing something that's more at the level of service design, then cartoons of humans interacting with people and spaces and so on makes a lot of sense. If all the action is happening on the screen, then a storyboard of screens makes more sense.

Jared: In addition to trying comics, Andrew also used other design tools, like user journey maps to visualize data and draw out the human elements of the nurses’ and physicians’ experiences when they interacted with MEDITECH’s EHR system.

Andrew: The story map has really helped be our architectural plan, and these specific stories have added some interesting color to it. When we get to a part on it, we can say, "This pain point is because it took her three hours to order these meds," or, "This suggested feature in phase three is because we don't want people getting treatment without doctors signing off on it." The nice part about the story map too has been, having that all compiled from all the stories is, even though we're doing a first slice where maybe there isn't a functionality yet, or it's a manual process, the team knows that. We're kind of testing and thinking about things with that longer term vision in mind. The story has value now in terms of, it might be frustrating now, but we know we're going to fix it later.

Jared: Andrew’s research stories and journey maps were taking on a bigger role. They were revealing unexpected user behavior patterns and upending the team’s assumptions about how oncologists approached the system. And in a moment of artistic inspiration, Andrew incorporated his research stories into the team’s journey maps. Now, the team could look holistically at the environment and problems within it.

Kim: It's a way to say here's what we're seeing across all the different research stories we heard. It's a way to make sure that you got all the data you need from research, so I actually use journey maps as an interview coaching tool sometimes. And it's a way to say what tools are people using, and what information are they gathering, what decisions are they making, and where are the pain points in all of this? So journey maps are kind of a research analysis and communication tool in my view.

What I encourage teams to do is to aggregate all their different research stories into a set of journey maps that describe the typical cases that they saw based on the usage pattern. If you have a set of personas that are distilled out of what you've observed, they each get journey maps that describe how they go about handling different situations, what tools they use, what information they exchange with the system. Those then become analytical tools.

Research stories are a way to help get at people's gut and help them see oh there's a problem there. Journey maps are a great analytical tool for making sure you really understand all the nooks and crannies of the problem, and that you understand it at a pattern level and not just an edge case.

Andrew: I think it's really empowered the team, that understanding the user is not just the designer's job. It's something everyone encounters everyday. As a programmer, you find all these edge cases, you find technical limitations we didn't think of initially, and they have just as good of a sense as I do about what an oncologist is expecting and general workflows. They're equally capable of making a decision, and certainly the team needs to be on board, but making those decisions and putting ourselves in the user's shoes isn't just the designer's job. It's everyone's job, something everyone's capable of.

Jared: These days, medical schools are incorporating into their training art studies to improve the observational skills of future doctors. The schools want remind these students of the human element. They’re trying to balance the critical importance of observing and interacting, against the cold, hard practice of analyzing and decision-making.

Andrew and his team at MEDITECH drew on user experience tools to understand the problem better, to humanize and communicate the research they uncovered, and to acquire an understanding of a user experience for which they had no firsthand knowledge. Their practice is both cold, hard analytical and warm-hearted human-centered.

It’s this balance between science and art, logic and creation, analysis and compassion. We embrace a deeper understanding of a problem, take ownership of challenges, and are empowered to identify the right solutions.

The job of the designer is not unlike that of the oncologist. It’s part science and it’s part art.

This UIE podcast is brought to you by the UI22 conference that’s happening November 13-15 in Boston, MA.

This year we’ve brought back Kim Goodwin’s full-day workshop, Using Scenarios To Solve Problems. Kim holds the record of being our most popular and highest rated workshop of any of our previous 21 UI conferences. That’s because she taps right into what designers require to get great designs out: a deep understanding of the users’ needs and contexts.

If you need your team to have a deep understanding of your users, you definitely want to check out her workshop’s full-day agenda. You can do that at UICONF.COM. That’s U I C O N F dot com. Get $200 off your full-conference registration with the promotion code KIMPODCAST17 (that’s K I M PODCAST 1 7).

Now, if you haven’t been to U I E dot F M lately, then you may have missed our recently revived podcast show, the U I E Book Corner. In this show, Adam Churchill and I talk about new user experience books that should be high on every designer’s reading list. Listen to the U I E Book Corner at U I E dot FM.

This UIE podcast was written by Kathleen Barrett and produced by Sean Carmichael. We'd like to give special thanks to Andrew Shipe and Kim Goodwin for appearing on this episode.

This podcast is part of the UIE Podcast Network. Thanks so much for listening and, as always, thanks for encouraging our behavior.