Automating services to improve both external and internal UX

This project focuses on a CDC-built and managed product that allows for the movement of covid test data from facilities to  public health jurisdictions.  Product teams were working to automate support processes, with the hopes of expediting resolution of issues and onboarding of new external users.

Understanding the current state

When I joined the team, there was very little information on what exactly these support processes were in their current iteration and as a result, determining which processes to automate first and understanding what that automation would entail was impossible.

Here is a zoomed-out view of one of the artifacts I co-created with developers to fully understand and disseminate internal support processes that we hoped as a team to start to automate.

I worked with the product's internal users, a support team including mostly developers, to map out highly technical internal processes. I ran 1 hour collaboration sessions 1-on-1 and sometimes with a small group of up to 3 developers. During those sessions, I asked the developer(s) to walk through the process we were capturing, and I took notes and prompted them with questions to better understand how the developer collected information and made decisions to resolve a support or onboarding need.

I then spent time on my own with the notes and built out an artifact to illustrate the flow of steps, and the developer(s) and I iterated on the artifact together until it was both true and clear.

From frequent support request to self-service

One of the support processes that we as a team decided to address was the work required to answer frequently asked questions about the specific sources of covid test data.

Relying on some previous research with external users and some research that I conducted with internal users, I designed a new feature for the web app that would allow external users to find answers to their own questions about where their data was coming from.

I was constrained by the design system of the app and by the needs of external users, who wanted answers to various questions about sources, and internal users, who can find information in the database faster when given specific information such as a test result's exact report ID.

To design these screens, I used the research findings to create a list of all the questions an external user may want to answer using these screens and then I started building them, using common patterns used throughout the web app. The highest priority question that this feature would answer: has x data source stopped reporting to my jurisdiction?

One aspect of the design that I added despite not seeing anything else like it on the app, was the small, colorful chip that denoted a detail page as one of three possible types: facility (including specific entities such as hospitals, nursing homes, public schools, etc.), ordering provider, and submitter. The three versions of detail pages look very similar and only have a few differences within the pieces information provided right under the main header of the screen.

The purpose of the colorful chip is to provide a recognizable indicator of what type of entity the user is viewing, and given that information, how to interpret the rest of the screen. The chips are in three colors to align with the three possible types: pink, yellow, and blue.

Ultimately, the purpose of these designs was to build a prototype that would allow us to test the concept with external users. When I wasn't sure what a user would want, I made a best guess based on what I did know, and then moved on, confident that we'd learn more and improve the designs in future iterations.

Part of the work of designing this new feature was figuring out how it would interact with other features in the app. There was already a feature that users could employ to download reports of covid test data. How might that need to change to accommodate this new feature that provides information about the data sources within each report?

I made some changes to the designs of the original feature so that the two features would function in complement to one another. For example, clicking on a report from the data sources feature would bring users over to the report feature.
‍
Clicking on a data source in the report feature would bring users over to the data sources feature.

Besides allowing the features to refer to one another, I added a few additional affordances and pieces of information to the report feature designs that would help to answer some of the external user questions I had recorded as part of research. One question I had in mind was: did this report include data from x source?

These redesigned screens now offer users the affordances of clicking into a report's detail page, and then to sort and search different types of data sources.

These screens were intended as a MVP or a test concept that would be used to learn more from users. Once this version of the app is built, we planned to start the work to build out more of a external user dashboard, using the same data and code that allowed these screens to function properly.

Search Pivot

Quick Links:
TourComparePricingCustomersContact