Revitalizing Healthcare Tech | Responsive Web App
Revitalizing Healthcare Technology | A UX Case Study
In the same way that user research improves our experience of technology, clinical research improves our experience of our bodies, minds and hearts. This research occurs most often through patient clinical trials, where participants are recruited through their healthcare institutions. Recruitment is a key component in the advancement of medical knowledge; it is also a highly complex and constrained problem space.
The vortex of available patient data is, as of now, largely unstructured. Without much structure, the data lacks the meaning necessary to recruit the right patients for the right trials.
As a result, many teams and companies are working tirelessly to structure this data through the use of Natural Language Processing (NLP). I worked directly with an early-phase startup to aid in the design of their platform to do just that. The driving question for them, and for many of us who want to improve healthcare systems, was this:
As it currently stands, hospitals are given a six-month window to report patients to most federal and private registries; unfortunately, the backlog is accumulating daily, meaning that the bulk of reporting is done on the tail-end of the window. In turn, many clinical trials are cancelled due to the low volume of participants. What our team wondered was: what is slowing down the process?
Technology has certainly improved the gathering of patient data. These advancements are promising at an institutional level, giving hospital systems a way to push patient data into standardized technologies.
Unfortunately, there are not universally adopted standards; what’s more, most hospitals don’t allow other administrative systems to pull out data when needed. Though the goal of Electronic Health Records (EHR) is to improve communication, many clinicians report a reduction in EHR quality and a rise in administrative cost as a result.
But on a patient level, how are we affected?
Doctor visits, a once intimate and vulnerable point of human contact, have suffered in terms of experience quality. In order to be paid for their time, physicians put great effort into their electronic data, and as a result less into connecting with and understanding the suffering of their patients.
So if communication is suffering, the data is siloed and the patient feels unheard, is the data actually doing the most good?
So then, the true question becomes:
How can we reduce cost, improve the accuracy and speed of registry reporting; all while improving patient care?
My role in the product’s design was largely as a UX/UI consultant. I focused my efforts on strategy, user flows, information architecture, and best practices for modern healthcare interfaces.
The value of UX in technically intricate products is often overlooked, leading to daunting products that require users to be trained (via User Walk Throughs). My goal was to design a product that intelligent users could intuit (via Usability Tests), improving the workflow and efficiency of administrative staff.
Refining this complex experience could have a profoundly expansive effect: if registry reporting is faster and more accurate, then clinical research is expedited and advanced. If clinical research is expedited and advanced, then doctors can provide more impactful and nuanced care. If doctors can provide more impactful and nuanced care, then patients are supported and empowered by their providers.
For the purposes of this product, the creative brief served two functions:
To ensure that I understood as much of the technical and business requirements as necessary before beginning my designs.
To help the team articulate their goals and objectives more clearly
Throughout the conversations, I helped the team to define their key message:
For example, if the previous reporting time fell in the final moments of the hospital’s 6-month window, this technology can guarantee a near real-time reporting rate.
This means that by the time the patient exits the building, their records have been scanned and their Medical Record Numbers (MRN) submitted with unparalleled accuracy.
Other key takeaways from the Creative Brief included:
Each client will likely have different preferences in introducing new software/processes to their team.
Each client will likely use different data in training.
Each client will likely have different data structure preferences when building their EHR searches, meaning that their searches need to be highly flexible.
My first goal was to empathize with and understand the immediate users of the product. I aimed to define what we could rightfully know about the hospital’s administrative staff and registrars — to understand the basics of their daily goals and challenges.
Luckily, one of our team members had already conducted some initial interviews, providing the following as a jumping-off point.
Of our primary users, we determined they:
With a clear outline of the problem, I defined the three primary user journeys:
The Head of Administration (oversees operations, has most power and permissions)
The Triage User (creates “saved searches”/queries, delegates work to registrars, can reassign denied patients)
The Registrar (uses annotator tools to ensure accuracy of NLP predictions, confirms or denies patients to registries)
While it is likely that each client will have their own blend of these key roles, I wanted to ensure that all three routes had a clearly defined interface and flow. I mapped out the primary tasks as I understood them. This helped me communicate with the developer quickly and efficiently.
Ensuring mutual understanding, I chose to focus my efforts on the Triage User. Not only does this user have the potential to complete larger-level administrative tasks, they also have the potential to view the annotation tools of the registrar user. Their abilities would need to be the most flexible; thus, their interface would need to provide the most room for additional features.
From here, I created a more detailed version of the Triage User Journey, consulting my developer every step of the way.
With a thorough user journey in mind, I identified the two biggest interface challenges: Tables and Query Builders. The architecture and function of these two elements would make or break the experience of the product as a whole. I worked closely with the team, asking many questions along the way.
Whatever was uncertain, I documented for the founders to reference in their continuing customer research.
As I delved into my wireframes, I carefully considered the following questions:
What data is most relevant to the staff when searching for a patient?
Are queries directly related to the specific registries, or should they be able to be related to multiple registries?
In terms of result action items, does the user need single-select and multi-select? Where will that toolbar live?
When determining the hierarchy of Registries to Queries, we had to consider the administrator’s workflow, as well as the back-end’s functionality. As we all know,
This meant that within the product’s complex ecosystem, I pushed to consider all possible routes when determining the relationships between queries and registries.
Users will likely want to apply the same query to multiple registries. This could mean that queries are the top-level of navigation, with multiple registries within them. But what about the other queries related to the registry? We wouldn’t want the user to have to back out of a query and into another to run all the queries for a singular registry.
Alternatively, if the registries are top-level, then we would need to make copies of each query into the desired registry. From a UX perspective, this seems ideal.
But what if they want to edit the queries? On the back-end, it would be simpler to edit all query copies as opposed to a single copy. For the nuance of the administrator’s work, however, they will likely desire that fine-grain control. So do we afford the user the option to edit all and to edit one? And what happens if they edit one, then desire to edit them all — which edit overrides the other?
In the end, we decided that once a single copy is edited, it is permanently detached from the other copies. This does add a bit more cognitive load to the user to remember the architecture of their copies, but it also affords them the power they need to accurately perform their tasks.
Focusing the navigation
Throughout the information architecture process, I knew there would be at minimum three levels of navigation, each with their own series of actions;
I also knew that, because the interface needed to be scaleable, there would eventually be navigation associated with any given patient’s health records.
Keeping this in mind, I determined that the Query navigation would likely take precedence, as these queries would be the primary tool for discovering and assigning any patients.
Even though the individual registry is higher up the taxonomy, it acts more as a navigation ‘bucket’ than a dynamic navigation system. Thus, I decided to keep the most visible navigation constrained to the searches, and the registry and team navigation easily discoverable, but less in-focus.
In addition to the focus on top-navigation, I knew that the results pulled on the table needed to provide space for single-select and multi-select actions. I provided a multi-select affordance on each EHR result, while bucketing the single-select actions on the right side. This structure mirrors the top navigation architecture.
Query builders are traditionally developer-driven interfaces. They often default to exposing raw code to users in order to ensure accurate and distinct queries.
My biggest goal for the query builder was to empower the administrators with an interface that met their needs without increasing their cognitive load. To do so, I references traditional Information Architecture principles.
Based on previous market research, I knew that most query builders exposed all of their powers from the very beginning. I know that if the user had every possible option in front of them, it would slow the timing and potential accuracy of their work.
On my design, the interface expands per the user’s previous choice. For example, if the user selects “Demographic: Age,” the interface will then provide the option to select from a list of operators. Once selected, the interface will provide either one or two more fields to input age values.
Providing Meaningful Choices
In the same way that structuring data provides meaningful outcomes, structuring the available choices provides more meaningful decisions. In designing the input field for the query builder, my driving question was:
“How do I imply the power, without revealing the quantity?”
To do so, I also integrated the Principle of Multiple Classifications.
First, users have the option to either begin typing in the field, or select from a list of hierarchical terms. The specificity of these terms vary, giving the user the power to go as broad or deep as necessary.
By employing the above principles, I was able to design a complex and powerful query-builder that is sensitive to the screen real-estate and the user’s cognitive clarity.
(Dual-Screen Query Builder with Build, Test, View, and Add to Registry Functionality)
In finishing my consultations for the company, I completed the following list of deliverables:
- Creative Brief
- User Journeys
- Low-Fidelity Wireframes
- Two iterations of Low-Fidelity Prototypes
- High-Fidelity Propositions
I aimed to keep my contributions user-focused, business-driven, and development-sensitive.
I also drafted a list of questions to bring into client interviews that would help further define the product per the individual client’s needs:
In closing my work on any project, I find it necessary to conduct a “Personal Retrospective” on my contributions. For this work, my key takeaways largely derived from the early-stage nature of the company.
In start-up environments, it’s important to ask as many questions as possible, and be prepared for the answers to evolve.
Ask the same questions with different language.
Make no assumptions about a back-end, front-end, or business process.
Define your constraints and pain points early. Redefine them often.
Adaptive design processes provide better collaboration and results than rigid ones.