A colleague recently sent me an article by Atul Gawande, MD: “Why Doctors Hate Their Computers” (huh — you don’t say!).

If you’re familiar with Dr. Gawande’s work, you know that his articles and books are both thoughtful and thought-provoking (he’s a multi-award-winning author and a MacArthur Fellow for good reason). I read the article with interest, recognizing many of the frustrations with new Electronic Health Records (EHR’s) noted by the physicians he interviewed.

But then there was this pronouncement by one Chief Clinical Officer in response to clinicians’ frustrations: “[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 (which also means that hell may actually freeze over).

Hold up! EHR’s are and should be for use by, and the benefit of, BOTH physicians and patients.

And let’s be clear: there’s no “which came first” chicken|egg conundrum here. Aside from some electronic portals that allow patients to enter their personal and medical history, the majority of EHR data and information comes directly from clinicians and other providers caring for patients.

Therefore, patients will realize the full benefit of the new EHR’s only if they are intuitive and easy to use by clinicians — that is, only if clinicians are able to use them optimally.

Clearly, we need EHR’s for all of the reasons noted in Gawande’s article, and I fully understand the frustration the Chief Clinical Officer and others feel when they introduce new technology to a sometimes hostile audience. (I am after all a charter member of the “Innovators who are Deeply Maligned and Misunderstood” club.)

However, this particular comment by the CCO causes me great consternation and reinforces my conviction that Design Thinking methodologies are not well understood or being used to create better systems for ALL stakeholders.

Rather, and all too often, the methodology of Design Thinking is missing entirely. (Sadly, any reference to it is also missing from the Gawande piece.) 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 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. (Check out my post about personas and how they help us empathize here.)

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 the work they do. This search provides focus and a framework for your problem-solving efforts. It allows you to be intentional in your designs. (Check out my post about mental models here.)

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. (Check out my post about the power of sketching ideas here.)

A Prototype 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. (Check out my must-read recommendation, a piece by Alan Cooper on interactive interface design, here.)

Test. By testing your ideas with actual people, you can both refine the concepts and learn more about the people—their needs and desires. Testing also allows you to examine whether or not your design solution is solving your original design problem, or if you need to re-examine your prototypes. (I highly recommend Steve Krug’sbooks on usability testing.)

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 argues convincingly that designing interactive software-based systems is a specialty as demanding as the construction of them. He forcefully and correctly asserts (and his assertions are further borne out by Dr. Gawande’s article) that the cost of bad design is incalculable, as it robs 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 simply “need to get with the program.”

Instead, we must get our collective act together and use Design Thinking methodologies to create systems that humans love to use.