This sobering read exposes systemic issues in the design of healthcare technology. It shows why it’s become too common to produce software that meets certain functional requirements so we can “check the box,” but ignores usability and the clinician’s experience using that software.
My big takeaway is that it’s not enough for developers to produce a feature and show it’s working. Technology and product developers may have hidden behind “it works as designed” in the past. But as technology enters every stream of our existence, human interaction with it needs to be at the core of how it works.
Whether you’re doing work related to electronic health records, enabling someone to make a phone call in critical circumstances, or designing a juicer, “it works” is not enough! The standard must be, “it works intuitively, consistently, and in an efficient, safe, and reliable manner.” An oft-used expression at Vocera is, “make “technology invisible.”
Enabling technology to work this way is not so much about the features as it is about the experience. It’s critical for the people designing and building technology to be connected with the people who use it.
In-situ Observations: A User Centered Design Approach
At Vocera, we champion a design approach that starts with watching current and potential users performing tasks in their real-world environments. We draft problem statements and interview people to make sure we understand the problems we should be solving and why. We prototype possible solutions and share potential approaches with our user community. We incorporate user feedback throughout the engineering design and development process in an iterative manner.
This approach enables better technology and an improved experience for users. It also leads to some very innovative and non-traditional solutions.
A recent example was the way we designed a prioritized, unified Inbox in the Vocera Vina smartphone app. We took the time to observe how an overflowing, unmanaged inbox can fill up with unnecessary, outdated information and distract a user. This led us to break the traditional chronological or conversational paradigm for mobile communication.
Similarly, our innovative call-by-role or call-by-function paradigm was a result of observing nurses struggle to reach the right person while engaged in patient-care tasks. This oft-ignored approach has helped ensure we’re solving the critical problems in healthcare like reducing clinicians’ cognitive load.
Letting Users Guide Product Design
We use this human-centered design approach in developing our technology’s experience-related functions. Once again using Vina as the example, we started with the problem of physicians’ and nurses’ communication-related tasks.
Before writing any code, we spent more than six months watching and interviewing physicians and nurses and conducting small focus groups. We created three completely different design prototypes based on users’ input. We asked those who provided input to select the approach they liked best and moved forward with what they chose.
We refined the design elements iteratively and built a working prototype. Then we went back to several different user communities and asked them to use it and share feedback with us. This was all long before we finalized the design.
The User Community Knows What It Needs
The limiting factor in creating software using a human-centered design process is the availability of potential users to take part in such a design process. There is generally more demand to develop and release new functionality than there is availability of people to have the necessary conversations.
Clinicians lead busy lives. Some of them might say, “It’s not my job to tell you how to build your product, I’m here to care for patients.” Perhaps if we could forge closer relationships, together we might influence care team well-being and patient care for the better.
As the Fortune article about electronic health records makes clear, the process for determining how something should function and validating that it works for users is something that we, as an industry, find too easy to set aside because of the pressure to get things done. We can never lull ourselves into a false belief that we know what the user community needs.