Ready to build better conversations?
Simple to set up. Easy to use. Powerful integrations.
Get free accessReady to build better conversations?
Simple to set up. Easy to use. Powerful integrations.
Get free accessHaving a ‘solid’ user onboarding experience on a SaaS product is particularly important. First because most SaaS users try a new software in the hope of finding a useful tool that’ll make them more productive (usefulness vs fun). Second because they generally try it during “work” time, meaning that they cannot lose too much time understanding how it works. Third because the SaaS landscape starts to be really crowded and chances are high that your user has many other options available if he doesn’t understand the value you deliver in less than 5 minutes.
The 3 aims of a product onboarding
Onboardings are generally useful for:
explaining the concept / most important features of a product
engaging the user to complete important “configurations / setups”
avoiding the “ghost town” effect when the user arrives on the interface for the first time
Getting Started
This is probably the most obvious goal of a product onboarding: an onboarding is here to clearly explain what your product is and what a first time user should know in order to get started.
The challenges
As “obvious” as this aim sounds, it’s not that easy to craft a good “getting started” process. Explaining clearly the value that your product delivers and how it does can be quite complicated.
Here are some common problems:
You want to explain ALL existing features. The more features I show, the more my users will be impressed, right? Yes, but no. The aim of an onboarding is not to explain every single thing that your product can do but to make the right choice of showing enough so the user can get started and later, if he is hooked, to show him the “power user” features. Too many explanations can be confusing.
The onboarding lacks context / story. The “getting started” part of your onboarding process shouldn’t simply be a collection of feature explanations that you display one after the other. You should create an onboarding scenario and make the user complete it as if he was following a user story (“Ok now I’m using this because it helps me do that”)
The onboarding is polluted with too many irrelevant “call-to-action”****. Very often you’ll find product onboarding which ask you to share on Twitter, Facebook, Linkedin or to connect your gmail contact book without any reason. So, yes you can ask users to share or connect stuff but only if it’s useful for the user experience. Not because you think it’s the right moment to get as much information from your users as possible.
A good way to avoid these problems is to organize your features into different categories (“core features”, “power user features”…) and to limit yourself to the ones which have the potential to “hook” your user. Your product is like a drug, once your user is hooked he’ll come back to you and as any good drug dealer you’ll be able to make him discover more features later.
Concerning the “format” you’ll find many examples of great user onboarding experiences on useronboard. The options are endless: video tutorial, interactive step-by-step onboarding, passive tutorial (only explanations), active ones (the user has to perform actions in order to go to the next step) etc. You’ll also find many tools that will help you create these “step by step” tutorials like mytips.co, walkme or directly on GitHub.
When designing Aircall’s onboarding, we struggled a lot with all possible features we could show: customize your messages and music, play with the cascading order of your call forwarding, import and share Google contact, collaborative features, etc.
The best onboardings we’ve seen were when the product itself showed the user how to use it. Slack has done an awesome job here.
So when a new user arrives we first emphasize the simplicity and speed to set up an Aircall number using 5 super-simple popins like “What’s your company name?”, “Who will take the call on this number?”.
Then for the rest of the features we decided to show to the user real “life” examples directly within the product. For example we create right at the end of the onboarding a 1st voicemail on the user’s number with some extra tool tips. We also create a first “virtual” contact (Lisa, our Support Diva) that we place directly into the user’s contact list, so he gets to see how contacts work and that you can add comments on them.
Completing ‘installations / setups’
This is an aspect which is strongly bound to SaaS products: having the user to install / set up a component before he can use the product.
Examples :
to install a javascript snippet on its website (ex: Google analytics, Intercom…)
to modify its DKIM and SPF to improve email deliverability (ex: Mailjet)
to create a phone number (Aircall)
to connect a third party service to retrieve data (ex: seo tools which need data from your web analytics)
…
There are two cases: the setup is compulsory (analytics tool) or it’s not but the user experience might not be perfect (DKIM / SPF setup which you don’t need in order to send emails but which are important to avoid being considered as spam).
In either case, as these setups are crucial, the onboarding stage is a very good time to ask your user to complete them.
The challenges
The end user and the person who can complete the setup are not the same**.** Typically the case for analytics tools: marketers are the users and they cannot install the javascript snippet themselves.
This is a VERY hard problem on which a lot of SaaS struggle. How can I onboard a user if he cannot use my product “out” of the box?
If the setup is not “compulsory” then you can still let the user enter and try your interface but you should keep reminding him that the user experience will be optimal once he’ll complete the steps required (reminders via emails, in app notifications etc…)
If it’s compulsory then you should really think about a strategy to lower the friction as much as possible.
Intercom has a quite interesting (and radical) approach as they ask you upfront if you can do the setup yourself or not. If not, you need to provide the email of the right person to contact.
Ultimately the question is “can you provide this minimal value that will hook the user without having this setup completed?” if yes, then allow him to enter. If not, then you should think about it.
The setup requires time. This is, for example, the case for a tool like Monitor Backlink. Once you’ve connected your Google analytics account, the seo tool takes 24 hours to analyse all the links and crawl them back. During this time you can use the dashboard but the experience is not optimal. Same thing for Mailjet. A DKIM / SPF change is generally not taken into account immediately and the user has to wait a couple of hours before he can send its emails.
You can still offer a “normal” onboarding here. The key is to make your user come back when its interface is ready.
Concerning Aircall we basically pre-configure many many things under the hood during the onboarding process and we inform the user only at the end of it that he can customize what he needs. That leads to a 5-step process (not that short :-)…which only takes on average 60 secs to complete and at the end of which the user gets an active phone number, cascading across various people and devices etc.
The ghost town effect
The “ghost town effect” concerns a wide range of SaaS: collaborative products, which are really useful only when your colleagues are also using it (ex: Yammer, Front, Slack), products collecting data (analytics, predictive sales tools…) which get better with more data, products relying on “contacts” (CRM etc.), and is simply the fact that some SaaS need data or other team members in order to be really useful from the start.
Since the user experience can be deceiving without it, the onboarding stage is generally a right moment to ask the user to act on it.
Challenges
There are three main challenges here:
making this data “retrieving” seamless: it should be as automated as possible and the user shouldn’t spend time entering this data or inviting other users “by hand”.
convincing the user to add his company data before he has even seen the product
convincing the other users who have received an invitation to click on it
Populating a product with data “automatically” has only gotten better with the years. Now SaaS makers can leverage a wide range of APIs in order to retrieve data and fight the “ghost town” effect. From the user’s social profiles (Twitter, LinkedIn, Facebook…) to data stream between apps (Google analytics API, Gmail API, SalesForce API, your phone contact book…) with a few clicks you can really enable your user to import a huge number of different data sets.
No, the real difficulty is to convince a first time user to click on that “invite my colleagues” button which will give you access to his gmail contacts. Unfortunately there is no magic bullet. It’s a mix of “brand” building (the more a user knows / trusts your brand the better) and of constantly reassuring the user about why you ask for this data and how it will be beneficial for him later on. The benefits you promise should exceed his fear.
Concerning invitation emails for other teammates the secret is to test as much email subjects and text as possible in order to discover what works for you.
Intercom has several great articles about these topics.
One onboarding to rule them all?
Another interesting challenge worth mentioning is the “admin” problem.
Very often SaaS products have two types of users: admins and regular users. These two types of users generally have the same set of core “features” but they also potentially see different interfaces, have different needs and perform different actions.
You can end up creating two different onboardings and these two onboardings can be both crucial for the success of your product.
For example on Aircall only admins have the right to create phone numbers. Regular users don’t. It’s a really important aspect of the product for this category of people (you want to choose the type of phone number, its location etc… and understand it from the start) and hence is really taken into account in our admin onboarding. A normal user won’t even see it.
Onboarding people with “voice”
These are all challenges we face and that we are trying to solve ourselves. We put a lot of effort iterating on this part of the product and we’ve already modified it quite a bit (we could see some real improvements on our metrics, so it’s definitely worth working on this aspect).
We’ve gone from a simple “static” onboarding for our MVP to an active step-by-step one shortly after and for our latest iteration we are trying a “voice” onboarding: users can choose to be guided through voice explanations.
We really don’t pretend that we have nailed it and that our onboarding is perfect (far from it). We just thought that having been through all this process it would be worth sharing our thoughts and learnings with the community.
As we are also experiencing with a new kind of “voice” onboarding we would love to have your feedback and see how we can improve it, so don’t hesitate to try it and tell us what you think.
Published on July 24, 2014.
