Healthy onboarding
For the best experience, we needed user data. But first we had to show value and build trust.
I consulted with a health tech startup—referred to here as Being Health—on creating an onboarding flow for new users. Their platform leveraged data from thousands of medical centers to find patients big savings on doctor visits, medications, and even overcharged medical bills.
For this particular flow, new users would be offered the Being Health benefit by their employer. They would receive prior communications about the program, and then Being would send an email allowing them to sign up and claim the benefit.
The email would then direct users to the Being web app, where they could complete the sign-up flow.
The most important thing during this process was to make sure users connected their electronic health records. This is what allowed Being to look at their medical history and offer savings.
We knew we had two challenges:
People like their privacy. They’re not just going to hand over their data without knowing they can trust us.
People are busy. Another task to do, coming from their employer, wasn’t on their list. The value we offered had to be clear.
The very first piece was the onboarding email. If folks never click through the email, we’re not getting them signed up.
The goal for the email was to establish trust through security, as well as reputation—showing what we’ve done for other users.
I also wanted to show specific examples of how users could save—whether that be medications, procedures, or Being fighting an overpriced bill for them.
Once users go to the website, they are prompted to create an account. We only ask for the minimum amount of information possible to capture their profile, because people are inundated with these flows. I also use this as an opportunity to reinforce product value and assure users we’re protecting their data.
For Being to work properly, users must connect their health records. I again use examples of Being’s features to show the value—users could save money on meds, doctors, and bills.
If users choose to skip this step, there’s a confirmation screen making it clear that without this connection, the biggest value add of Being isn’t available.
We also offer them the opportunity to connect with a Being nurse, whom they have already had contact with through their employer. This way, they’ll have guaranteed help the next time they try to connect their records.
If users continue with the connection, they are presented with a list of medical institutions, as well as a search field with a clarifying prompt, “Where does your doctor practice?”
After they choose an institution, we explain that they’ll temporarily leave Being to sign in to their patient portal. We also reassure them that their data is protected through HIPAA-compliant encryption.
Once the user has signed into their patient portal, they are directed back to the Being web app. Here we provide a confirmation and give users an example of what to expect, which is text messages sent directly to their phone. These messages only send when we find savings, so they’re not bombarded with useless notifications.
Users also have the option to connect other patient portals, or they can go to the Being dashboard, completing the onboarding flow.
We shipped the onboarding experience, and waited to see how users would react.
Initially, we saw good adoption from the email link. Twenty percent of those who received the email created an account. Out of that 20%, half of those users connected their patient portal, resulting in a total utilization of 10%. Comparatively, that figure was double the industry standard of 5%, and we were able to consider this a success!
While it’s important to recognize successes, we also realize big potential for improvement. We are still losing half of interested users because they aren’t connecting their health records.
Users click set up later, and even though we offer help through our nursing team, it puts too much responsibility back on the user to follow through.
We know from human experience that passive help isn’t really that helpful. It’s like when someone is going through a hard time, and we say, “Let me know if there’s anything I can do to help.” When someone is struggling, it’s too much to process.
So, we anticipate user needs, and put the responsibility back on Being.
Now, when users click Connect Later, they are prompted to schedule a call with a Being nurse. And by embedding a third party scheduling software, we are able to schedule those calls while users are still excited about the service.
The beauty of scheduling is:
Users with time constraints still get to set it up later (for real)
Our nurses are guaranteed to be available
It’s in the books—even if they forget about it, we won’t
Users still have the option to exit the flow and go to the dashboard, but we remove the responsibility of initiating the call, making them more likely to get help.
When Being launched this update, we heard great anecdotal feedback from users about how it alleviates the burden of proactively setting up the service. Over the next few months, I hope to share quantitative data about the the success of this change.