GRAIL - Pathfinder

March 2019 - May 2020

Grail's core product is a liquid biopsy multi-cancer diagnosis test that can detect 20+ types of cancer from a single blood draw. The core technology of the test is a machine learning algorithm that was trained by vast amounts of genomic and phenotypic tumor genome data obtained through the world’s largest cancer screening population studies.. The test is able to pick up weak signals of cancer as early as stage I, the most curable stage, and detect cancer types that have no diagnosis option today.

My Role

I'm the first (and only) product designer at Grail. I joined as we started to plan the diagnosis test pilot where we would return actual results to real people for the very first time. I was involved in design, research, marketing, product, business, commercial - everything needed for us to deliver our product to our internal and external users: this pilot is codenamed Pathfinder.

User Journey

We're building a first-of-its-kind test that has two groups of stakeholders - the healthcare provider (and for now the patient by proxy) and Grail's internal users. This is a really complicated end-to-end journey that involves many steps, from ordering the test to processing results internally (a test touches 12+ teams) to return results to the patients:

Test Processing

Problem

The inbound of samples and outbound of results requires the team to build a brand new product, one that seamlessly binds to existing infrastructure. Once we receive a sample, how do we make sure all the teams that need to touch it do so effectively, easily, and error-free? There are also a whole host of edge cases in this process - how do we handle them all (since each one could result in a failure in processing)?

Specifically, some of the problems individual teams face are:

• Manual entry is prone to error, how do we make sure data entered is correct? 

• When orders are placed electronically how do we match the inbound sample to the right patient & order form?

• Lab scientists sign off on hundreds of reports, how do we balance efficiency with concentration?

Research

I started by sitting with internal stakeholders and observing their existing workflows to gather more context on their day to day operations. After learning more, I designed and executed several research studies that simulated what they would need to do to process every sample, including testing various design prototypes. Since internal users are easier to access, I iterated on the designs many times until we had something that worked in the field.

Design

Once I had a good idea of the expected user flow I mocked up the first version of pre/post (the internal name we picked for this new product, pre-result/post-result). One design constraint is that all Grail internal tools use a shared UI library based on material design, while I made some changes to the library, I try to stay true to it as closely as I can.

Examples of problems mentioned earlier:

Manual entry is prone to error, how do we make sure data entered is correct? 

Lab scientists sign off on hundreds of reports, how do we balance efficiency with concentration?

Final end-to-end designs:

Returning Test Results

Problem

After Grail processes the test, what’s the best way to show this to the provider and the patient? How can we provide actionable and useful results, and in the event of a positive diagnosis, how can we communicate the next steps?

Research

Since these stakeholders were external, we did research with patients and physicians in situ to understand how our results would be communicated. We went to our partner hospitals and interviewed the doctors in our pilot, who worked with us to build reporting that was useful and actionable for them.

Design

We spent a lot of cycles working on the report itself and how to convey information effectively to the provider, taking into account not only the report itself but the context of the patient. Since it’s up to the provider to correctly interpret outcomes, we want the design to be informative rather than suggestive. 

Design iterations on main pages of portal:

Concept for features outside of portal:

Final Design for MVP:

Results and Next Steps

All of this work comes together in an end to end MVP experience that allows a provider to order and administer a test, for Grail to process results, and for those results to get delivered to patients - the first step toward our mission of detecting cancer early, when it can be cured. As of January this year we have two partners enrolled and processed 100s of tests. The plan is to conduct portal feedback interviews with physicians once they’ve received an adequate amount of results (especially after positive results) so that we can iterate and improve the experience.

I also want to highlight some future thinking I’ve done around the future of this product lifecycle, there’s an important player missing in the current user journey - the individuals (patient/customer). 

Research shows that they are actually the most proactive in their own health and have a need for extensive support top of the funnel and following diagnosis. Here are some products we might build for patients:

To make a true impact in society we also have to think through our long term reimbursement via healthcare strategy. There are additional parties involved in the adoption of our product like private employers, insurances, and the government.