Overview
Goal
Design an integrated, web-based social health screening and patient navigation tool according to the CMS Accountable Health Communities grant for implementation in Baltimore City. The screening and navigation tool integrates via API with a resource directory, a separate tool the team built at the same time (displayed in "Overall Flow" below). Responsive design essential for tablet.
Role
Product designer. I worked daily with the dev team to ensure design was correctly translated into code, managing the product roadmap, backlog, and communication with the client.
Time
May 2018 - June 2019
Problem
Navigators (social workers, case managers) often have a short period of time with a patient in the emergency room to understand their social health needs, like access to transportation, food, education, financial stability, safety, and behavioral health resources. Navigators currently collect patient information and questionnaire on paper.
Solution
A digital web-based tool for navigators to collect the screening data with patients, display resources available to the patient, and fulfill reporting requirements to CMS. Main goals include:
• Quickly (within 20 minutes) establish patients' social health needs
• Identify available resources to assist patients
• Track referrals to resources to understand city-wide capacity to assist people in need (closing the loop on referrals)
• Allow medical care teams to have a comprehensive understanding of public health resources and referrals affecting patient care outcomes
Limitations + Risks
• The end-user of this service are vulnerable patients from under-served communities. Extreme precaution was used in the design process to respect their needs.
• Patient data is extremely sensitive. It is very tough to design a system that effectively communicates informed consent.
User Experience: Research + Analysis
After our initial design sprint, we further defined users and their goals to create the tool's information architecture and features. We had 7 user groups expected to interact with the tool through role-based logins.
Research spanned the entire length of the project as a feedback loop for user testing to ensure that we had a diverse perspective. I (and a small team from the client) interviewed, observed, and had focus groups with over 100 users and stakeholders from hospitals and community-based organizations (CBOs).
Example of one of the Navigator personas based on user research. HCAM is Healthcare Access Maryland, a non-profit in Baltimore providing care coordinating services to patients.
User Journeys
With such a complex system to design, it was difficult to demonstrate the Navigator's journey and how it would change with the new tool (Now = with MVP, Future = post MVP features). I kept the journey simple, in a table that was easy to edit and update as any new details were found during user research.
The journey was especially helpful to communicate scope to the client to make sure that we focused on specific problems/frustrations of users to assist in prioritizing the backlog.
Product + Information Architectures
I created very detailed schematics and UI maps of the tool because of it is a very complicated system with various inputs for data. After a few weeks of vision alignment, I switched format to a more visual UI map rather than the previous schematic to provide clarity on progress to the customer and the dev team.
You can also see here that we decided to split the screening tool + resource directory into separate tools (separate stacks and infrastructure). We spent a lot of time at this stage to ensure that upon moving into full page design and code, we agreed on a flow.
The first schematic of the project -- it was overwhelming to say the least.
Prototyping: Wireframes + Mockups
Below is an example of the evolution of the Patient File. The main user goal is to verify patient background information, view patient's needs, add referrals and events, and view beneficiary screenings (raw data). The business goal is to collect data according to CMS data requirements in a user-friendly manner.
We iterated over the course of our sprints as more features were added, especially based on feedback from users to simplify the interface and bring most of the important information above the fold on the screen to ensure that users could easily navigate.
We struggled to scale the patient needs, considering that our first 2 iterations did not provide enough room for scaling to more than 4 needs at a time, while also displaying navigation events and other details on the screen. After feedback sessions and testing with users to determine their main goals, in iterations 4 we designed a tabbing system that was easy and quick to implement in code to simplify the experience.
You may also notice that to simplify the interface, we removed metrics and buttons from the top fold after users told us that the information was unnecessary for them to accomplish their goals.
UI/Visuals: Branding Guidelines + Design System
Below are a few examples of the design system we created for easy implementation by the UI developer based on US Design System (Bootstrap), with a few customized pieces.
