The story of modern medicine is the story of our human struggle with complexity. Technology will, without question, continually increase our ability to make diagnoses, to peer more deeply inside the body and the brain, to offer more treatments. It will help us document it all—but not necessarily to make sense of it all. Technology inevitably produces more noise and new uncertainties.

-Atul Gawande, MD from his article “Why Doctors Hate Their Computers”, The New Yorker, 2018 Why Doctors Hate Their Computers
Illustration of 3 people thinking

In fact, Gawande notes in his article that a 2016 study found that physicians spend approximately two hours doing computer work for every hour spent face-to-face with a patient. While Electronic Health Records (EHRs) are commonplace in today’s medical field as the healthcare industry advances and medical professionals are trained to use and comply with EHR software, the reality is that many continue to express ongoing frustrations with the technology. But why?

One Chief Clinical Officer, in response to clinicians’ frustrations, stated, “[W]e think of this as a system for us, and it’s not,” he said. “It’s for the patients.” I was struck speechless. Hold up! EHRs are and should be for use by and for the benefit of BOTH physicians and patients.

Aside from some electronic portals that allow patients to enter their personal and medical history, most EHR data and information come directly from clinicians and other providers caring for patients. Therefore, patients will realize the full benefit of the new EHRs only if they are intuitive and easy to use by clinicians — that is, only if clinicians can use them optimally.

Bang Head Here

However, this comment by the CCO caused me great consternation as it had, to my reading, undertones of scolded clinicians to “just buck up and quit complaining about how much you dislike using an EHR.” Instead, we must understand and promote design thinking methodologies to create better systems for all stakeholders.

One frustrated physician explained, “Ordering a mammogram used to be one click,” she said. “Now I spend three extra clicks to put in a diagnosis. When I do a Pap smear, I have eleven clicks. It’s ‘Oh, who did it?’ Why not, by default, think that I did it?” She was almost shouting now. “I’m the one putting the order in. Why is it asking me what date, if the patient is in the office today? When do you think this actually happened? It is incredible!”

Unfortunately, too often the methodology of design thinking is missing entirely. Instead, teams with no training or experience in Design Thinking develop systems using mostly traditional engineering approaches. Then, when users find these systems difficult and frustrating to use, the response tends to be:

Design Thinking is a Process

Design thinking is a process for creative problem-solving that puts people at the center of the design process through empathy. It is human-centered, collaborative, experimental, and optimistic. The process is not linear but usually follows these steps:

  • Empathize. Empathy in Design Thinking requires you to observe the people you are designing for, interact with them to understand their points of view and immerse yourself so that you can experience what they experience. It helps move teams away from self-referential thinking.
  • Define. As you define a problem in Design Thinking, you are looking for interesting and compelling insights about the people you are designing for and how they think about their work. This search provides focus and a framework for your problem-solving efforts. It allows you to be intentional in your designs.
  • Ideate. By building lots of design solutions, you allow for unexpected and radical solutions to design challenges. You also harness the collective perspectives and strengths of your design team.
  • Prototype. Prototyping is a way to test for functionality and permits further insight from the people you are designing for. Prototyping allows you to fail quickly and cheaply by piloting ideas before fully implementing them.
  • Usability Testing. By testing your ideas with actual people, you can both refine the concepts and learn more about the people—their needs and desires. Usability testing also allows you to examine whether your design solution is solving your original design problem or if you need to re-examine your prototypes.

In Closing

I think about Cooper’s first book, The Inmates are Running the Asylum, which should be required reading for everyone involved in creating these systems.

Cooper convincingly argues that designing interactive software-based systems is a specialty as demanding as constructing them. He forcefully and correctly asserts that bad design costs are incalculable, as they rob us of time, customer loyalty, competitive advantage, and opportunity.

Bottom line, it is long past time to stop blaming system users by labeling them “disgruntled” and “uncooperative,” loftily declaring that they “need to buck up and get with the program.”

Instead, we must get our collective act together and use design thinking methodologies to create solutions humans love to use.