Batman Onboarding
Getting rid of onboarding wizards
User Onboarding is a big topic right now. No matter if it’s about sign-up flow, a great first-run experience, or making the user familiar with new product features on an ongoing basis, it feels like many people are now aware of the importance of a good user onboarding strategy. Although I think a good first-run experience is very important (“What happens right after sign-up makes or breaks any web product”), I don’t like the typical onboarding wizards you see in webapps these days.
What’s wrong with onboarding wizards?
Don’t get me wrong, there are many great onboarding solutions out there. However, I usually see the same mistakes being made. Here’s a few things why I think user onboarding is often done wrong:
1) Introducing all the features: There are so many onboarding wizards that try to explain the whole product. Most of the time the user should only experience one key feature, the “Aha!”-moment of the user experience. Introducing everything at the same time means most of the features are actually introduced at the wrong time. More confusing than helpful.
2) Not based on user behavior: The user has only one chance to be guided through the onboading flow: right after signup. So people who just want to play around and discover some features close the wizard immediately and don’t know how to get back when they really need to be guided through the product. Why not introducing features as the user needs them?
3) Too much friction: Very often onboarding wizards are not a part of the core user experience, it’s just a layer on top of the product. To me as a user, this doesn’t feel right.
4) People want to be in control: Having no choice in the first steps they’re taking is obviously not a satisfying first-run experience.
In my opinion, a first-run experience should be unobtrusive and never get in the way of people figuring things out on their own. An onboarding wizard should not even be seen. But it should be there when it’s needed. Like Batman.
Let’s look at an example of what I call Batman Onboarding.
Example: Slackbot
Slackbot is a nice little companion inside Slack, a team collaboration tool that recently got a lot of love. He (let’s assume he’s male, he has sort of a masculine face in the profile pic) is part of the team in Slack and just introduces himself in a nice way. The great thing about slackbot is that he shows core functionality of Slack (chatting with team members) without friction, but by experiencing the feature. It’s basically just a funny guy you can chat with.
Slackbot asks for information that is not necessarily needed, but that could enhance the user experience later on. Notice how he communicates the benefits (“to make things easier for your teammates”) and how the user is always in control about which information she wants to share. It’s very unobtrusive, the user never has to reply. And, on top, slackbot also introduces product lingo in a funny way:
Slackbot Batman Onboarding
“The signal goes on and he shows up. That’s the way it’s been, that’s the way it will be.” ― James Gordon
OK, so slackbot is introducing the chat feature and other things by being funny, unobtrusive, and also possibly enhancing the future experience by getting nice-to-have data the user might not be willing to share otherwise. The really great and Batman-like thing about slackbot, however, is the following:
Perfect! They noticed some behavioral changes in my team (increasing activity) and figured (or know by actual user data) that people can get quite annoyed by too many notifications. So they let you know in a really nice way by this little guy you’re already familiar with. No friction, super simple.
Stay out of people’s ways, but be there when you’re needed. I think more people should do Batman Onboarding.
(image taken from here)
