Copyright © 2019, Julia Park

julia.park@berkeley.edu

Manage contagious diseases

When:

Aug-Dec 2018 for INFO213 : User Interface Design

Team Members:

Evan Burch

Amy Turner

My Role:

UX Research

UX Design

Ideation, IA

Wireframing

Prototyping

Logo Design

Tools Used:

Adobe Illustrator

Adobe Photoshop

AdobeXD

Figma

InVision

Hand sketching

Background

The class was asked to find a problem space that would require three stakeholders to solve collaboratively. Our team chose the field of epidemiology because of its rich cast of stakeholders and wicked problems. Because our team was largely unfamiliar with epidemiology, we approached the problem using a double-diamond approach.

Desk Research

Confirming that there's actually a problem that technology can solve

We initially conducted landscape research because none of us were familiar with epidemiology. We looked through publications, published research, etc. which helped narrow/define our scope.

FINDINGS 

RESULTING DECISION

Epidemiologists operate at several different scales. Global, federal, state-wide, county. Each branch has unique challenges.

 

The term "epidemic" is very broad, and many types of "epidemics" exist.

There are MANY stakeholders which contribute to the field of epidemiology. Nurses, doctors, labs, epidemiologists, data analysts, policy makers, patients, etc.

Focus on county-level epidemiology system due to ease of access to interviewees

Narrow scope to communicable diseases

Focus on a system that interacts with epidemiologist, nurse case manager, and patient.

But, perhaps most importantly, we found three documented problems in the field of epidemiology that might be mitigated by data management/technology.

01. The stakeholders must be able to communicate clearly/effectively to one another.

02. The epidemics must be managed in a timely manner.

03. The epidemics must be managed in accurate manner.

The desk research was useful in getting a big picture overview into the unfamiliar field of epidemiology, but designing a tool required us to dive deeper into the actual stakeholders' work. So we next worked on the stakeholders that we could run some user research on.

Based on our desk research, we found a trio of stakeholders who seemed to exchange a lot of data with one another; to confirm, and to learn more about the problem space, we scheduled expert interviews with the three stakeholders. Some were contextual inquiries and others were held remotely. I focused on the user experience of the epidemiologist.

Epidemiologist (ME!)

manages multiple case managers who provide a lot of data regarding epidemics

Case manager/Nurse

point of contact for those infected and manages their health case

Patient

dealing with a contagion and relays health information to their case manager

Expert Interviews

There's so much data an epidemiologist has to be aware of!

We interviewed epidemiologists at the Alameda County Public Health Department (California) and Tri-County Health Department (Colorado). Although we as a team conducted more interviews, the most pertinent data for me arose from these two interviews. The former was in-situ and the latter was a remote phone call. The interviews were, for the most part, unstructured simply because we wanted to really widen the net for design opportunities in this unfamiliar field. As a result of the interview being unstructured, I had to parse out design opportunities from a lot of conversation. One of the biggest findings had a big impact on my future information architecture:

The tasks of the epidemiologist, although varying from county to county, largely fell into three categories: Disease Management, Monitoring Reports from Health Providers, and Federal Information Updates from CDC. It is from these three areas that timely and accurate notifications are essential; currently the data stream is monitored manually. 

This finding would later greatly determine how I decided to organize my application because I wanted the flow of the interface to mirror the existing mental workflow of epidemiologists. In addition, it became very evident that current and accurate information was the crux of the epidemiologist's work. Below are the rest of my findings, and I've listed the resulting design features. It's quite text-heavy, but the interviews were so fruitful, complex, and interesting so I had to include the findings!

DISEASE MANAGEMENT

1. To me, one of the most interesting parts of the epidemiologist's job appeared to be left up to "chance" and prone to human error. It turns out that in epidemiology, finding a common "link" or source of illness between two patients is really important. For example, finding out that two patients with Salmonella poisoning ate at the same restaurant around the same time last week is an important thing to know! However, in the current system, the only way to discover this important piece of information is through "chance." For example, Dylan and Molly (two case managers) might be chatting casually over lunch about their latest cases. It's only when Dylan mentions in passing that one of his patients got sick from eating at Taco Joint last week. Molly then realizes that one of her patients, also sick, ate at Taco Joint last week. In other words, the discovery of a "source" of illness might literally be dependent on a lunch conversation.

FEATURE: I need to design something that allows for this source detection to be automated using the data that my case managers are collecting. 

2. Each disease's specifications, reporting needs, etc. are HIGHLY unique. As in, the definition of an "outbreak" for that Tuberculosis might be different from Ebola and the type of information case managers need to collect from patients is different for each type of disease.

FEATURE: The application needs pages which are "disease-specific." In fact, this entire section "Disease management" needs to be disease-specific.

3. Case managers should be able to see real-time, overall data trends when it is important. Case managers are encouraged when they see their work is helping reduce new occurrences of a disease.

FEATURE: I need to be able to send notes about data trends to the case managers

4. Due to the sensitive nature of health data and trends, it is important to have data vetted by case managers and scrubbed by data analysts.

FEATURE: I want to see data real-time, but I also need to have a way to see well "vetted" data from my analyst. Accuracy is more important than speed.

5. The ability to have some control over any automated processes is very important. Previous attempts to introduce automation into epidemiology have failed due to the inability to tailor "alert" settings for the diseases. For example, some diseases historically have "high" seasons where experienced epidemiologists expect to see an increase in cases over the summer. However, there was no way to input this "expected increase in cases" into the old systems, so the system would send many alerts about an "outbreak" over the summer seasons.

FEATURE: I need to implement customize-ability for each disease.

FACILITY REPORTING

6. Labs and doctors are required by law to report new cases of a communicable disease. One of the most troubling problems for epidemiologists are when there is a sudden decrease in reports from either a lab or a doctor (usually due to a system error). Therefore it is important to know when this happens as soon as possible.

FEATURE: I need to receive alerts when there is a decrease or in reporting from a given lab or facility.

FEDERAL UPDATES

7. Sometimes, updates from the federal system mean that they have to collect additional information from patients for a given disease. However, the current means of data collection is on paper forms. This means that most new, required information is actually jotted down in the margins of the paper data collection form.

FEATURE: I need a way to see updates from the federal system, and a way to edit the data collection forms that case managers use to get data from patients.

Jobs To Be Done Statements and a Persona

Because the design that was emerging tended to be task oriented, I prepared both personas and jobs-to-be-done statements. 

Ben, epidemiologist

Age: 47

About Ben:

Ben cares about preventing biological disasters in the city. He is a firm believer in good, clean data that can help him see patterns regarding contagions. He has to deal with a ton of data from many different sources, and he needs to make sense of it all. He works closely with case managers.

Behavioral Considerations:

-Does not want to act rashly - prefers to wait until more accurate data arrives to prevent panic

-Trusts systems-in-place, trusts data from analyst

-Methodological, organized approaches are required for his line of work

Frustrations:

-Human oversight or error might cause him to miss epidemiological connections between cases

-Data transmission between entities is not uniform leading to missing information being logged

1. I want to manage and analyze several different epidemic cases so I can analyze current risks and predict future risks, gain a comprehensive understanding interrelations between cases, and form a response plan.

2. I want to make sure that I am getting the right information into my database so I can accurately diagnose problems quickly and reduce the burden of human error and oversight in detecting problems.

3. I want to forward information/alerts to others so that I can share information in a way which does not cause panic.

4. I want to interface with the federal system so that I can have the most current information and needs

5. I want to have the ability adjust sensitivity of flags so that I can avoid getting flags all the time for things that are normal and avoid being annoyed.

Information Architecture

An information network between three stakeholders

I had to work closely with my two teammates who were designing the UX for their respective stakeholders. The design that emerged was one of an interconnected network of data transmission to help prevent data loss and reduce human oversight. As mentioned previously, I knew I wanted to structure my application to mirror the mental categorization of the epidemiologist, so I split my application into Disease Management, Monitoring Reports from Health Providers, and Federal Updates from CDC

Wireframing

Seriously a really early iteration of my design approach.

Basic Design Approach

01 - Separate application into the three distinct sections

02 - Make alerts prominent and provide a way to verify the source of data

03 - Provide extreme amount of customize-ability

04 - Make the data displayed 'disease-specific'

Sketching layout of various features and figuring out organization/flow... 
Version 1 of Landing Page... I was concerned with what was the most important information to display on this landing page
I rounded corners of alerts to try to distinguish them from a normal information display
You can see the separation of the three categories here
To handle the three categories of tasks  (Disease Management, Reporting, and Updates), I stacked a navigation bar to the left with these three categories. To switch between diseases, I included an easy-to-access disease search box on the left.
To tackle the fact that epidemiologists trust their data analyst that already provides them with charts, I decided to include two pages of data visualization - the first was 'auto-generated' data that only included information that the system could know, such as aggregate case manager data. The second was a page filled with infographics that the data analyst would upload. I've shown the toggle/dropdown option to switch here

Usability Testing Round 1

A cognitive think-aloud task-oriented interview. I created a test plan and recruited 3 public health students.

KEY FINDINGS 

1. Proper copy/text is CRITICAL, particularly for field-specific jargon. If the terminology is not natural, then users will become confused. The prototype does not use intuitive language.

 

2. Data visualization on landing page is not really noticed.

3. The separation of categories confused users, but I suspected this was because I tested students rather than professional epidemiologists (later confirmed).

4. It was unclear to users how to switch between diseases. It wasn't clear that the pages they were looking at were disease specific.

Wireframing Round 2 + Running Usability Tests Again

Moved work into Figma because I wasn't happy with Adobe XD, and prototyped in InVision. Ran usability tests on usertesting.com.

I revamped the landing page to very clearly indicate the three sections of the application using three bounded sections.
Instead of stacking  all alerts in one section together, I placed them within the context of each of the three categories
Removed data visualization from landing page and moved it into the disease management section
Forced user to have to type in specific disease to enter the "Disease Management" section to reinforce the idea that the data they were looking at was disease specific
Emphasized  single most important statistic on landing page
I still wanted to keep the vertical navigation bar from lo-fi mockup showing the three sections - but I also wanted an "x-axis" showing disease specific pages.
X-axis showing disease specific pages
Y-axis showing three
task areas
X-Y Axis implemented
Y-axis showing three
task areas
Too much data here would have likely been mistrusted by the epidemiologist and hard to read in a glance. So, I opted to show only the most important information here and that was the number of cases over time with respect to when an intervention was introduced. A very simple line graph with a vertical marker shows the most important piece of information - "trend over time and point at which intervention was introduced"

KEY FINDINGS 

1. The separation of concepts/workflows is intuitive to professional epidemiologists.

 

2. Rather than using the mechanism I built to "switch" between diseases, users would simply just go back to the landing page and re-type in a different disease. This actually seemed like a fine solution because it's probably unusual to switch between diseases in one login session.

3. It was clear to users that the pages they were looking at were disease specific, due to the X-Y axis system.

Final Prototype

Data dashboard for specific disease with both real-time data and vetted data

Final Prototype

"X-Axis" design showing disease-specific pages

Alert for potential source identified for a disease

"Y-Axis" with three categories of workflow