UX/UI design, usability testing, evaluative research
My internal team was comprised of a Project/Brand Lead, Website lead, UX designer (myself), Software engineer, along with the client-side product manager and engineering team
Three launches over the course of 20 weeks
– Multiple partners (integration between the biotech, ExamOne, PWN Health, and Labcorp)
– Multiple purchasing options, which changed over the course of the project
– 12 required eligibility questions: some required by Health and Human Services (HHS), and some required by the partner, PWN health
– Purchasing the test is only the first step in the process: we must communicate the next steps to fulfill the test
– This is a standalone site for customer education and payment process
– Allow for future expansion of product for other disease states
Initial Service Design
We first sought to define the steps involved in purchasing and following through on the test. As there were various flows determined by key integrations, we needed to document how the steps would change based on the user’s choices. The service design evolved over the course of the project as new stakeholders were brought in, but this initial work laid the groundwork for our design process.
Next we worked with the key stakeholder to develop a wireflow, which presented multiple navigation paths in a single flow. This allowed us to find natural breakpoints for communication screens.
Medium-fidelity wire flows
Paired with click-through prototypes, medium-fidelity wire flows allowed us to validate high-level user flows with the key stakeholder, and communicate the structure of the user flow to the development team.
Click through prototypes
These click-through prototypes allowed us, the client-side stakeholders, and the development team, to experience the user flow.
For the initial (MVP) launch of the product, not all of the planned partnerships (automated test prescription and partnered blood draw) were yet in place. Therefore, for the MVP launch, the test was prescribed by a customer’s doctor, with blood draw through the customer’s doctor’s office (if the doctor offered blood draw) or optional partnered blood draw for an additional cost.
Specific to the MVP testing scenario, we hypothesized there were many questions we needed to answer for users, including:
-Who is the doctor? Can it be my doctor, or do I have to select from a pre-selected list of specialists?
-Does the doctor offer blood draw services? How do I find out? If they do, can they work with this test?
-Why do I need to answer these eligibility questions? For what will they be used?
MVP Usability Testing: Friends and Family
-7 individuals, ranging in age from 20s–60s
-Participants were given one of two scenarios and encouraged to explore a static prototype, narrating aloud their thoughts & questions through the site.
-Scenario A: Your doctor sends you a link to pay for the test they’ve prescribed.
-Scenario B: You heard about a new COVID immunity test on Facebook and think you may have been sick recently. As an essential worker, it would be helpful to know if you have immunity.
In the initial round of testing, we aimed to learn the following:
-From the homepage, can users navigate to the payment process?
-In the payment process, are the different test types clear?
-Is the amount required to pay clear, and why?
-Are the eligibility questions clear?
After this round of usability testing, we made a few refinements— all outlined in the MVP key findings deck.
Key changes made
We recommended and made changes around how pricing information was displayed. We tested two options for pricing: one was the stakeholder’s first choice language, and the second was an alternate option—intended to improve transparency and clarity. As shown by the participant’s responses, the alternate option was clearer, improved perceived transparency, and avoided a potentially negative experience with the company.
For the public launch of the product, the planned partnerships were in place, meaning that instead of prescribing the test through a doctor, users could now pay for the test and receive authorization from a doctor (without having a telehealth appointment), which is a simpler and faster process. However, we knew we still needed to get the language right to be sure that users understood how the test was authorized, while being transparent/accurate and compliant with federal regulations. Additionally, customers needed to fill out a set of eligibility questions for the test to be authorized by the partner.
Public launch usability testing
-5 participants, all employees of the client company (though not on the product team)
-30-45 minute interviews (via calls on Teams)
-Participants were asked to navigate through a static prototype, narrating aloud their thoughts & questions as they completed specific tasks in the interface.
-Scenario A: You came across an ad for the T-Detect test on a social media site (Facebook)
-Scenario B: You clicked on the ad and reached this page (the patient page)—walk us through what would you do next?
In this round of testing, we aimed to test the usability of the following:
Initiating the payment process
-From the patient's page, can users navigate to the ordering section?
-Are the navigation titles clear?
-In the payment process, is the breakdown of services clear?
-Is the amount required to pay clear, and why?
-Are any costs surprising?
-How does the overall length of the questionnaire feel?
-Are any eligibility questions unclear?
-Is the interaction method to answer any questions unclear (within the limitations we can test with a prototype—ie. clickable button, checkbox, etc.)
-If a user is ineligible for the test, is the ineligible notification screen clear?
Confirmation and next steps
-Are the next steps the customer needs to take clear?
-Is the overall timeline of steps clear, including when the customer will receive their results and how?
After this round of usability testing, we made a few refinements— all outlined in the key findings deck. The key takeaways were generally positive:
Key changes made
Similar to the MVP round of testing, we suspected that language around the cost was not resolved ahead of testing. This is because additional options were added between the MVP testing and the public launch testing, and so the language needed to be updated.
Being transparent in pricing upfront, though scary to our stakeholders, allows the company to build trust with potential users. As the data shows, a perceived lack of transparency around the pricing caused users to be suspicious of what other information might be hidden and changed the user perspective of the company from neutral to negative. By refining the language around cost, we were again able to reduce the likelihood of negative experiences with the portal.
This was one of my favorite projects of my career so far because I learned so much and was able to dig into so many parts of the UX process—service design, UX/UI, and usability testing. Our team also worked closely with the development team to implement the designs, and because of this, I am satisfied with how the designs translated to the final product.
I was certainly challenged on this project—as this was a brand new product, we were designing the payment portal as the product and processes were still being developed. Additionally, changing stakeholders on the client-side complicated the expected deliverables and required our team to be adaptable and flexible.
Going deep on the project was exciting for an avid learner like myself—I’d like to work on integrated product teams again in the future.