Mindstrong: Members Enrollment

Project Background

As Mindstrong continued to evolve, the registration experience was, however, lagging behind. While we were committed to protect our member’s protected health information (PHI) and personally identifiable information (PII), the steps to get registered and onboarded were convoluted and complicated.

As a designer, it’s my job to solve complex problems and identify opportunities for product improvement that align with our OKRs while driving value for our members. 

Problems

When new or existing members opened the app, they were presented with options to sign up or log in. However, the signup and login flows led to the same experience asking members to provide their phone number without any prior context. 

The logic was messy and often led to new accounts being created for existing users who were trying to log in, as well as new users not being directed down the appropriate login path. This resulted in higher sign-up drop-off rates and increased hours of our Member Support team hand-holding our members through the process.

Approach

I held multiple work sessions with our stakeholders including engineers, PM, Member Support team, clinicians, and regulatory in order to understand design and product requirements. These sessions helped me to uncover many prior assumptions that were without proven data such as the notion of making the sign up and login flows the same in order to appear simple for users. 

Data from Amplitude showing click events also helped identify where the drop-offs occurred and areas with minimal interest or interactions. 

From the work sessions, I was able to come up with a new user flow that I proposed to the team.

Implementation

In the new user flow, we aimed to solve most of the friction points that were mentioned. We removed unnecessary steps and the informational landing screens that were shown to not receive any traction so that users can get to the Sign Up screen faster.

We also created a clear visual distinction between Sign Up and Log In flows and streamlined how and when information were asked as we learned that our members could easily get confused.

Although we weren’t able to remove the dead-end completely at this stage of the business, we made sure to move it up earlier in the flow so that potential new members didn’t feel like they had wasted too much time and effort in the process.

Welcome screen: In the Before version, users needed to click Get Started to get to the Welcome screen before users can see Sign Up button.

In the After version, the informational screens were removed. The app then opened to the new welcome screen prompting users to log in or sign up. The buttons’ positions were also updated to show better information hierarchy so that the primary and secondary call-to-actions were the Sign Up and Log In buttons.

Sign Up screen: In the Before version, when users clicked Sign Up, they were asked to enter their phone number. Users weren’t given any context on why. To further add to the confusion, if the users clicked on Sign In, they would see the same screen.

In the After version, we deliberately made the design and the presented screen different than the Log/Sign In screen. Only necessary information that was needed in creating an account was asked. Zip Code was also brought up earlier in the flow.

Log In screen: In the Before version, when users clicked Sign In, they were asked to enter their phone number. Users weren’t given any context on why. To further add to the confusion, if the users clicked on Sign Up, they would see the same screen.

In the After version, we updated the phone number screen to provide more context to users. We also made it explicit to the users that they would be signing in. If the users clicked Cancel and returned to Sign Up, they would be able to see a completely different screen asking for their information to create an account.

Graceful Error: In the prior version, we didn’t really have any graceful error or helpful error messages. This left both the members and our Member Operations (mOps) Team frustrated as it became more effort to pinpoint what caused the error.

As part of the enrollment process improvement, we knew we had to provide this piece of support, not only because providing graceful error was part of our design principles but also because our members and our mOps team really needed it.

In the example shown, if members entered an incorrect phone number or one that didn’t exist in our system, they would be shown a screen with that information and options to remedy the situation such as an option to try again or an option to call support.


How we landed

Success:

About 25% improvements in our download to pair conversion from 50% to 67%.

To improve:

  • We found out that there was a big drop off right after the users entered Auth Code even after they have completed the sign up form

  • The current flow still causes a half signed up state where users are stuck in limbo, can't find them in Care and are unable to follow up as leads

  • We still need to further improve and decouple the enrollment & registration process

  • Sign up & Sign in labels are potentially confusing to members. We updated Sign in to “log in” and moved the login button position on the Sign up screen

Previous
Previous

Case Study: Design System

Next
Next

Web App: Conversica Training Desk 2.0