Designing for Healthcare
Research, prototype, test, repeat
Designing for healthcare is hard. Meeting the needs of doctors, nurses, patients, and especially the tangled web of government and hospital regulations can be a daunting process.
These were the challenges I faced in my first job out of college. In 2015, I joined athenahealth as a Product Designer, and started work on what would become their electronic health records (EHR) product for hospitals.
For many years, athenahealth’s focus was on creating clinical documentation solutions for low-acuity settings, like outpatient clinics. As we expanded into larger and higher acuity spaces, like hospitals, we found that our product could not support the heightened complexity and increased frequency of documentation that hospital nurses required.
We needed a solution. So, for about six months, my team and I worked on creating a documentation interface specifically for hospital nurses. This interface would allow them to quickly document head-to-toe assessments of all patients in their care, and present the resulting data in a structured format that would help them track patient conditions over time.
Designing and implementing this interface required extensive research and multiple rounds of prototyping and user testing. Here’s how I did it.
Research
Conducting user research for medical software required meeting users where they were: in the hospital. I visited hospitals around the country — from Toledo, Ohio to Apalachicola, Florida — to learn as much as I could about how they operate. This sometimes required scrubbing in and following nurses around for multiple 8-hour shifts. These visits were a sobering reminder of many of the problems and inefficiencies in healthcare, and the magnitude of the work I had ahead of me.
I quickly learned that, in addition to delivering medical care, nurses are documentation workhorses; in many hospitals, they are the primary users of electronic health records. They document assessments of the patient’s body systems, vitals, intake & output, IVs, respiratory tubes, and wound drains; they provide their patients with educational materials, guide them through daily activities, and ensure a smooth transition between levels of care.
While most healthcare providers have implemented EHRs to support this documentation, very few are happy with their quality. 92% of nurses are dissatisfied with them, and they have even contributed to an increase in physician burnout.
This high dissatisfaction rate is due, in part, to these systems’ poor usability. Below is a screenshot of the EHR system used by one of the hospitals I visited.
Even for the computer-savvy, navigating EHRs like this can be very difficult, and many nurses will avoid using EHRs unless absolutely necessary. Some will fall back on a tried-and-true solution: an 8.5 x 11 sheet of paper.
It’s clear that these existing nursing documentation solutions are not working as well as they should. What would make them better? To find out, I conducted interviews and feedback sessions with nurses and patient safety experts. Arming them with fat pads of sticky notes and pens, I asked them to describe their ideal nursing documentation solution. What does it do? What features does it have? How could it help them deliver better care?
I then categorized this feedback into themes to help determine major areas of focus for the project.
I was also able to comb through data collected by legacy software to get some insight into the nurses’ current documentation patterns.
After visiting hospitals, researching other documentation solutions, and sorting through feedback from nurses and patient safety experts, I was ready to start prototyping.
Prototyping
Like most things in life, prototyping is almost always more fun in a group— and often more productive.
I helped conduct 3 design studios to get input from developers, product owners, nurses, and other stakeholders on our project. I’ve always found it very valuable to design with non-designers; they often approach problems in entirely new ways, outside the boundaries I sometimes put on myself.
We spent several days locked in a big meeting room well-stocked with office supplies and snacks, and began sketching out ideas for a brand new nursing documentation interface. When we were all out of ideas, we shared our sketches with each other, asked questions, and offered suggestions for improvement.
After a few iterations of this process, we had dozens of promising concepts — everyone had something of value to add. It was really interesting to see how each person’s background affected their design approach. Every time I participate in a design studio, I’m reminded that designers don’t have a monopoly on good design ideas.
One concept that was solidified early in the design studio was the display of assessment data. On paper and in almost every other EHR, nurses use spreadsheets to track patient data longitudinally. We all ultimately agreed that this structure would be the ideal format for our interface as well.
With a rough prototype for the data display finished, I needed to figure out the best way for nurses to quickly and easily document this data. In other words: how does the data get into the spreadsheet in the first place?
Other spreadsheet programs, like Google Sheets, Airtable, and most EHRs use direct manipulation to document and edit spreadsheet values. This input can work well under some circumstances, but the complexity of clinical data cannot usually fit in a simple dropdown, like the ones shown below. And even with simple data, jumping from cell to cell to input data can be clunky and time-consuming.
What if we separated the data input experience from the data viewing experience? Consider, below, a pop-up documentation form that appears on top of the spreadsheet. When signed, the form disappears, and the data is added to the spreadsheet.
In this rough mockup, the modal contains just a few checkboxes. But consider the other possibilities — it could contain an anatomical diagram to indicate pain location, or a view of the patient’s circulatory system that could be used to document the location of IVs. When the data input experience is given its own space in the interface like this, it has much more room to support more complex input mechanisms.
This basic structure seemed sound, but there was no way of knowing for sure unless it was tested. So, from these basic wireframes, I created several high-fidelity clickable prototypes using Sketch and Principle, taking care to make them look and function like real, working applications. Below is the first high-fidelity prototype I created for the pop-up input form. It definitely wasn’t perfect, but it was a good enough to test with users.
Throughout the research process, I discovered that using lorem ipsum or medically inaccurate content led to nurses and doctors criticizing the content, rather than giving me feedback on the interface. So, before I could start testing, I also needed to populate my prototypes with realistic clinical content.
Collaboration with clinicians
One of the most challenging parts of this project was grappling with the sheer volume and complexity of medical documentation. In a high-acuity clinical setting, nurses document hundreds of pieces of data per patient per day.
To find out what types of things needed to be documented, I consulted with medical compliance documents, a variety of paper nursing documentation, and hospital-specific guidelines. Fortunately, athenahealth employs a board of patient safety and medical subject matter experts that I could consult for this problem. Over many weeks, we worked together to create the full set of assessment templates that would be used in the product. These templates were created in a spreadsheet, like this one:
The data from these spreadsheets was later formatted for use in athenahealth’s back end. Retrospectively, this was an imperfect and unnecessarily laborious process. If I were to do this project again, I’d take the time to create an interface for the clinicians to supply us with this data more efficiently.
Testing
With the interactive prototypes finished and populated with accurate clinical data, I got back in touch with the hospital nurses I observed weeks before, and asked them for feedback on my prototypes. Surprisingly, most were eager to participate in the tests; they felt empowered being able to contribute to the design of a product they might one day use.
Through video conferencing and screen sharing, I had nurses document a simple neurological assessment by clicking through the prototypes. A moderator guide was used in all user testing sessions to ensure consistency, and to keep questions free from biased or leading language.
I conducted nearly a dozen of these user tests, and gathered hundreds of comments from nurses, which included some praise, plenty of criticism, and ideas for features I hadn’t even thought of.
Iteration
From this feedback, I had my work cut out for me. In addition to simple design tweaks (adjusting layout, sizing, typography, and color) there were many opportunities where the initial prototypes could be improved.
Here are some examples of fixes I made based on feedback received in user tests:
- Autofill known values, like the current date & time
- Include the most recent documented value for each question within the input form
- Add input fields that allow users to document custom values that aren’t included in the form (bonus: we could analyze text from these input fields to improve clinical content in future iterations)
- Add the ability to minimize the form so the user can navigate to other parts of the software if interrupted, and easily pick up where they left off
- Add the ability to “copy forward” the last assessment of the patient. If a patient’s condition doesn’t change much from shift to shift, this feature could significantly cut documentation time.
The finished product
After updating prototypes with these enhancements, there was only one thing left to do: build! My team was one of the first at athenahealth to use our new React design system for the front end of this project.
Since it was a common term in the industry, this feature quickly became known around the office as “Flowsheets.” Here’s an interactive prototype I built that shows how documenting a head-to-toe assessment works in athenahealth’s EHR.
An explanation of the video above: when it’s time to document (usually every four hours), the nurse clicks the “Add assessment” button, and a modal appears where all the documentation takes place. Navigation on the left side of this modal allows the user to jump between body systems quickly. The header shows what’s being documented, along with a date and time field, autofilled to the current time. To ensure that users always know the date/time of documentation and the body system they’re documenting, I chose to always show the date/time to the main header and make the section headers sticky. This leaves more room for the inputs as the user scrolls.
Each body system section includes a “copy forward” button that allows the nurse to simply copy everything that was documented during the last shift. On hover, the date, time, and name of last documenter appear so that the nurse knows exactly what is being copied forward. The nurse can also edit any value before signing the documentation, as some things are bound to have changed since the last shift. This feature was relatively easy to implement, and it absolutely delighted nurses.
As with any EHR feature, there were very strict guidelines about copying and pasting previous assessments that we made sure to follow, summarized below.
While most assessment inputs were simple checkboxes or radio buttons, sometimes it made sense to design a customized input interface to better fit what was being recorded. For example, the pupillary size options (2mm-8mm diameter) are accompanied by simple pupil icons. Also note that “Right” & “Left” are oriented opposite of what most users would expect, but this layout better fit the preference of the clinicians we tested.
Sometimes the structured data inputs weren’t enough to capture the nuances of every patient. So, we added a free-form note field for every question in the assessment.
Nurses often expressed the need to see the last documented value while they were assessing the patient. Why? Suppose, for example, the patient’s speech was garbled during the last assessment. If the nurse saw that information during the current assessment, he would be reminded to pay extra close attention to the patient’s speech. This initially presented a problem, since our assessment form design obscures all of the historical documentation for the patient. I came up with a simple solution: just show the last documented attribute within the form itself.
If a nurse wants to see more documentation history, he can minimize the assessment form, look at the Flowsheet, and go back to documenting.
When the nurse is finished, he signs the note. A subtle animation indicates where that data is documented in the Flowsheet.
Below is an example of how a patient’s vitals Flowsheet might look after a day of documentation.
Many nurses are starting to use tablets for clinical documentation, so I also started to explore how they might one day use Flowsheets to document on a tablet. Sadly, tablet support was deprioritized; I would have loved to design more of the tablet and mobile experience.
Specs
Of course, for the developers on my team to build all of the above, I needed to provide development specifications, which included typography, hex color codes, pixel measurements, animation timings, descriptions of corner case behavior, and more. I won’t bore you with every last detail, but to give you a sense of what this looked like, I’ve included two screens from the 40-page handoff doc I gave developers below.
Impact & lessons learned
After 6 months of work, my team finished building a new structured nursing documentation interface that allowed nurses to spend less time documenting and more time caring for their patients. Today, it’s one of the most essential parts of athenahealth’s hospital EHR product, and it has allowed athenahealth to expand upmarket to dozens of larger hospitals and health systems. Thousands of nurses across the country use Flowsheets; in the past year alone, they’ve recorded over a million patient assessments.
By working on this project from idea to implementation, I learned a great deal about healthcare, design, and product development, including how to:
- Run design studios that help non-designers feel included in the design process
- Work within the constraints of a limited design system and break out of these constraints when necessary
- Develop better protocols for keeping designers in sync with the rest of the team
This project was not without its challenges, of course. Our teams had to deal with company reorgs, feature reprioritization, and last-minute implementations of obscure EHR regulations. Overcoming these challenges wouldn’t have been possible without a group of talented people working together across teams and across disciplines, all dedicated to building something truly important.
Designing for healthcare is hard. But it’s worth it.
Thanks for reading! If you’d like to see what else I’m up to, get in touch or check out my website.
