Onboarding Redesign Exploration


When

September 2016 - November 2016

my role

Principal Designer. I was the sole designer for this project soliciting feedback from our design team at our weekly critiques. In addition I organized and ran all the UX research conducted during the project.


Introduction

While in our all-hands meeting in during one of my first couple months at Netpulse our Support team was presenting their monthly ticket breakdown and it surprised me to learn that our onboarding process and login flow was responsible for 50% of the tickets received each month, so around 1,700 tickets. With a business cost of $5 per ticket we're looking at around $8.5k a month that we're spending on the onboarding flow alone. I decided to do some more digging on the onboarding flow and learned the following:

  • We were asking for push notifications up front, right after a user had opened the app for the first time. This resulted in 80% of our user base having denied push notification permissions. This means that to recover those permission we would need those users to go into their settings menu and re-enable them. So 80% of our user base was "deaf" to any notification that we sent. To add to this our flagship add-on products (Referrals and Feedback) were going to rely heavily on push notifications to function. Selling these add-ons to the gyms was the big business bet that Netpulse was pursuing, after those sales were made at best we would only have 20% of our user base to target.
  • Dropoff for our onboarding flow was at around 70%. So only 30% of those who opened the app made it to the dashboard.

This signaled serious problems with the flow. What did our onboarding flow look like? What was causing these dismal numbers?


Research

When digging into how we handled sign in and onboarding I learned about the importance that Member Management Systems (MMS's) play in onboarding. An MMS is the third party that handles customer billing, customer class booking, etc, it's the true identity system for any gym member. Several of our features need to communicate with the MMS, for example if you book a class or purchase a personal training package through our app we need to verify and then pass that onto the MMS so that it's tied to your account and the gym's software. At the time of this research (February 2016) we were integrated with 3 of the major MMS's in the fitness industry. With plans to expand to many more, by the time I left in April of 2017 we had 7 integrations. 

Each MMS handles user identification differently, what this meant for us is that for each MMS we had to have a different onboarding flow since they each require different bits of information to verify a user. Below are the three login flows we had laid out.

Surely there must be a more elegant way to handle onboarding. But at the time myself and the other PD's were overloaded with projects, onboarding redesign, however dire it was needed, wasn't even on the roadmap. So a myself and another PD asked ourselves, how can we make a case to this on the roadmap? We decided to look into what a better way of doing Onboarding could look like with the goal of presenting our findings to the executive team and the product team. 


Re-architecting the Flow

After work and on weekends (the other PD at Netpulse and I are roommates which made things easier) we began work on the product principles we could leverage to re-architect the flow.

The role of MMS

We needed to begin by rethinking what role the MMS plays in our onboarding of users. The way we were doing it, regardless of where a user may come from, whether they just signed up at the gym, or whether they're coming into the app via a guest pass the MMS information was the lock that they'd be faced with upon entry. We can't control what information the MMS requires of the user, and unfortunately it was usually several input fields, some of which weren't easy for our users to access.

 

When we look at which of our features actually require an MMS verification to work, it turns out to be very few of them. You can absolutely view a schedule of classes without authenticating to the MMS, only if you want to book a class do you need to authenticate. You can browse the personal training catalog without authenticating as well. We went through all of our features and identified which ones, and at which point  you would need to be authenticated. It became clear that instead of using an MMS as a gatekeeper to our entire experience we could backload it, and only ask for authentication when it was needed.

proposed flow.png
 

give & take

The table to the left shows all of the information we ask about a user, this is all before they get to the dashboard and can start interacting with our features. The best onboarding flows give as much as they can take, they spread things out where they can and only ask for what they need when they need, providing value to the user as quickly and frequently as possible.

 

 

double permission modal

When we bring up a system permission modal (notifications, calendar, etc) and a user denies it, the process to get them to re-enable those permissions is tedious and requires them digging through the settings app. We rely heavily on Notifications (class reminders, guest pass invitations, etc), Calendar access (booked classes/PT), and Location services (class list, check in, etc) so to have a user deny us severely limits the capabilities of our product. The first step was to move our permission requests to happen in the right context, for example after a user books a class to attend asking them if they'd like to add it to their calendar.

The second step is to implement a pre-permission dialogue, popularized by Cluster, it involves bringing up a modal that asks if they'll give us access, if they say yes, then we bring up the system access modal, if they say no we dismiss the modal but at least we don't get denied and can make it easy for us to ask for access at a later time.

 
 

stickiest action

A big goal of the onboarding flow is not only to get a user into the app, but to demonstrate value and get them to come back as quickly as possible. Our onboarding flow at this point was asking a lot of information from the user, and then dumping them on a dashboard with a dozen tiles of features they could interact with, without providing any guidance. What we needed to do was to get a user into the dashboard but then encourage them to engage in an action that would make them more likely to come back.

When digging into the data we learned that our users who had connected one of their devices and joined a challenge were 3x more likely to come back, and those that had set a fitness goal 2x more likely. So those two provided us a good starting point, and we came up with some mockups as to how we would implement this.

 

magic link

 
magiclinkhoriz.png
 

First popularized by Slack, "Magic Links" allow us to flip the current onboarding process on it's head and greatly simplify it, it's an incredible elegant solution, here's how it would work.

Currently:

  1. Member buys a gym membership (usually in person at a location)
  2. We have to rely on the gym's salesperson/marketing initiatives (if any) to inform the member that there is an app available for their gym.
  3. Member has to go into the app store on their own, download the app.
  4. Member has to sign up for the app, remembering their member ID, and several other pieces of information they were given upon purchasing the membership.

The Ideal:

  1. Member buys a gym membership
  2. Their account is automatically created in the MMS, we pull that information from the MMS and automatically create an account for them in our database.
  3. We text the member a direct link to the app in the app store, deeplinking their information.
  4. They download the app and are automatically logged in.

Presentation to Product & Executive Team

This work culminated in a presentation to the full product and executive team. They loved the work and research that we did and many of them commented on the fact that from both a business and product perspective this is one of the most pressing thing we need to address.

At the time however, we had Feedback, Dashboard 2.0, Find a Class and several RevGen features that were underway, these were to fill up our design and engineering bandwidth for the rest of the year and unfortuneatly Onboarding Redesign never got picked up.

These are the slides I used in the presentation, I'd be happy to talk over them in person.


Read this next: