Designing a great user onboarding process requires a deep understanding of who your customers are, why they want your product, and what they want to do first.
But you already know those things, right? Even still, it can take a lot of testing and many revisions to get this process tuned.
To help you get started, I examined 50+ tech companies in the SaaS space to see how they onboard their users. I looked at different types of products: end-user-focused, development tools and analytics. Let’s see how they compare.
Your first priority should be showing users how to do exactly what they signed up for. Otherwise they’ll be less likely to take the next step.
Give people what they want.
The following companies understand that serving their customers’ main need first is crucial. Keep in mind that what works these products might not work for you—the same principles will apply, though.
This is what the first screen looks like when setting up a GitHub account. They tell you exactly how to start and what steps their guide will walk you through.
Don’t want to follow the guide? No problem—the New repository button (same color as Get Started) shows you another way to get started quickly.
GitHub’s guide is actually just a page out of their core documentation—something you can bookmark and return to. This method might better suit their audience than using a step-by-step walkthrough of the interface with tooltips that disappear. (But those can be great for other types of products!)
When a user signs up to create an store, they probably have products to sell. Etsy only asks for the minimum amount of information needed to setup a shop, so the user can breeze on through and get to stocking their online shelves.
Another great part of Etsy’s onboarding experience is that they focus on what the user needs exactly when the user needs it. Unless you have products ready to publish, who cares about setting up a payment method?
Billing is the last step in the setup process, and—at that point—it’s the only thing stopping a user from publishing their store. Being able to publish your store is a much bigger incentive to configure payments than being able to add your first product.
The product helps you create a hosted status page enabling you to communicate with your customers about uptime and and outages that have occurred. StatusPage.io does a good job of helping users hook up data sources, brand their page, choose which metrics they want to display when presenting uptime history.
This is another great example of doing things in the order of importance:
Before inviting team members or customizing outage message, start by connecting your data sources. After all, without a data source, the app wouldn’t know when or which outage messages to send.
Twilio starts you out by choosing a type of message to send. A user then proceeds by choosing a number to send the message from—but as a new user, you don’t have any Twilio numbers. So they present you with the option to buy a Twilio number.
As easy—and tempting—as it would have been to make Buy a Twilio number the first step, by waiting, the user gets to clearly understand why they need to buy a number and how it’s going to help them.
Keep things simple by offering more later.
Keeping the first steps simple for products with multiple feature sets is crucial. Being able to do this effectively is really an art and Groove does a great job of it.
Despite having many useful integrations, website plugins, and a knowledge base, Groove keeps the Apps section hidden away until they’re needed.
A knowledge base is a very common feature of a customer support product, but Groove’s primary focus is to make it super easy and enjoyable to answer your customers’ questions. They wait until you’ve gotten the hang of tickets before suggesting adding another feature to the mix.
There was one product I tested that appeared to start with the core feature, but before I even got to use it, they asked me to install a second feature. At that point, why not just install it by default and save the user the step?
Give the taste of what it might be like.
For products that require any data to be collected or would otherwise take a lot of work to setup, providing samples or a mocked up project can be very helpful.
A lot of companies who do a great job of this. Here are a few examples.
One of Wistia’s key value propositions is video heatmaps. Those can tell you how long viewers are watching your videos, where they drop off, and what they rewatched. It’s all very helpful, but could be hard to understand without a proper example.
To combat this, they provide a sample heatmap which explains what the different colors mean and how to read them effectively.
They also solve the time-consuming setup issue by offering a sample video for you to try out their other features with. After all, you might not have your latest video handy or your internet connection might be slow making uploading a nightmare. My hat is off to you, Wistia team!
For a product that is infinitely versatile, Trello does a great job of introducing the tools that are at your disposal without showing one specific use case.
In fact, they have tons of demo boards that you can look at to get ideas of your own. Planning a wedding? They have a sample for that. Setting up a Scrum board? They have another example for you.
Of all the products I tried, Trello was the king for showing different use cases without showing you endless tooltips of features.
Groove (yes, again)
I’m not a fanboy—they just did a terrific job!
When you sign up, there are support tickets waiting for you to read and answer. They help you practice different features like replying and closing tickets.
A sales CRM is very dependent on you having contacts and deals loaded.
Close.io includes a few sample customers and messages with the CEO himself—yes—that you’re asked to respond to and interact with.
Don’t leave out important details.
While you might have answered every question a new user would ask upfront, there might be a few steps that are crucial to make the user truly successful.
I’m not talking about profile completeness or inviting a team member, though. This might seem like an obvious point to make but there were a few blunders that left me confused:
- Tell the user when something goes live on the web. Multiple products failed at this.
- Don’t take the user away from the app to sell another part of your product line… yikes.
- For analytics tools that take time to get data, tell the user once they’ve set everything up so they don’t keep poking around the app while waiting for records to come in.
- If your app requires embedding a snippet of code, tell the user if your are not getting signal from the code. Include a note saying how they might fix it.
- Do you only accept certain file types for uploads? Tell the user before they even try to select them.
- Ask users how they want payments handled if they’re receiving money. Don’t mess with your customers’ cash!
- Focusing on providing alerts or notifications to your users? Explain how to set them up during onboarding.
Unless you absolutely need a user to confirm their email in order to grant access to their account, don’t make them take additional steps.
Lower the barrier.
It’s okay if you want users to confirm their email eventually, but don’t make it the barrier to entry.
I know a few of you reading that just felt your heartbeat start racing so let me explain. There are cases when you should definitely require confirming an account before granting further access: risk of malicious use, fraud, or sensitive information being exploited.
The only product among the ~50 I tested that had a valid reason for requiring me to authenticate my email address was MailChimp. Without that, MailChimp would be opening the floodgates to email spammers—even though their other security measures would keep it in check.
There are ways to go above and beyond.
Localize timezones, languages, and currencies by IP address if you didn’t request the user’s location. Just like Harvest does:
Acknowledge if a browser isn’t compliant.
Detect the operating system in order to suggest the proper native app.
If your app requires embedding a snippet of code, acknowledge when the embedded script is sending data to your product successfully. Mixpanel does this right:
How apply this to your product?
While none of the examples will be a silver bullet for all products, you should be able to take the principles and find ways to apply them in yours:
- Identify the first thing a user might need to do when signing up.
- Start simple and offer more features later.
- Give them a taste of more complex features by providing tangible examples.
- Make sure users know all the crucial steps for success. Don’t assume they’ll figure it out on their own.