The Mental Model and Information Architecture

Company: Eon

Product: Eon Direct

Role: Lead Product Designer

Tools: Figma, Pendo, Font Awesome

Work Preview

Company Overview

Eon is a market leader in the identification and tracking of potentially malignant incidental findings.

Product Overview

Eon's proprietary SaaS product, Eon Direct, uses computational linguistics to comb through radiology reports and identify suspicious observations and their essential characteristics.

Eon's team of clinically trained nurse navigators then utilizes the system to assess these observations, determine their risk levels, and establish appropriate patient follow-up protocols.

This process is complemented by the continuous tracking and management of these findings to optimize patient outcomes, executed collaboratively by the system and Eon's communication team .

The Challenge

I was tasked with redesigning the user experience of Eon Direct to increase system efficiency, allowing the existing team of nurse navigators and communication team members to handle a larger volume of patients.

The Research and Solution

Eon Direct is a complex system that serves a very specific clinical need in early cancer detection. The legacy system’s user experience was very open ended, allowing navigators and communicators to use it at their discretion, without following a rigid process. 

To evaluate its user experience for efficiency, I needed to first understand how users were using the system to impact clinical outcomes and the purpose behind their processes and actions. 

I had a unique advantage during my research in that a significant portion of Eon Direct users are internal team members, working on behalf of hospital enterprises. Instead of sporadic and formal interactions, I engaged with them on a daily basis. I spent my first few weeks at Eon primarily observing team members in their roles while seeking insight and clarification through questioning.

As I deepened my understanding of the legacy system and the behavior of its users, it became apparent that its user experience was not encouraging the user to form a strong and accurate mental model that reflected the system’s functions, processes, and its logical flow of tasks.

At a high level, Eon Direct’s function is to support two separate processes for managing patients with incidental findings. The system enables Nurse Navigators to process and triage patients with incoming findings and enables Communicators to ensure these patients are followed up with and their findings are monitored at the cadence determined by the Navigators. Both of these processes include several steps for each patient that must be performed in a specific order.

However, the legacy system’s UX was structured around a series of ambiguous ‘worklists’, as shown in the image below. Each list was intended to represent a patient's status or actions needed. But the lists lacked clarity, offering cryptic hints and confusing updates regarding the patient's progress in the system, forcing the user to untangle the puzzle to determine which actions were completed and which were outstanding. Patients also frequently appeared in multiple lists at the same time, even when the tasks associated with some lists must precede others. Furthermore, some of the lists were part of the patient processing workflow and some were associated with the communications workflow, but the lists were intertwined and presented in a random sequence, implying to the user that they were part of the same process.

A poor mental model can limit the efficiency of a system. This is because when users are encouraged to form a strong mental model that matches the reality of the system, they are able to make assumptions about how it is organized and how it behaves. Those assumptions can replace training time and rote memorization of system behavior for new users. They can increase efficiency for seasoned users by helping them rely less on conscious effort and memory to figure out how to complete a task. Instead of thinking about how to use the system, actions are more automatic while they spend their cognitive load making strategic decisions.

To encourage users to form a strong mental model that aligns with the functions and processes of the system, I knew that the redesign would need to involve a structural overhaul.

Isolating the System into Two Major Parts

During my research, I observed multiple training sessions for new navigators and communicators to understand how the system's design impacted user efficiency at different levels of expertise. It became evident that new users struggled to comprehend their roles within the application. Due to the entangled nature of the lists, educators found it necessary to explain the purpose of all worklists, causing confusion and wasting training time on irrelevant information. The system was not encouraging a mental model that implied that these are completely separate processes, a patient can only exist in one of the processes at a time, and, as a user, you only are concerned with one.

My solution addresses this issue by clearly segregating Eon Direct into two distinct areas, Patient Processing and Patient Communications, at the highest level of the information architecture. This separation ensures that each user group can focus on their specific roles without irrelevant information burdening their cognitive load. It also helps the user to quickly form an accurate understanding of the system’s two major capabilities and purposes.

Defining the Workflows

However, even after dividing the system into different sections, the worklists and general user experience still foster misconceptions for many users around the process and decision points for managing a patient with an incoming finding. The flow below is similar to how many users describe the process based on the UX. It requires hours of training and exploration for users to understand the inaccuracies in their mental model.

I started to remedy this by defining and optimizing the correct workflow and decision points. I did this by observing navigators as they “thought out loud” while processing a diverse set of real patient cases with unique outcomes.

This was difficult because the users I worked with were unable to articulate the entire workflow including all decision points and divergent paths as one process. This was simply because they weren’t used to thinking about it and describing their actual workflow separately from the UX and there was not any documentation presenting it in this way. However, they were able to clearly explain their decision making for each patient individually, which enabled me to piece together the process by observing as many different cases as possible and identifying the patterns of decisions.

For example, the application’s UX presents the user with the decision to add the patient to lung (activate), ignore the patient (archive), deactivate the patient, or add them to provider review. When users would reach this point during observations, they would often say something similar to “now I am triaging the patient by choosing from these four options and adding them to the lung cohort”. Adding the patient to lung (activating them in the system) is most commonly selected, so my early iterations of this workflow showed a four-way triaging decision point that matched the UX. However, after observing other cases, I realized that this was inaccurate. For example, patients are “ignored” (archived) in cases of false positives, where the system incorrectly flagged a report as including an incidental finding. Almost immediately after opening a patient chart, the user noticed that there was no finding present and jumped to the triaging page and archived the patient. This observation helped me realize that the first decision in the flow is to determine whether or not the patient should be archived, even though the UX presents this decision as part of triaging. This is an important insight when thinking about the new UX, because identifying false positives early in the process prevents navigators from wasting time completing other irrelevant steps. Even if navigators were not always performing this step first in the legacy system, working that into the new UX could be beneficial.

After observing users and continuously iterating on the flow, I brought it to leadership to ensure that it did not contradict any of their expectations. Defining the flow gave leadership the opportunity to make slight alterations to retain more data.

The final flow is shown below.

Representing the Patient Processing Workflow

In redesigning the UX for this process, my goal was to create an interface that enables users to quickly develop a mental model of the process that aligns closely with the diagram shown above.

To achieve this, I first pinpointed the four key steps present in nearly every patient's journey. I consolidated this information onto a single page activated by clicking "Patient Processing" in the navigation bar. Here, users have a visual overview of these four steps, each represented by an expandable bar connected by arrows to illustrate the sequential movement of patients through these stages. By incorporating dropdowns, users can expand each step as needed, revealing patients currently in that processing stage. This design choice allows users to see all steps at once, which helps them start to build a strong mental model of the process. It also allows users to easily divide their workloads by step if desired.

I opted not to include a step for determining if a patient should be archived due to its infrequent use in the case of false positives. Instead, I included an archive button at the top of the patient chart, enabling users to archive patients at any time without navigating through the defined steps to access a triaging page.

Upon clicking on a patient, users are directed to the patient’s chart, which includes an overlay of a linear progress bar that displays the entire process and indicates where the patient is within it. This mirrors and reinforces the visual of the process on the Patient Processing page and gives the user a quick overview of completed tasks and outstanding requirements. Prominent CTAs match the wording of the step in the progress bar to help the user move through the process easily.