3 Onboarding Principles To Help You Design For Human Beings
(1) → This means “check out footnotes at the bottom of the article”.
Onboarding is an art the same way that building a freeway tunnel is an art — it takes a ridiculously long time to make perfect so that people can barrel through it at 80 mph without getting lost or crashing in the hopes that they might get on to other things that have nothing to do with it.
There is a lot of information on the internet about onboarding, UX best practices, and user psychology, most of which is able to put a brand new spin on how the average product team should look at their designs. The following post is a collection of my personal learnings about getting users from point A (signing up) to point B (repetitive usage) without complaining or closing their browser window.
(For context, I work at HubSpot as a software engineer focused on “new user experience”, analytics, and experimentation.)
Before we dig in, there are three things to keep in mind:
- Onboarding must not be stupid.
- Onboarding must generalize, but also not.
- Onboarding is a Really Cool Dad.
It will make sense soon. You’ll have to trust me. Ready?
Part 1.
Onboarding must not be stupid.
Humans have a tendency to be repulsed by the feeling of “being stupid”. So much of what we do every day is an attempt to avoid the the feeling of stupidity — “stupidity” meaning “loss of control” or “lack of information” or “embarrassment”. This is part of the reason why we, as humans, are pretty bad at predicting the future. We are hardwired to make decisions on an emotional level (every decision is finalized in the limbic system) instead of a logical one.
In product development land, the user is not stupid and aggressively refuses to feel stupid.
You know who is stupid? You, according to the user.
When it comes to onboarding, there are two places where stupidity can creep into the experience:
- Friction points (“I feel stupid”)
- Obvious, intrusive information (“Do you think I’m stupid?”)
Businesses in the wild are fairly good at finding the first stupidity-trap by using analytics tools like Google Analytics, Mixpanel, KISS Metrics, and Localytics to build funnels. Funnels are a great way to identify points of concern in your flow.
What funnels don’t do is tell you why the friction point is a friction point (raw data is terrible at giving you “why”). It’s your job to discover the reasons for drop-off and address them appropriately.
While making funnels is pretty straightforward, it’s a lot harder to find the parts of your product experience that users find annoying but not annoying enough to be blocked from completing tasks. The reason these interactions are important is because small annoyances build up over time, resulting in statements like “we use it every day, but we are really hoping to find another system that is less of a pain in the ass”. At the moment, analytics can’t measure poetic saltiness (1).
Intention and irritation live completely within the sphere of human emotion, so it goes without saying that talking to people is the best way to uncover which parts of your onboarding (and inevitably, your whole product) that are making your users cringe.
Send blast email campaigns for feedback. Do one-on-one user tests. Make your co-workers in another department walk through a flow you are concerned about. Or, perhaps, break out the alcohol:
The more your users are talking, the more you are listening to subtle feedback (2) and the more you are able to pinpoint the things you thought were a good idea but were, in fact, not.
TAKEAWAYS:
No one likes feeling stupid. Use analytics and user tests to find friction points and unnecessary instructions.
Part 2.
Onboarding must generalize, but also not.
It’s impossible to build software without generalizing. If you have CRM software, you may assume that your users work in the style of a traditional sales-rep/manager team. If you have a social media mobile app, you may assume that your users all have thumbs and can use their eyes to absorb information. If you are Adobe, you assume that your users are industry professionals who don’t mind going through hours of training in order to use super-powerful creative tools.
Generalization is important in design because building features and flows for every possible combination results in interfaces like this (among other things):
However, going back to the Adobe example, there is a huge difference between “opening the aperture” and “designing for personas”:
Onboarding is a game of mapping personas to an experience:
- How do users view their time? Do they ever have time for anything?
- How much experience will users have using similar tools before using yours?
- Do users expect that they will need to take time to train themselves on your product (like Adobe), or do they expect instant gratification (like Snapchat)?
- Do users think of your product as a utility or entertainment? (3)
Get to know your users so well that it makes you sick. Become obsessed with tweaking and updating your personas to display commonalities among the majority of your users. Personas work best when they reflect generalized actions in relation to your product (“looks for possible integrations on day one”) as opposed to generalized properties (“drives a mid-sized sedan and drinks black coffee”).
When your personas are explicitly built from the point of view of their interaction with your product, you’ll begin to generalize in ways that make more sense when connecting the dots to UI design decisions.
Let’s work with behavioral personas:
Pretend for a moment that you have an iPhone app that records phone calls and saves them. After some observation, you find yourself with three groups of users:
- Users who try to record a test call on the first day.
- Users who dive right in and record their first call the next time they remember they have the product installed.
- Users who install and never record their first call.
Using these generalizations, you can begin to create an onboarding experience that addresses the hangups in each:
- When they user installs the app, show “press ‘#*#’ to start recording a call” on the zero-state screen. Without recordings, this app is pretty useless.
- Add a user-initiated flow that verbally prompts a user to record and play back their recording, similar to Skype test call.
- Start a flow for when you start a recording in-call. It skips directly to doing the recording as not to interrupt the user’s call, and then prompts them to go to the location of the newly recorded audio after they hang up.
- After the first few days without usage, a reminder plays while the recipient’s phone is ringing that you can “press ‘#*#’ to start recording this call”.
These are ideas that I improvised in a few minutes, but it was really easy to generate best-fit flows for each persona. What you’ll notice is that these flows are all able to exist in the same space without competing for attention.
How to find behavioral personas:
Onboarding design works best when you ask first and test second. You can quickly build these personas by watching people use your app in real life or by installing a screen-recording tool. Ultimately, you’re trying to replace the helping hand of a human being with the humming and awkward beeping of a computer.
Allowing the onboarding experience to be more fluid, like the example above, brings the rigid, static computer a little closer to being like the reactionary, dynamic human that it’s trying to emulate. A human instructor knows what information to start with, is able to see when you struggle with a task, and can see when you might need reminding. A human instructor also reacts correctly to statements like “yes, but not right now” and “I’m not listening”, which computers are incredibly bad at.
TAKEAWAYS:
Develop personas specifically for the point of view of onboarding by generalizing user behaviors. Use tools like in-person user tests and screen recording to find these behaviors. Challenge yourself to rearrange your onboarding steps or to skip steps without breaking the experience. Your users will inevitably follow their own path.
Part 3.
Onboarding is a Really Cool Dad.
Here is a graphic that I’ve seen taped up around the office this year:
The idea is that you shouldn’t be selling the features of your product but instead what the user will become when they use your product (things like “a badass” or “a superhero” or “not sad anymore”).
In the context of onboarding, you can see how the following WunderMap overlay is an example of what not to do:
However, imagine I change all of these tips to be a little more focused on the user by adding some humor and by addressing the user directly:
While these tips are much more entertaining, they now don’t serve the purpose that they were originally meant to serve: education which leads to repetitive action (4). I think the guides from Samuel Hulick are brilliant. Like many things, however, this Mario graphic should be taken with a grain of salt.
Sometimes you shouldn’t sell at all. Sometimes you need to be a “cool dad”.
A “cool dad” — via my own made-up definition — is a dad who lets their kids do whatever they want, but (hopefully) puts the guardrails on when their kids are about to make a poor decision. Cool dads also give their kids plenty of praise when they deserve it.
If you think about the metaphor of parenting, a father might have to provide a lot of guidance when their child is very young, but their child will quickly attempt to gain some independence. When their child doesn’t agree with their rules, they cry and scream in Chipotle. When your users don’t agree with the rules of your product, they think about churning.
Strive to be a “cool dad” (or “cool mom” or “cool parent” or “cool guardian” or whatever you like best) when designing your onboarding flow. Set the tone, get the required info, then get out of the user’s way unless they need help. Throw in some high-fives and balloons when a user hits milestones. A well-designed UI goes a long way when adhering to this philosophy.
The reason that users don’t retain or take action, in many cases, has nothing to do with being convinced. Convincing a user to make big leaps is why a marketing team exists, and also why so many products have usage limits baked in which require upgrades to increase.
Onboarding doesn’t need to include a sales pitch. Selling is “convince me to go to the playground”. Onboarding is “now that we’re here, push me on the swings and please tie my shoes before I trip on them”. Let users have fun on the playground with their friends instead of pointing out all of the different swings and slides for a half hour.
TAKEAWAYS:
Avoid giving a sales pitch. Be empowering as you lay down flexible, but specific, guardrails for your users. Be a “cool dad”. Give users enough info to get moving on their own, only chiming in when giving praise or getting them un-stuck.
Footnotes
- Sounds like a good startup opportunity
- .…but not, of course, everything they say.
- It’s possible to have both eventually, but the onboarding experience needs to address the problem being solved in the early moments of use. Facebook is a utility. Netflix is entertainment. Snapchat is a utility. Farmville is entertainment.
- What this might do, though, is set a better tone for the user who thinks they are about to use a boring weather utility, like how Blendtec is making blenders fun.
Geoff Daigle is on the growth team at HubSpot. You can find him on twitter at @dailydaigle
