COVID-19 Pooled Testing
How a lean product team used an iterative, feedback-driven process to design a clinical testing tool that met regulatory requirements and was usable by teachers with minimal training.
Overview
I was the lead designer for Color’s COVID-19 diagnostic services during the pandemic. Pooled testing was one of the many services my team built to meet immediate testing needs as the pandemic rapidly unfolded. With a lean team and tight timelines, we were designing for accessibility and efficiency.
We built a patient-facing experience, an admin-facing experience, and a clinician-facing experience in the Onsite Tool. For this case study, I will focus on how we designed a pooled testing workflow in the Onsite Tool.
Background
There was a need for affordable and available COVID-19 tests.
Employers and K-12 schools were struggling to reopen during the summer of 2021. Individual COVID-19 lab testing was expensive, but rapid tests were scarce. K-12 schools specifically needed an affordable option to monitor the spread of COVID-19.
How might we improve affordability and access to COVID-19 testing so that employers and schools can re-open safely and quickly?
Opportunity: Pooled testing
Pooled testing was identified as an opportunity by Color’s Lab Team. We could use our existing COVID-19 lab infrastructure to support pooled testing.
A group of individual nasal samples would be “pooled” in the same collection tube. The pool would be analyzed as one sample at the lab, which reduces cost at scale. If the sample is positive, then at least one person in the pool is positive for COVID-19. If the sample is negative, then everyone in the pool is negative for COVID-19.
We had the lab infrastructure to make pooled testing a reality, but we needed software to support it.
Pooled testing: A group of individual nasal samples are “pooled” in the same collection tube.
The Team:
1 product manager
1 engineering lead
1 full-stack software engineer
1 product designer (me)
My role:
UX/UI designer
Content designer
Visual designer
Interaction designer
Prototyper
Timeline: Unknown
The ambiguity of the pandemic meant that we would often identify potential solutions before we knew whether or not customers would ultimately need them. Pooled testing was no different; a contract had not yet been signed when we kicked off the project, so it was possible that it would be a dead-end. It was also possible that we would sign a contract and need a functioning product with a week’s notice.
Users: Unknown
Without a contract signed, we did not know exactly what use cases or users pooled testing would need to support.
Designing for reopening workplaces would have different technical requirements and nuances than designing for reopening K-12 schools.
Assumption-based model: Design for K-12
At this point in time, we had successful testing programs for public health departments and private employers. We had not yet designed for dependents (schoolchildren), and we hypothesized that the need for affordable testing would be greater among K-12 schools than employers.
We decided to move forward under the assumption that our key customer for pooled testing would be K-12 schools.
Without bandwidth for in-depth research, I used the information we did have to develop assumption-based requirements and constraints. This was a starting point, but I would need to find an opportunity to test these assumptions.
Assumption-based workflow:
Color’s Onsite Tool supports the workflows for providers, clinicians, and other staff at testing sites.
To inform the digital pooled testing experience, I worked closely with the Commercial Team, the Lab Team, and the Medical Affairs team to map a workflow for K-12 schools.
Assumption-based digital model:
1 classroom = 1 pool
The Onsite Tool would always be used on tablet and did not need to be mobile-responsive (Color provided iPads to all test sites up until this point)
Assumption-based users:
Nurses have a clinical background and familiarity with complex clinical tools
Nurses would receive training from Color (this was the model for all of Color’s COVID-19 test sites up until this point)
This was the existing logged in homepage for Color’s Onsite Tool.
Iteration 1: Recycle Existing Product
We only had one engineer on this project, and we might need to ship a functioning product with a week’s notice. Therefore, we decided as a team to reuse as much of the existing experience as possible.
For K-12 schools, we operated under the assumption that 1 pool = 1 classroom.
Under this assumption, I adapted the logged in homepage to reflect a list of pools instead of a list of all patients.
In order to reuse as much of the existing interaction patterns as possible, tapping on a row opens the workflow for pooled testing.
Feedback
I created a prototype for the Commercial Team to share with potential customers. We received feedback from Cincinnati Public Schools which upended a handful of our assumptions.
New users: Teachers
Teachers, not nurses, would conduct testing
Unlike nurses:
Teachers may not have experience with clinical tools
Teachers may not have a clinical background
It was unlikely they would have bandwidth to review complex training materials
New data
1 pool = 1 classroom would fail
Students often moved between classrooms and schools within a district, so it would be difficult to manage in the Admin Dashboard or on Color’s backend
The Onsite Tool had to be usable without training, and it needed a flexible model for creating pools of students.
Iteration 2: Search-first
Teachers are busy and needed a simple, easy-to-understand product. Plus, they would not only be using a digital tool for pooled testing; they would also be juggling samples and managing students. Therefore, I proposed a solution that utilized the following principles:
Each step should have one clear task and one clear action
The experience should be search-first instead of relying on an expansive patient list
In lieu of training materials, speed bumps should be incorporated for error prevention
It would require more engineering effort, but it responded to real needs of teachers and their environment.
In the new workflow, each step of the pooled testing process is a focused screen with one clear action.
Feedback
The Commercial Team shared the prototype with Cincinnati Public Schools. It was well-received for its usability, but we had a handful of new problems.
New timeline: 1 week
Commercial had signed a contract; my team had one week to ship a functioning product.
New users: Any school staff member
It would no longer be teachers using the Onsite Tool; it would be anyone at a given school who was available when needed.
New requirements: Mobile-first
School staff would be using their personal mobile devices, so we needed a mobile-first experience.
In the new workflow, students would line up outside of a testing room. Inside the room, school staff would use the Onsite Tool on their personal mobile phones.
Negotiating timelines
It would not be possible for our engineer to build the search-first solution in one week. We either needed to develop the list view UI, which we knew was not usable, or we needed a deadline extension to build the search-first experience.
Because the Commercial Team had seen firsthand the value of the search-first experience, my team received a deadline extension. But now, I had a new design challenge: the UI needed to be optimized for mobile.
Iteration 3: Mobile Responsive
I initially attempted to include search, the patient list, and the list of participants in the pool in the mobile UI.
Feedback
When I asked for feedback from my team, they had an idea: the patient list was not usable, and we were building a search-first experience, so why not remove the patient list?
What We Built
At this point, we had a usable, mobile responsive solution for Pooled Testing that was validated by real users and could be feasibly built by our engineering in the new timeline. My team successfully designed and shipped a patient experience, a clinician experience in the Onsite Tool, and new analytics features for the Admin Dashboard.
Patient-facing registration and results:
Clinician-facing Onsite Tool:
Additional analytics features in the Admin Dashboard:
Real-world Feedback
I visited a Cincinnati Public School during the launch of Pooled Testing, and while the digital experience was easily for school staff to use, I discovered that we were going to need more swabs. Color supplied its own test kits to schools, including swabs; the number of swabs was equal to the number of students at the school. However, young schoolchildren don’t have perfect dexterity. I noticed that they would often drop swabs on the ground, touch them with their fingers, or find other ways to contaminate them. This meant that the school ran out of swabs before testing was complete. I brought this feedback to the broader team at Color, and we updated the supplies we sent to schools to improve the pooled testing experience.
Impact
We quickly met technical, ambiguous testing needs in 2021 with a user-centered approach, and this approach also established design as a thought partner across Color. Through research and insights about real users and the context in which they work, we built an effective solution that also created a paradigm shift within Color.
Because the commercial team witnessed firsthand the value of an iterative design process and feedback from real users, we moved from an assumption-based model to a user-informed model as an organization.
The market shifted, and towards the end of 2021, vaccines were becoming available. Then, in 2022, vaccines and rapid tests became readily available, so the need for affordable lab testing diminished.