User Journey for CDC Public Health Portal

It’s tough when you’re just starting an application or a feature

It's important to have a UX strategist who can gather the context of use and map out what a user would experience. Let’s explore the development of user journeys for a public health application. 

Project Scope

  • Goals: Map out what users would need to do to send and receive public health data through an application 

  • Client: Center of Disease Control and Prevention (CDC)

  • Method: empathy mapping workshops, persona development, user journey development, user flows, comparative analysis 

  • Duration: 10 weeks

  • Participants: 19 team members

  • Recruitment: Email schedule team members 

  • Tools: Miro, MS Teams, Dovetail, Figma

Background

Public health agencies and the general public need to know accurate data on immunizations, cases, and other associated data on various diseases, viruses, and disorders. The CDC needs to collect the data the data from many sources so that they can analyze the data and disseminate statuses.

I conducted empathy mapping sessions, persona development, user journey development, user flows, and comparative analyses to identify how organizations and tech companies who send and receive public health data with the CDC would best interact with a data sending observability application.

Empathy Map

What were we dealing with?

I conducted empathy map sessions with various stakeholders to determine how teams interact with the Portal system.

Teams consisted of:

  • Portal team (designers, developers, product managers of Portal UI and specific portal features)

  • Portal Company (company that owns the Portal product)

  • Upload API and Processing Status team (team who develops upload and status tracking capability)

  • HL7 team (team allowing for HL7 data processing)

  • FHIR team (team allowing for FHIR data processing)

  • Routing team (team working to route data endpoints to select databases and data lakes)

  • Customer support team (IT team, responders to help requests)

  • Program onboarding team (team that registers teams of Portal Company who receive public health data from sources who send data)

Portal works by:

  1. Portal system teams develop the Portal APIs and systems and integrate to the appropriate endpoints

  2. Programs of Portal Company are onboarded to the Portal and provide details on public data, the format, and the timeframe they are expecting

  3. Programs alert Organizations to register to use Portal. Organizations register to use Portal

  4. Organizations submit their public health data to Portal

  5. Organizations check their submission statuses

  6. If errors occur, Organizations and Programs troubleshoot if their data has not sent or that data has not landed in the specified destination respectively

    1. Some errors will require Organizations to resubmit their data

  7. Programs collect their data from the specified destination. From there Programs will analyze the data and distribute the findings amongst Program Company and/or to the public

Findings

Findings with the empathy map sessions allowed me to produce preliminary service design documents with accompanied comments:

  • Actors: who are the teams and users that interact with the Portal system

  • Transactions: what are the tasks, processes, and responses teams and users perform and respond to

Users of Portal are:

  • Organizations that send data to Portal Company and

  • Programs within Portal Company who receive data from the sending organizations

The empathy map sessions were focus groups of each team:

  • Who are we empathizing with?

  • What do they need to do?

  • What do they directly experience or see?

  • What do they communicate or say?

  • What actions do they take?

  • What do they think and feel? Pain points and achievements?

Personas

Who is sending public health data?

I looked further into who are users are to create personas and persona factors.

Personas are fictional sample users used to represent a real user.

Persona factors are variables about that influence users to behave differently than others.

Persona development

There were four personas in the form of organizations:

  • A Program is a group of epidemiologists and IT personnel working in Portal Company

  • A Public health tech company or intermediary is a company that sends public health data on behalf of other Organizations

  • A Public health data producer is an organization that collects data from health professionals and companies within their jurisdiction)

  • A Portal team member is a team member of the Portal system teams that use Portal to assist Organizations and Programs and to troubleshoot system errors

Each type of organization and program will have managers and staff members. Designated managers could use an admin account allowing them to manage their team. Teams may also have developers, IT, staff members, and external systems that modify data before or after routing through Portal.

Persona Factors

Some other persona factors include:

  • Technical acumen and sending mechanism can influence how a user uses some of the Portal’s tools

    • Some Organizations will directly upload public health data to the Upload API using automated batch uploads that operate system-to-system.

    • Other Organizations may still use a very basic email of files or a spreadsheet and will need to learn how to format a submission into the accepted formats using manual upload on the Portal.

    • Some Organizations will use a public health tech company to develop the system to allow for automated batch uploads

    • Some Programs will have data routed to an intermediary system to further modify the received data before sending the data to a destination for the Program to pick the data

  • Data size can influence how often and what information is most useful to be presented in particular ways on the Portal

    • Some Organizations will submit very large files of public health data

    • Some Organizations will submit daily while others may submit monthly, quarterly, or annually

Public health data producers represent many organization types:

  • State jurisdiction organization (often within the state’s department of health)

  • Territory jurisdiction organization

  • Local jurisdiction organization such as metro area, county, or city limit

  • Tribe jurisdiction organization

  • Community organization

  • College or university organization or laboratory

  • Specialty laboratory

  • Specialty hospital or clinic

  • Commercial laboratory group or patient-centric custom application

  • Data type can influence how a user submits data and what metadata needs to be associated with the data

    • The content of public health data can range from viruses and diseases to other reported data such as newborn hearing, childhood blood lead testing, and infection antimicrobial resistances

    • The data will document multiple types of services such as immunizations, case reporting, surveillance, tracing, and screening

    • Data can come from patient data, inventory, order and shipping documents, laboratory results, extracted from multiple databases, and more

  • Data format can influence the mechanism in which a user submits the data

    • Programs assign the data format

    • Some Organizations will submit in formats such as HL7 and FHIR where others may use other simpler formats such as CSV

List of Features

What exactly are these users doing?

Working with the Portal team and leadership, I conducted a series of workshops so that we could finalize a list of features and scope as a minimal viable product for release (MVP).

List of Features Workshop

Before the workshop I synthesized features discussed or hinted at from prior meetings including the empathy mapping sessions, persona development meetings, and other product meetings discussing development and the use of metadata. After the synthesis,

The sections of the workshops were:

  1. Listing out all of the features

  2. Listing each feature by role (personas and persona factors)

  3. Listing each feature (by role) by journey phase (transactions)

  4. Later we used the following list to assign priority MVP

A list of features is a document to display all features planned, if they are required for MVP, and for which account types should have access to the feature.

List of features

The major features of Portal are:

  • Submit public health data through upload tool

  • View details and status of submissions

  • Search, filter, and sort through submission

  • Update your profile and settings

  • Manage your team (admin)

  • Manage the data Organizations are expected to attribute to a submission (Portal team and Portal Company Programs)

Below is an image of how the list of features by role and journey phase looked that was later used to assign priority.

User Flows

What are users doing on these features?

While the Portal was being designed, I supported with creating user flows for the features.

I created user flows for the:

  • Upload page

  • File Submission Search & Details page

  • Login & Registration page

  • Account Profile & Settings page

  • Manage Your Data & Team (metadata management) page

I also created user flow for the more extensive (before and after registration) onboarding process for onboarding new Portal Company Programs and their Organizations.

Conclusion

The insights from the service design workshops and documentation as well as the user research and testing supported the initial version of the Portal.

Unfortunately, the Portal product was cancelled in an effort to consolidate products at Portal Company. Fortunately, many of the insights and ideas was later used on a different product form Portal Company.