The app stores have millions of wonderful apps available, including yours. But despite of that, the average smartphone user tries out new apps only a few times a year and there is a chance of about 70% that he uninstalls it anyways.

The user’s decision of keeping or uninstalling your app, is based on his first experience with your mobile app. Therefore that first experience, the user onboarding process, should be flawless.

What is user onboarding

Different companies tried to define user onboarding. In short, you could say that: “user onboarding is a process of introduction to get acquainted with the benefits of your service and try it. This is important for users to become engaged and return to your service in the future.” This sounds nice, but creating that process and make it work is easier said than done.

Goals in user onboarding

If you know what goals your user onboarding has to achieve, it is easier to design that process and test if it meets these goals. By investigating different apps and hearing different experts, it became clear to me that there was no standardized approach for this. There isn’t even a model. So I took the liberty of creating one.

 

 

I called this model the ‘6 onboarding ingredients’. It actually shows the different goals any user onboarding should pursue: authentication, personalisation, explanation and education, guided first-time use, showing the benefits and marvel.

They are placed on a matrix with a X- and Y-axis. The X-axis shows the purpose of the ingredient for the user. It ranges from feeling to facts: “should the user be left with a feeling, or know about some facts?” The Y-axis shows the purpose of the ingredient for the app. It ranges from system to skills, to sense: “should it set up the system, make the user more skilled or should it intrinsically engage the user?” Combining these two axis results in the six ingredients.

 

Authentication

‘Setting up the system’ and ‘knowing facts about the user’ come together in authentication. When a new user enters the app, he has to be authenticated to be able to use it. It is like verifying the ticket before entering the amusement park. This can be done volatile: just register the ID of the device on the background and let the user continue, or it can be done extensively: executing a two-step authentication with something that the user has and something that the user knows (for example: phone number and password). In some situations an app can be entered anonymously, but as soon as the app has some kind of ‘ personalisation’, authentication is needed.

 

Personalisation

The purpose of personalisation is the feeling of the user; it feels exclusive to have the app adapted and optimized for you. It causes a relationship between the user and the system. Dan Kosir confirms that. He says the more personalisation the app offers, the higher the chance that the user keeps using the app (Dan Kosir, 2017). Practically, personalisation is ‘adjusting the system’ to the preferences of the new user.

 

Explanation and education

Almost every app has its own jargon or certain abstract concepts that the user should know about. But the new user doesn’t have that knowledge or skills in the beginning and has to be educated. The app is completely new to him, after all. The app should enlighten him from a helicopter view, but also on a detailed level. Tell him what the goal of the app is, but also how that is integrated in the different features. The purpose of this is based on ‘facts’ that the user has to know about. It contributes to making him a skilled user.

 

Guided first-time use

The best way to make the user have a positive first-time experience of the app, is by letting him play with it for a while. Let the user explore the app and its features in a safe environment. At this moment you can help the user by introducing certain buttons and menus or giving real-life examples. By making these steps very easy and impossible to fail on, the user will feel like a winner. Even when he has no skills yet. That is why this ingredient has the purpose of ‘feeling’ for the user and the purpose of ‘skills’ for the app.

 

Showing the benefits

Another important ingredient in the onboarding process is getting the user to know the benefits of the app. “The quicker users find and understand your product’s core value, the more likely they are to eventually become enthusiastic, profitable customers.” (Jackson Noel, Appcues) But there is more to this than just telling the user what the benefits are. Make them understand how your app is an improvement of their life. “(…) you earn their engagement by making them b etter people, not simply by making a better product.“ (Samuel Hulick) The purpose for the user is to know these facts. For the app this ingredient contributes to engaging the user by his sense of the app.

 

Marvel

Last but not least, onboarding is also about amazing the user; being that one app that stands out between the others. Marvel is not just showing your USPs. It is about having that one little extra thing; the easter egg that some users tend to find interesting and others maybe won’t notice. Achieving this marvel is hard, because there is no roadmap to it. One way though, is to have a unique design, a smart solution to a problem the user had for many years or have your app working on a special device that nobody developed anything for yet.

 

Design your recipe

A good onboarding experience consists of all these ingredients. But it can be that, for example, the app needs more authentication, because the app uses confidential data (example: cryptocurrency app). Or if the app is very complicated, more first-time guidance and practise is needed (example: Google Spreadsheet). If the app has to fully adapt and get to learn the user before it is fully operational, personalisation will take more time (example: StumbleUpon). It’s up to the designer what implementation – or mixture – works best for his application. Below is a table of a few popular tools and the different do’s and don’ts of experts on them:

Do’s Don’ts
Tutorial screens / modals Use static tutorial screens upfront to give the user some context. To explain the benefits of your app instead of the features. (Babich, 2017)

Add a “skip the tutorial” option to static tutorial screens for experienced users (Babich, 2017). You can also make users opt-in at the beginning, instead of opt-out. (Countly, 2016) (Inline Manual, 2017)

Restrict the amount of screens to three. (Satia, 2014)

Don’t make a static tutorial of many screens  upfront. Users don’t like the cognitive load. They want to use your app after installing it, not learn about it. (Babich, 2017)“They have signed up for a service, not the tutorial.” (Saxena, 2017)

Don’t make them too long to read. Users won’t be interested in it and will look for the close button immediately. (Inline Manual, 2017)

Interactive tour Provide a interactive tour with proactive guidance. Take the user by the hand and walk through the main workflow of the app together, providing explanation where needed. (Babich, 2017)

Make sure a walkthrough is focussed on one specific task or workflow. (Inline Manual, 2017)

Steps should be very easy and directly rewarded. (Zichermann, 2011)

A successful onboarding process has the following pattern: action, reward, action, action, reward, join by registering. (Zichermann, 2011)

Don’t make these tours too long. Users want to accomplish something, not only play and see demo’s. (Inline Manual, 2017)

Make sure the user cannot fail at the tutorial. (Zichermann, 2011)

Setup wizard Offer registration/account creation options via social login as well as email. (Countly, 2016)

Show progress bars and checklist on what the user did and has to do. It is engaging, because “it capitalizes on the psychological need for closure.“ (Countly, 2016) (Saxena, 2017)

Avoid a complicated and extensive account creation / sign-up. (Countly, 2016)

Don’t require the user to create an account before using the app. (Countly, 2016) (Satia, 2014) “Doing so gives more incentive to the user to complete the signup process.” (Saxena, 2017)

Coach marks / tooltips Show a mark at the time the user needs that explanation (Babich, 2017), at a specific screen of your app. (Inline Manual, 2017)Only hint at primary features. (Babich, 2017)Make hints short and to the point. (Babich, 2017) Don’t show multiple coach marks at the same time. The interface is new to the user and is forced to read many tips, without any context from experience. Even tips in a row (one-by-one) have the same effect. (Babich, 2017)  (Inline Manual, 2017)

Don’t explain obvious things. (Satia, 2014) (Babich, 2017)

Empty states If there is no content to show yet, add a fun guiding hint on how to get started. (Satia, 2014) (Babich, 2017)

Give a visual hint of what the page will look like when there actually is content. Tell the user how to achieve that. (Babich, 2017)

Don’t show empty pages when there is no content yet. It confuses the user and doesn’t provide guidance on what to do. (Babich, 2017) (Countly, 2016)

When to start this?

The onboarding of your app should suit your case, your user and your story. Even more, depending on the nature of your app, it is even recommended or discouraged to
include an onboarding process at all. Germaine Satia and Nick Babich both came up with indicators when an app needs proactive onboarding. Indicator 2 and 5 are also pointed out by the company Apptimize.

  1. It contains non-standard interactions (uncommon gestures as primary method of interaction).
  2. The app’s default state is empty. It requires the user to populate it with data (sometimes personal data users still have to collect with help of the app).
  3. The app is part of a bigger suite of products. (explanation of this part of the suit and the bigger picture is needed).
  4. It has a complex system or workflow of tasks (many user roles with different access rights, many actions).
  5. The app undergone a major redesign and new features and changes has to be introduced.
  6. It contains a brand new concept that might be unfamiliar to users and should be explained.

 

Leave a Comment

Het e-mailadres wordt niet gepubliceerd.