Product Design | Code for America
Directing EMTs to available care
Work In
Progress
Overview
In summer of 2020, I began supporting research and UX / UI design as a volunteer with my local Code for America brigade. Our interdisciplinary team of social workers, front- and back-end engineers, and data scientists meet weekly to collaborate and iterate on a tool that will help ambulances direct non-critical patients to emergency departments with the most available capacity.
Today, we're finalizing a low-fi prototype and will begin gathering feedback from EMTs and hospital staff in the coming months.
My role
I am one of two designers on the team. The project leader and I connect weekly to discuss new features and adjustments to the UX / UI, which I then implement. I'm also currently drafting a research plan which we will begin executing in the coming months.
Tools
Our Focus
Ambulances waste valuable time waiting to drop off patients at EDs.
Supply and demand of emergency department (ED) care isn't matching up.
Lack of reliable, real-time bed count data makes ED capacity opaque.
Limited visibility into the number of ambulances en route and waiting to offload patients obscures wait times.
Single-channel radio communication delays critical incoming patient information.
Strategy + goals
Create a browser-based web app that helps reduce ambulance wait times by:
1
Helping EDs streamline patient intake with a digital ringdown.
2
Helping EMS teams direct patients to the most available care.
Co-designing the platform
Basic service mapping
Throughout the design process, our team conducted regular interviews with Niels Tangherlini, EMS Operations Chief with the SFFD, and other emergency + hospital staff who are directly impacted by ambulance wait times.
Together, we audited existing tools and work flows, identified critical data points that have the strongest impact on hospital selection + ED preparedness, and selected opportunities to improve communication.
Finding the holes
User Experience Mapping
To help comprehend the entirety of potential interactions across the platform, I created a UX map for each user type. I used a color coding system to identify how actions were triggered, whether they took place within or externally to the tool, and their outcome.
This revealed a litany of edge cases (e.g. delayed data entry, ignored notifications) that we hadn't planned for, and helped inform our research questions for lived-experience participants.
Can't do any good if no one's using it.
By bringing in nurses and EMTs to define the parameters of the tool, we aim to compliment existing workflows and encourage adoption + sustained use.
Too glossy
When I first joined the team, my inclination was to jump to designing highly visual, colorful interfaces. It quickly became clear that this approach:
-
Demands too much real estate on the screen
-
Wasn't easily scannable
-
Relied too much on color to communicate statuses, and
-
Distracted users from the functional feedback we wanted to collect
Guide user action
Continued iteration on the product focused on enabling rapid and accurate data entry.
-
Vertical orientation encourages a linear workflow
-
Sectioned + listed data is more easily scannable
-
Deliberate, consistent color use indicates actions and alerts
-
More utilitarian aesthetic focuses feedback on function
Match the medium
Further discussion with hospital and emergency service leadership gave us a better sense of what devices would be most easily adopted by the staff on the ground (tablets for nurses, smart phones for EMTs).
This enabled me to design components, interactions, and notifications that better fit the devices' native capabilities.
This became a great opportunity to teach myself Figma's component and prototyping features.
Building from the USWDS-up
Component design
The project leader recommended that we use the U.S. Web Design System (USWDS) as a foundation for the project for three main reasons:
-
Components are designed for accessibility
-
Design guidelines have a familiar, institutional aesthetic
-
Existing code base allows for rapid development
Working from the project leader's initial wireframes and the constraints of the USWDS, I built out an expanded library of unique components that could adapt to fit a wide range of devices, and be easily updated as we continue to refine the tool.
I designed the component structure with success and error states in mind, to ensure that data would be input accurately, without disrupting the flow of the form.
Something to respond to
Initial prototyping
I then assembled the primitive components to create a clickable prototype, which we used internally to visualize and iterate on user flows, interactions, element states, and behaviors.
I wired a variety of user flows that would illustrate a range of potential paths an EMT or nurse may follow when using the tool.
UI variations
Preparing for usability testing
While we are coordinating our first round of user testing sessions, I've begun iterating on our initial bare-bones prototype with more refined component variations.
A more clearly defined visual hierarchy helps delineate between higher- and lower-priority information. Providing a variety of options for how this information can be configured will help our research participants articulate the proper information architecture.
Bringing in stakeholders
Pitch deck creation
To help Niels recruit emergency and hospital staff for our pilot program, I created several distinct pitch decks synthesizing our thesis, the team's work to date, and my own research into the problem focus.
Next steps
1
User research
I'm now building a research plan to gather feedback from hospital + emergency staff remotely while their time is stretched particularly thin.
2
Refinement
We'll then re-evaluate and refine the initial prototype based on the information and features that are most valuable to our users.
3
Pilot
Finally, we'll test the tool with a selection of hospitals and emergency service providers in the city of San Francisco.
