New user onboarding turns signups into successful users as quickly and easily as possible. Done well, it generates excitement about future use, provides learning by using the product, and takes care of basic configuration in a fun and engaging way.
As a designer on the Atlassian Growth team, one of my responsibilities is coming up with these onboarding flows for us to test in our products. We run A/B experiments to determine what ideas will increase various success metrics like conversion, monthly active users (MAU), and usage minutes.
Popularised by consumer products like Facebook & Twitter and the work that Samuel Hulick has been doing, user onboarding is taking the product design world by storm. It seems every startup in the valley is focused on delivering an incredible onboarding and setup flow to beat all others, all in the name of increasing MAU.
However, I believe if a product is intuitive by default it should require no onboarding flow at all. The days of RTFM are gone; the best products don’t require hand-holding to understand core functionality from the get-go.
Which begs the question, what makes a product intuitive?
A whisk is a steel instrument. A bowl is a concave surface. A chicken egg is the unfertilised gamete laid by a female bird.
This is listing and describing features. Instead what you need to do is show your customer how she can make an omelette. (Thanks to Jay for the great metaphor.)
If you haven’t heard of the Jobs-to-be-Done framework from Clayton Christensen, I suggest you check it out. In short, customers ‘hire’ your product for a job they want done, and you need to succinctly communicate how your product will do this job for them.
In the example above, our customer is after an omelette, so you need to provide not just the tools and ingredients, but also the recipe so she gets what she’s after.
Do you introduce a lot of bespoke terminology? Are you using words which most people associate with a different definition? Unless you’re Apple, you probably can’t invent a new word or change the definition of existing words.
We have a product called Confluence which is a collaborative wiki and knowledge base. It’s kind of a hybrid between Google Docs, Wikipedia, and StackExchange for your company.
Everything in Confluence lives within multiple ‘spaces,’ kind of like folders on a computer. The problem with the word ‘space’ is that it’s incredibly abstract and has many different definitions. Customers trialling Confluence are confused when they encounter it, so our onboarding flows spend a lot of time explaining what we mean by the term.
Terminology like Share, Menu, Project, and Avatar all have distinct definitions within the context of software (and associated well-known symbols). When people interact with these words or icons in your interface, they expect one thing and are confused when you show them something else.
Ensure your definition and usage is the same as what people expect, and try to use as little bespoke terminology as possible.
“An affordance is often taken as a relation between an object or an environment and an organism, that affords the opportunity for that organism to perform an action. For example, a knob affords twisting, and perhaps pushing, while a cord affords pulling.” — Wikipedia
Put simply, affordances are the things your users interact with. Buttons, gestures, drop-downs, inputs.
We have a Breville toaster and a Breville microwave at home. One thing I love about the toaster is this ‘A bit more’ button:
This button is neat because it explains what it will do in a simple and human way, it is physically a button that can be pressed, it looks like a button differentiated against its surroundings, and it has a ring light that shows you when it’s on. It’s quite straightforward and simple.
Contrast that with our Breville microwave:
What’s the difference?
The affordances on the toaster are clear and intuitive. I know what they’ll do; I don’t need a manual to tell me. The microwave on the other hand is interface voodoo: a myriad of bespoke icons on the display, inconsistent long presses and short presses, a multi-function contextual knob, and complex button labels. What does Time Weight Defrost do? Or the button simply labeled Microwave? It even has an oddly-specific, dedicated Potato button! Why? Does anyone cook potatoes in their microwave?
It sounds obvious but it’s often overlooked: make sure your product has intuitive affordances like the toaster, and not the microwave.
There’s an old computer science saying that a computer should never ask you a question that it can answer for itself. In most cases your product should be able to determine a lot of configuration on its own; for example the user’s timezone and location.
In the case of new users, you absolutely know that people don’t start with their own data in your product. When you create a new email account, it usually doesn’t come with a bunch of emails in your inbox. Your users will be looking at a lot of blank screens. Make sure you have well-designed empty states or sample data to catch them and highlight their next steps.
For times when the product can’t easily know how to set itself up, rely on qualitative research and analytics to inform your default configuration.
If you know most people have four steps in their workflow, the default column count on your task management app should be four.
If you know most of your audience are signing up to design a newsletter, surface that above other options, like designing a birthday card.
If you know most people are using two of your products together, perhaps connect and integrate them both by default.
You have the ability to affect a potential customer’s expectations before they log in for the first time: you control the advertisements you run, the content on your marketing website, the emails you send, and what you post on your Facebook page.
So if you’re saying one thing on your marketing website (“our product is great for thing x!”) and then don’t follow through in-product, you’re going to lose that customer because you’ve built up their expectations and then demolished them.
How do you begin to address this?
Conduct an audit of your whole customer journey from initial impression right through to success (whatever that is) and make sure you’re sending the same consistent message about what your product does the whole way through.
This exercise is also a great way to surface differences of opinion in your organisation. Your marketing department might think your product does one thing well, whereas the product managers might disagree!
You now have a good base for making your product intuitive. Once you feel that you’re satisfying most of the points I’ve outlined here, start iterating on the new-user onboarding experience through experimentation to further optimise each of these points.
But if you’ve been nodding your head the whole way and saying, “yep, our product isn’t here yet”, then perhaps go back to the drawing board and aim to make your product more intuitive by default before throwing everything you have into new-user onboarding experiments.
A/B experiments are useful for turning a good product into a great one through iteration, but not that useful when your product has a long way to go before it’s somewhat intuitive. Make sure you’re starting off at a certain level before iterating through experimentation, and remember, the best onboarding is an intuitive product by default.
Benjamin Humphrey is a designer at Atlassian. If you enjoyed this post and want more of the same, you might consider following Designing Atlassian! This article first appeared on Medium.
