User onboarding isn’t a feature

This article originally appeared on HelpScout.

I’ve spoken to many companies about their onboarding experiences, and I often hear them enthusiastically tell me that they finally got onboarding on their roadmap and plan to roll it out soon. I cringe a bit when I hear this.

Weird, right? For someone who is way into user onboarding, wouldn’t hearing that there’s more of it coming out be music to my ears? It’s not, unfortunately, because it’s a huge indication that the company is approaching onboarding the wrong way.

User onboarding isn’t a feature of your product like a new dashboard or fancy partner integration, but time and time again I see product teams treating it exactly as such—something that’s designed, launched, and eventually neglected.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

This is problematic, because onboarding isn’t a discrete piece of your product; it’s an evolving quality of your entire customer experience. Treating it as a shippable feature is fundamentally the same as saying, “We’re finally going to ship Support in Q2. We really think we nailed it this time!”

Onboarding Is Not “Set It and Forget It”

When people “ship onboarding,” it typically takes the form of a walkthrough UI spackled onto a pre-existing interface that was never really designed for getting people up to speed in the first place. And once the team has shipped the walkthrough, onboarding goes onto the back burner for another year or two before the entire process is repeated.

To make matters worse, the onboarding feature roll-out is often lacking something that all other features get: user research. Often, the needed onboarding changes will already be “obvious” to everyone because, “we already know what’s wrong with our signup flow.” Even if that’s true, stapling tooltips to a broken workflow isn’t a permanent solution.

User onboarding is not about pointing
out the bad parts of your interface;
it’s about more reliably delivering
more value to more signups.

Addressing the latter is significantly more important than deploying some walkthrough code and calling it a day.

So how do you generate real improvement to your user behavior and avoid baking internal assumptions into a core part of your long-term product experience?

Getting Users to Do the Right Things

Before you jump into designing a new onboarding flow, figure out what you should be getting people to do in the first place. Only then should you spend time designing the user experience.

• Are you sure that having someone upload a photo is highly correlated with that person successfully adopting your product?
• Does naming the first project really kick things off on the right foot?
• Is email address confirmation actually required before anything else?

Onboarding tends to fail when you simply line up a bunch of stuff for people to do without knowing whether that stuff directly increases the chances they will find ongoing success. New users can run around on a wild goose chase inside your product just fine on their own; you don’t need to build a machine that helps them do it.

So if getting signups to become successful is the criterion for quality onboarding, then how do you define “success” to begin with?

Onboarding Isn’t about Setting Them Up—It’s About Getting Them Back

While the definition of a “successful user” will differ for every company, there are very, very few products out there—especially in SaaS—that won’t have “keeps logging in over time” as one of its main determining factors.

With that in mind, the process of finding the high-value activities in your product becomes a lot more straightforward: simply identify the actions your signups take that correlate with more of them sticking around longer.

If you have a 14-day free trial, seeing the things done by the people who make it to 15 days or more is going to be very interesting. Ditto for people who have made it past the 30-day or 90-day survival mark, regardless of whether you have a trial. In fact, another parameter to use (and a very simple one, at that) is “only the users who have ever logged back in a second time” (by the way, prepare to find that percentage to be gut-punchingly low).

Once you have your survival criteria in place, you can begin to find some very interesting connections.

Finding the Recipe for Your Users’ Success

When it comes to identifying the actions that highly correlate with long-term retention, one of my favorite reports to run is as follows:

• Make a list of what you think your high-value actions are (in this case, guessing is totally fine, unlike cementing said guesses in years-long interface changes).
• Create a cohort of users who match your survival criteria and another cohort of “everyone” (e.g. September signups who made it past 30 days vs. all September signups).
• Identify the percentage of users in each cohort (successful users vs. everybody) who have completed each action and how long it took them to accomplish those tasks.

This should give you a clear picture of the kinds of things the successful users are very likely to do that the average signups aren’t. At the very least, it should show you very clearly where you are losing the most new users. You can keep repeating this with more and more user actions until you find a very clear trend in differing behavior.

This is what I call finding your successful user recipe.

The actions that successful users do that average ones don’t are very likely to be what drives long-term value for both you and your signups.

That’s what you should be building your onboarding experience around.

Be careful, though; correlation does not always mean causation. If you find that successful users are much more likely to file support tickets, for example, it doesn’t necessarily mean that’s a valuable exercise for everyone. It’s probably because those users are the most intrepid and would have converted either way, not that you should railroad everyone towards contacting your support department. (Though I’m sure your support reps are very nice.)

But what if you don’t have a ton of new signups generating lots of data to report on, or—gasp—you aren’t tracking user behavior at all? Never fear! If the quantitative approach doesn’t apply for you, there’s always the qualitative one!

Going Qualitative

A couple years ago, I was running Customer Success for a B2B SaaS company. We weren’t getting thousands of signups a month, but each customer had a really high lifetime value, so every single one of them was precious.

The product culture there was very much “all new features, all the time,” which made getting even minor UX updates to the existing product a significant challenge. Overhauling the onboarding flow was completely off the table. So instead, I became the onboarding.

How? I’d literally watch every single step taken by every new signup, often in real time. If a new user got stuck at a certain point, I’d wait half-an-hour or so and then send them a personal message directly from my inbox offering help: a pointer, a link to a reference doc, an open time in my schedule to jump on the phone and/or set up a screen share, etc.

The screen shares were my favorite, because that’s where I learned the most. Instead of sharing my screen, I’d have them share theirs and let them run the show, up to and including the point where they’d turfed out. This would provide invaluable insights about what people were trying to do and what was preventing them from doing it.

I’d turn the “why they turfed out” observations into UI bug tickets, but even more important were the notes I’d take about what they were trying to do in the first place. The product had a lot of different use cases, and the more time I spent on the phone with real live customers, the more I picked up on the most frequent usage patterns and the commonalities that all signups shared, regardless of what they were trying to accomplish.

This is the exact playbook I would recommend someone follow before diving into an onboarding redesign project. Learn so well what people are doing that it almost becomes boring to you, then use that knowledge as your onboarding sequence. That is what you design your onboarding flow around. If you want to build a skyscraper, you’ve gotta dig a deep foundation!

Shipping Happens Once, but Iterating Is Forever

Actually, that skyscraper metaphor may be a bit off. Once the concrete has set, the builder’s job is largely done, and that’s the exact opposite of the point here. Landscaping is probably a better comparison to draw: consistently observing, pruning, and adapting your user environment.

If you think of onboarding not as pointing out the weak parts in your interface, but instead as the holistic approach to delivering more value to more signups, then it becomes extremely clear that your onboarding experience must keep pace with the evolution of your product and the evolution of the market it serves.

Slapping on some tooltips and feeling like you’re covered will not serve you or your new users very well at the end of the day. Through data or a white-glove approach (preferably both!), find the things that get people not only over the hump of learning your UI, but accomplishing what they originally set out to do.

Instead of burdening the user with even more workload and buttons to click, learn what the quickest path to value is and adapt your experience around it. After all, it’s not about getting people to do more things, it’s about getting them to do the right things.

Read Next: Lifecycle emails: Magic pixie dust for user onboarding