Why We Need Design Thinking In Healthcare - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
Software // Enterprise Applications
Commentary
5/25/2015
12:06 PM
Connect Directly
Twitter
RSS
100%
0%

Why We Need Design Thinking In Healthcare

Designers begin by understanding how people work in the real world, and then create the best IT system that's technically feasible.

getting more people to understand what design is, and why it matters, is worth whatever insult to the profession I'm about to cause.

Design Isn't Just For Gurus

Design isn't some mystical skill that some people are born with. Unfortunately for a field dedicated to making things intuitive, the design world doesn't do much to dispel this notion. The profession is carved into dozens of subfields with acronyms (UI, UX, CE, etc.), each of which has considerable overlap. Fortunately, a quick peek behind the curtain reveals that the process of designing things is not nearly as ambiguous. Here are four concepts that offer a core to understanding design, and how it can be applied to today's healthcare reform:

Design is about understanding, not assuming. Smart people responsible for solving problems typically, and often without knowing it, skip ahead to what they would want in formulating a solution to a problem or product. Instead, good design is about first understanding users, uses, and environments, then doing research deep enough to break through stereotypes and assumptions. This sort of deep dive can lead to a dramatically different understanding and thus, different potential solutions.  

Here's an example of such learning. Academic medicine can be a real grind, and the prevailing assumption is that keeping doctors from feeling burned out requires better benefits that support work-life balance. In 2010, Stanford University hired strategy consulting firm Jump Associates to understand what was really going on with burnout, and what the university could do about it.

Jump shadowed and interviewed doctors and researchers from the time they woke up, through the workday, and until they and their families went to sleep. In one interview, a doctor in her eighth month of pregnancy told researchers that she was signing up for more on-call shifts than ever. While she wasn't required to do the extra work, she said she hoped it would give her a clear conscience when she took a few months off with her baby.

In this case, the real problem to solve isn't inadequate benefits. The stated benefits -- like the time off permitted after having a baby -- are great. But the guilt that doctors feel in actually taking that time off can be overwhelming. So the team focused on ways to redesign cultural and organizational systems, perk programs, and development initiatives in order to better support doctors. Had the team just focused on making better benefits, they would have completely overlooked the real problems and needed fixes.

Design is a process. The design process is a series of steps intended to:

  1. Solicit and understand the users' needs
  2. Identify and try technically feasible solutions

The approaches tend to include the following steps:

  1. Form the team
  2. Define the problem
  3. Define the users
  4. Develop and iteratively test the solution

Some designers might switch the order of my No. 2 and No. 3. Designers may differ over the choice of ethnographic studies, shadowing, interviewing, or embedding users on the design team in order to elicit user needs. There are also different approaches to testing proposed solutions. None of the designers I spoke with were dogmatic about these differences. They mostly emphasized that, as long as you end up at the destination, your preferred mode of transportation is less important.

To those familiar with software development, the role of the designer may sound similar to that of a business or systems analyst. I suspect that good analysts would find considerable overlap in some of the methods (e.g., storyboarding, interviews, rapid iteration, etc.) and philosophies (e.g., user-centered concepts) of designers. And just as designers would benefit from learning more about how healthcare works, analysts would benefit from expanding their understanding of design. Which leads to my next point.

Page 3: Use "design thinking" to solve problems

Leonard D'Avolio, PhD, is the Director of Informatics at Ariadne Labs, a joint venture of Brigham and Women's Hospital and the Harvard School of Public Health. He is co-creator of the healthcare prediction platform Cyft, an assistant professor at Harvard Medical School, and a ... View Full Bio
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Previous
2 of 3
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
PeterF028
100%
0%
PeterF028,
User Rank: Moderator
6/15/2015 | 10:35:12 AM
People need to appreciate the offering
Great article. Even the best innovations are meaningless if no one uses them. This is why its so important for organizations to involve a diverse mix of people when coming up with and pursuing new ideas.  It's really about having the culture in place capable of providing perspective. Peter Fretty, IDG blogger working on behalf of CSC. 
asksqn
50%
50%
asksqn,
User Rank: Ninja
5/30/2015 | 2:58:52 PM
Beam Me Up, Scotty: there is no intelligent life down here
Designing software around end user habits is one thing, but if the end user is a techno-moron -as most particularly in Healthcare are- well, there is no patch for human stupidity.  I expect even more patients to die from healthcare personnel errors the more tech is leaned on than the current bodycount from not being able to read a physician's handwriting.
GarrettG406
50%
50%
GarrettG406,
User Rank: Apprentice
5/28/2015 | 2:56:13 PM
Re: I live it first hand
     Cognitive Ergonomics is important here in designing informatin solutions that match well with the users' and their environment. For example, the bottlenecks in certain decision processes due to something like too many decisions at once or informatin overload can be relieved some by designing the information system to level out the mental workload. However this takes managerial understanding and a commitment to quality over some short-term cost. An information system that requires noted documentation to be entered before opening the next client case that occurs at the same time the provider should be interacting and counseling with the client is not a good solution from a cognitive ergonomics perspective. However, recognizing this bottleneck, using assistive technology in the documentatin process at this point would reduce the bandwidth and increase the effectiveness of the provider, to the benefit of the client and long-term cost and quality deliverables. In my projects I am committed to design technolgoy for the users and stakeholders not just the engineering viewpoint of accomplishing the list of functions to be included and completed.
PedroGonzales
50%
50%
PedroGonzales,
User Rank: Ninja
5/26/2015 | 9:42:09 PM
Re: I live it first hand
I think we often times forget that software is meant to improve users' process.  That the design of any product is the main way how users interact with our product.  If developers do not understand this then the faulty software will always be the norm. 
ldavolio
50%
50%
ldavolio,
User Rank: Apprentice
5/26/2015 | 7:09:20 PM
Re: great points
Thanks all commenters on your thoughtful feedback and follow on points.   Dr. Tsega, I read your blog post and i think you summarize nicely the ridiculousness of EMR design.  It's a really interesting topic that's lighting up the medical listservs and message boards these days.  Often overlooked is the government-funded oligarchy that created the rapid adoption of the decades old EMR design.  The unanwered question (in my opinion) is, "was it worth it?"  
ChrisBarnes
50%
50%
ChrisBarnes,
User Rank: Apprentice
5/26/2015 | 6:29:15 PM
Additional resources
For those who want to go beyond the resources mentioned, I also recommend the following:

GameStorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Gray, Brown,and Macanufo -- An excellent receipe book for helping groups of people explore ideas, problems, and solutions.  

This is Service Design Thinking by Stickdorn and Schneider -- This textbook explains design thinking in the context of creating/innovating services, describes practical techniques, and includes case studies. It's also beautifully designed.

Chapter 7: "Getting Personal: Developing Yourself as a Design Thinker" in The Design of Business by Roger Martin -- Many kernals of useful wisdom here, though a bit more "thinky" than practical.
progman2000
50%
50%
progman2000,
User Rank: Ninja
5/26/2015 | 3:27:48 PM
Re: I live it first hand
We've taken our developers onsite to hospitals and the result is always the same. After years of listening to developers explain how the user "should be" using the program, you can see that light come on and they finally "get it". There is no substitute for actually seeing and living what the users actually do.  
Stratustician
50%
50%
Stratustician,
User Rank: Ninja
5/26/2015 | 3:23:30 PM
Re: I live it first hand
Sadly, you aren't alone in this.  I think what a lot of software/application companies forget is that while they might think their solution checks off the key functionality, if it isn't developed with users in mind, it might not be as successful as they hope.  In healthcare for example, hiring developers who have industry experience, not just because they worked at a company that created solutions for healthcare, but who actually worked in hospitals and other healthcare providers and understand how the tools are used, might provide better user acceptance and usage overall than those solutions designed for these industries but not created with users in mind.
drtsega
50%
50%
drtsega,
User Rank: Apprentice
5/26/2015 | 12:51:02 PM
great points
Thanks for writing this and providing some helpful resources. I very much agreed with your point about the problem with bringing in designers at the end of a project (or thinking about design at the end, rather than the beginning).

I wrote something about this previously, and wouldn't mind getting your thoughts on it: https://medicalminimalist.wordpress.com/2015/03/18/diagnosis-clutter/
progman2000
50%
50%
progman2000,
User Rank: Ninja
5/26/2015 | 7:00:03 AM
I live it first hand
I work fof a software company that sells a healthcare product and have seen us make this mistake for years. Our product was developed by programmers that thought they understood what it was the user wanted. The sad part is we either lose deals because of this gap or well sell and implement a solution that forces a user to change their workflow based on our flawed assumptions. It's amazing how ofter that happens in the world of big ticket software purchases.
Slideshows
IT Careers: Top 10 US Cities for Tech Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  1/14/2020
Commentary
Predictions for Cloud Computing in 2020
James Kobielus, Research Director, Futurum,  1/9/2020
News
What's Next: AI and Data Trends for 2020 and Beyond
Jessica Davis, Senior Editor, Enterprise Apps,  12/30/2019
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
The Cloud Gets Ready for the 20's
This IT Trend Report explores how cloud computing is being shaped for the next phase in its maturation. It will help enterprise IT decision makers and business leaders understand some of the key trends reflected emerging cloud concepts and technologies, and in enterprise cloud usage patterns. Get it today!
Slideshows
Flash Poll