mcvh portfolio cover.png

Creating a UI to book hundreds of Covid vaccine appointments >

Creating a UI to book hundreds of Covid vaccine appointments

My Roles: Research and design, including: user research, wireframing, prototyping, iterating on designs

Introduction

The Product: MA Covid Vaccine Help (MCVH) was a volunteer organization founded in February 2021 to help at-risk individuals book Covid vaccine appointments. At the time, booking Covid vaccines was a frustrating and confusing process, and those who most needed and wanted a vaccine had a very difficult time getting one. Volunteers used a database to keep track of everyone who requested help getting a vaccine, but the database alone did not meet their needs. I designed a UI in Figma to expedite the often complex workflows of the MCVH volunteers, and to keep the private health information of vaccine appointment requesters safe.

Duration: March - April 2021

mcvh mockup my requesters cropped.png

Background

I joined the volunteer organization MA Covid Vaccine Help (MCVH) at the end of March 2021 to create a user interface for their volunteers to use to more efficiently book vaccine appointments. In a very short period of time, the organization had grown from one to several hundred volunteers who were coordinating via the messaging app Slack. Vaccine-eligible individuals who needed their help would fill in an online intake form or call the organization’s 1-800 number, and their information would go into a database. In order for volunteers to access the information in the database, several volunteers had created a “SlackBot” with the ability to pull up information as it was needed. This was a command line-like interface that output information from the database and allowed volunteers to use and update the data.

The Problem: Many volunteers were uncomfortable using the SlackBot system. The system was cumbersome, only allowing a single piece of information to be displayed at a time, and required keeping a separate record of the individuals requesting help with an appointment (a.k.a, “requesters”) outside of the main database. Additionally, many requesters didn’t speak English, and specialized volunteer translators often had to work in tandem with a booking volunteer in order to effectively communicate with a non-English speaking requester. 

The Goal: To create a graphical UI that met the following requirements:

  1. Sign in through Slack

  2. Beginning to end workflow within the UI

  3. Minimal exposure of private requester information

My Role: Research and design, including: user research, ideation, prototyping, iterating on designs


User Research

I began by understanding the workflows of different cohorts of volunteers in order to identify their needs, and determine what part of the project to tackle first. Roughly, the volunteer cohorts were:

  • Requester intake - volunteers who obtained and input the information of people who called the 1-800 number

  • Appointment booking - volunteers who found and booked appointments for requesters

  • Language help - bilingual volunteers who partnered with other volunteers who didn’t speak a requester’s primary language

  • Queue cleaning - volunteers who reviewed the requester queue to find people who no longer needed an appointment, or those who had very specific appointment needs

Through this process, I decided that the workflow I would tackle first would be appointment booking. This workflow was what most volunteers spent their time doing, and it could be built upon to fit the needs of the other volunteer cohorts. 

The typical appointment booking workflow went something like this: 

  1. A volunteer would “claim” one or more requester profiles, taking them out of the queue

  2. The volunteer would then copy the profile into a local spreadsheet or doc where the profiles would sit until an appointment was available that was within the requester’s travel range, at a time that worked for them.

  3. Once the volunteer found a viable appointment, they would make the appointment by carefully copying and pasting information from their doc into the appointment booking UI. 

  4. The volunteer would receive a confirmation email, and then communicate via email and text to the requester that their appointment had been booked.

  5. Once the requester responded, the volunteer updated the requester’s status to complete.

This is what the workflow looked like at a high level. In this workflow diagram, I detailed each step in order to understand exactly what the volunteers needed to do to complete booking for a single requester.

Early high-level appointment booking workflow overview. As I learned more, I added to this workflow diagram and detailed each step in order to understand exactly what the volunteers needed to do to complete booking for a single requester.


Pain points:

  1. There were many places within this workflow where information could be lost or misplaced

  2. The work was slow, since a volunteer could only claim a single requester at a time

  3. The command line (SlackBot) was difficult to read. Information was revealed as new lines in a “conversation” with yourself, so as more information was revealed, relevant information was pushed upwards and often offscreen.

  4. Some volunteers forgot to “unclaim” a requester, making that requester unavailable to other volunteers to help get an appointment

Starting the design

Documenting workflows: I broke down each step from the above workflow into smaller steps to visualize them better. The workflow below shows how the volunteer would go about performing the first step in the workflow: claiming a requester. Because of appointment limitations, a volunteer would often need to claim a requester from a specific location. They was often also a need to find a specific person instead of simply choosing the next one in the queue. Once the requester was claimed, they needed to input the requester into a personal spreadsheet.

How a volunteer claimed a requester without UI support

How a volunteer claimed a requester without UI support

In the next step of the process, a volunteer would book the appointment for the requester. Many things could go wrong at this step that were mostly due to a volunteer’s lack of visibility into the requester’s needs (i.e. location, schedule, vaccine brand needs).

Volunteer books requester (1).png

I reviewed each workflow with several volunteers in order to make sure that I hadn’t missed a crucial step. It was also important to carefully define the MVP, because due to the complexities of appointment booking for large numbers of people, there were many things that could be done to make the process easier, but we wanted the UI to be useful as quickly as possible.

Interactive prototype

The MVP was designed in under a week in order to get feedback as quickly as possible. The UI could be accessed through single sign on (SSO) with Slack.

MCVH login screen.png

Once logged in, the UI would allow a volunteer to view their list of claimed requesters, in priority order, along with any information necessary to book an appointment.

At the top level, a volunteer could see the critical information needed in order to determine if a requester was a good match for an appointment. They could also see if the requester was high priority (color-coding was based on percentiles - for example, red was reserved for the top 10 percent of requesters, and indicated that they should be completed first). The volunteer could also change their status or unclaim them if necessary.

By clicking into a requester entry, the volunteer could add a note, see the requester’s full comment, and see any other requesters linked to the profile with the same email address. They could also make changes to the requester's language or add more linked requesters.

The requesters were divided based on whether their appointment had been booked, and whether they had responded saying they would be able to go to the appointment in collapsible menus. The UI allowed the volunteer to change the status of a profile quickly and easily.

The new booking workflow (with hi fi UI mockups) looked like this:

And the prototype looked like this:

Key design points:

  1. All basic demographic information is shown at the top level

  2. By clicking into a requester’s listing, the volunteer is able to access more detailed information and notes

  3. A requester’s full profile includes all of their private information, and only one requester’s full profile is available at a time

  4. Requesters who were not yet eligible for a vaccine had their eligibility date clearly listed

  5. The requesters were automatically listed in priority order, and color coded so that the top 10% of high priority requesters were shown in red

  6. Requesters often needed to be booked together, but were not entered into the system together, so the UI allowed requesters to be added to a single listing to ensure those would be booked together

Unexpected conclusion

The above process took about a month. At this point, due to the increased availability of the vaccine, and subsequent lack of demand for MCVH’s services, this UI was never refined or implemented. A product not launching is seldom something to celebrate, but in this case, it was! We were very happy that people could get the vaccines they needed without needing volunteers to help them.

Despite the success MCVH experienced, it is important to point out that not everyone had easy access to the vaccine by May, and my next goal for MCVH was to show the barriers to vaccine access and how the state could improve access for everyone.