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.

Alto’s existing mobile web onboarding experience.

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

Existing onboarding funnel, showcasing % drop off between steps.

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.

Sample Miro board from a weeklong series of workshops.

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.

Definitions framework that deconstructed the makeup of “onboarding” and “activation.”

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.

UX flow concepts with Fast & Furious and Marvel highlighted at the top.

User research concepts to test—Marvel and Fast & Furious.

WEEK 3 // TEST & ITERATE

We ran the UserTesting test over the weekend, and our amazing user researcher synthesized the findings in two days.

UserTesting results compiled by my user research partner.

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.

Proposed and aligned on UX flows for Provider-Sent and Organic onboarding flows.

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.

Final native mobile UI for Provider-Sent onboarding. One-third of new users onboard via native mobile.

Final mobile web UI for Provider-Sent onboarding. Two-thirds of new users onboard via mobile web.

Final desktop UI for Provider-Sent onboarding.

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.  

5% improvement in activation (RTS comm → First delivery scheduled).

12% improvement in onboarding success conversion (RTS Comm → Med List viewed).

 

Next
Next

Rethinking Fitbit's Future Software Vision