Alto Onboarding Redesign
Date: 2020
Role: Design Lead, Project Manager
Project type: Product strategy, user research, user journey development, design systems
In Q2 2020, the Patient App team had an explicit OKR to improve self-service onboarding. The deliverable to achieve this (as outlined by the lead Product Manager) was an open-ended request to redesign the onboarding experience in three weeks. With no initial PRD, no defined user problem, and no user research to build on top of, we were essentially starting from scratch with this ambiguous request and ambitious timeline.
For Onboarding as a whole, the project consisted of two main sub-teams who were focused on each of the two core flows —Provider-Sent onboarding and Organic onboarding. In addition to being the Design Lead for this entire project, I was the IC for Provider-sent onboarding, the project manager for our cumulative four-week design sprint, and the DRI for overall design system development and cross-platform consistency (iOS, Android, and web, including responsive web).
To focus this case study on my direct contributions, the process below will focus on the provider-sent user experience.
Definition
USER PROBLEMS
Provider-referred patients don’t have context on who Alto is or what to expect before needing to engage in an onboarding process that is a new way to get medication, has multiple steps, and is a dynamic exchange between Alto and patient.
This results in multiple problems to address:
Some patient cohorts perceive the process as high-friction
There are several in-app drop offs between 10-40% (see image below)
40% of new patients drop off after Insurance and before Med List, which is Comms Preference or success screen (less likely to be the success screen)
9% drop off from viewing the web landing page (WLP; step 1) to Claim Account (step 2)
30% drop off after seeing the Med List (post-onboarding completion). CardFinder works about 66% of the time and 93% patients have insurance (60% manual, 35% photo), so is this a result of sticker shock? Lack of price (“price unavailable”)?
40% of new Alto patients call or text the Patient Care team after they receive an SMS text link about Alto and their prescription because they are immediately wary, confused by the 800-number, and want to know how Alto got their information
On average, it takes new patients 2–3 sessions to complete onboarding
BUSINESS PROBLEMS
Alto’s bread and butter acquisition model relies on providers (doctors, medical assistants, etc.) to pitch and refer prospective patients to Alto’s same-day, prescription delivery service. While this has proven successful thus far, it is also inconsistent and not dependable.
Network-level providers, like Stanford, don’t give patients any context on Alto because they refer all patients to Alto by default
Specialty therapeutic areas (TAs) like Dermatology don’t give context on Alto because it’s an elective service on top of an already elective treatment
The average provider has <90-seconds to give patients context on Alto
GOALS OF THE PROJECT
Create an intuitive and delightful onboarding path
Set context to build trust and appropriate expectations with patients for every step of the core onboarding flow
Motivate patients to complete onboarding in a single session by building on their intent to fill and giving a sense of agency
Educate patients on Alto’s core value props
Capitalize on the digital experience to meet patients where they are
SUCCESS METRICS
Primary metrics
Activation: RTS Comm → Self service first delivery
Onboarding Success Conversion: RTS Comm → Med list Viewed
Secondary metric (guardrail)
Retention: Self scheduling first delivery→ self scheduled 2nd delivery
Iteration
When we started this project, there was no PRD, no defined user problem, and no user research to build off of. Yet, we were tasked with redesigning onboarding across multiple platforms and device sizes (native, desktop, and mobile web) in three weeks. So, to start, I created a project plan working backwards from the initial deadline. The goal of which was to help provide some structure and organization to the cross-functional team of 2 designers, 1 user researcher, and 3 PMs. Eventually, as week one wrapped up, I forecasted ahead and advocated with the Lead PM and Engineering Manager to extend the deadline out an additional week so that the team wouldn’t be as burned out by the end. After getting their buy-in, in total, this was a 4-week project.
WEEK 1 // AUDIT & ASSESS
We kicked off this project by auditing the current onboarding experience and conducting some competitive analysis. To audit the existing experience, we ran a weeklong series of internal workshops with the Design team, the Patient App team (PMs, Engineers, Designers), cross-functional stakeholders (PMs, Engineers, Marketing, Specialty, and Operations). The goals of which were to identify strengths and weaknesses of onboarding, generate how might we (HMW) statements for opportunity areas, and reimagine a new onboarding experience using archetypes and empathy. Additionally, our user researcher conducted a social media audit of various reviews and posts to audit potential value props. Meanwhile, PMs ventured into Amplitude and Mode to gather any quantitative inputs.
WEEK 2 // CONCEPT & DEFINE
After our weeklong series of workshops and investigations, we synthesized workshop findings and HMW statements into a prioritized list, using a frequency/severity matrix. I also created a definitions framework to deconstruct the onboarding flow, seeing as what one teammate would refer to as “Onboarding,” another would refer to “account creation.” So, as a team and as a company, we all had varying definitions of what “onboarding” and “activation” meant.
Around this time, we also discovered some anecdotal executive feedback that onboarding wasn’t quick enough. This contrasted with some previous user research, and immediate user feedback to our Operations team that users didn’t know who Alto was or whether they should trust us. So, using these two perspectives as opposite extremes, we decided to run some user research. To reduce internal bias with each concept, we codenamed the user trust-oriented flow as “Marvel,” and the speed-oriented concept as “Fast & Furious.”
Given the short timeline of the project, we chose to run 60 unmoderated sessions using UserTesting.com, leveraging click-through prototypes and structured questions to glean quantifiable metrics. At Alto, hard numbers are more important to the executive team as opposed to qualitative feedback. Additionally, for the prototypes, we leaned into making these mobile web-focused designs since two-thirds of new users onboard via mobile web. To continue momentum, we also kept iterating on potential UX flows to consider.
WEEK 3 // TEST & ITERATE
We ran the UserTesting test over the weekend, and our amazing user researcher synthesized the findings in two days.
Using these results as huge inputs into our overall thinking, we continued to iterate on wireframes and flows, narrowing in on a final direction by the end of the week. To build alignment and understanding of what the PMs and designers had been doing, we also had a UX review with Engineering so that we could gauge feasibility.
WEED 4 // UI DESIGN
Moving into the final week, we moved straight into UI design for native (iOS-first) and web (desktop and mobile web). Our primary design goals were to:
Leverage existing components
Identify and refine any legacy components so that we could evolve our design system
Define new interaction patterns that were respective of each platform (e.g., using action sheets for native and dialogs for web)
Infusing more of the Alto rebrand, and updated tone of voice
Maintain cross-platform UI consistency
We also worked with our wonderful Marketing partner to develop new copy that was conversational, welcoming, and as brief as possible given the nature of health information. Below are the final designs for the Provider-Sent onboarding flow, for native, desktop, and mobile web.
Implementation
Post-design, it took our team of 5 engineers 6 weeks to implement the mobile web and desktop versions of the Provider-Sent onboarding flow (native mobile was deprioritized). These flows were implemented as part of an A/B test, just to ensure that the new experience wasn’t performing below the existing baseline metrics.
During implementation, I wore the hat of Design QA and collaborated very closely with Engineering to review and comment on PRs, iterate on missing or unclear designs, and advocate for brand, UI, and design system consistency across both the Provider-Sent and Organic onboarding experiences, and across platforms.
RESULTS
In terms of success, the new Provider-Sent onboarding experience increased both of our primary metrics.