The main role of your app’s first screens is to get your users genuinely believing that the app will make their life better in at least some small way. I wrote previously about how the top consumer apps make clear promises to the user and then start delivering on them immediately, getting the user taking action, doing something valuable, in the first few screens.
But even for the top apps — even for the ones with the most compelling user promises — the user will, at some point, run head-on into a whole bunch of screens that are going to feel like, well, work.
Every app has some form fields for the user to complete, some phone permissions to request, some terms and conditions to display.
Now, if the user really wants what your app has to promise, they’ll battle through these more mundane steps. At least for a while. Place too many obstacles in their way and even the most interested user will get fatigued and find something else to do with their time.
How do you counteract this and maintain user engagement through your app’s onboarding flow?
Looking at the top consumer mobile apps — those that already have huge user bases and those that are getting there fast — we can see some common patterns in how they take users through onboarding.
The top apps …
- … show users how far they’ve progressed through onboarding (and how much is left to come) ⌛
- … use transition screens to get the user excited about what comes next ⏩
- … ask the user for phone permissions at the right time and with a good reason 🤳🏼
- … show the user just how much people like them have benefited from the app 🙏🏽
I’ll cover each of these in turn.
1. The top apps … show users how far they’ve progressed through onboarding (and how much is left to come) ⌛
A user doesn’t know, when they open an app for the first time, how long the onboarding flow will be. They usually expect some onboarding. They expect a sign-up form or two, but they don’t know what else they’ll get. Will it be just a couple of screens and then they’re in the main app, all set up and ready to make the most of it? Or will it take much more than that?
Apps can manage this process and remove this uncertainty. They can give the user a sense of accomplishment by highlighting how far they’ve come. And they can manage the user’s expectations by showing them how much is left.
WHO DOES THIS WELL
PayPal, Shine, MyFitnessPal: comprehensive and continuous progression indicators
Showing the user how far they’ve progressed is particularly important for longer onboarding flows. The more steps there are, the more chance that the user will, at some point, wonder whether it’s worth continuing.
PayPal, meditation app Shine and diet tracker MyFitnessPal all use progression indicators to situate the user within their onboarding flow. Each of the apps have a significant numbers of steps (6+) in their onboarding flow, all of which are covered by the progression indicator. While each step is easy enough to complete, knowing where they are in the flow reduces the chance of the user getting fatigued and dropping off. (And, especially, dropping off right when they’re getting to the end of onboarding.)
Knowing how far they’ve come — and how much they have left — helps give the user energy to continue. “I’ve already done that much, may as well go on” and “I’m so close to the end, I’ll be there in no time”.
Discord: checklists to group related (and important) actions
Progression indicators, like those used by PayPal, Shine and MyFitnessPal show progress across steps. Each step appears to contribute equally to achieving the goal of getting the user onboarded.
Discord adds granularity to specific steps. The app groups related actions together and uses an “activity checklist” to measure progress towards — and incentivise completion of — these actions. Activity checklists work particularly well when there’s a small, set number of actions to complete. And when these actions, collectively, comprise a specific part of the user’s onboarding.
Discord uses a checklist with three actions to walk users through setting up their server. Tapping any of the uncompleted actions — like “invite your friends” — prompts the user to complete that action, with limited effort required.
Discord keeps the checklist visible until it’s complete, even as the user browses down into their server’s channels. This keeps the user focused on these important onboarding actions, while giving them some freedom to explore the app.
WHO DOES THIS NOT-SO-WELL
Pinterest: a false ending
A user opening Pinterest for the first time might think “brilliant, only 3 steps and I’m in”. After answering three questions, a loader spins and … another question. Well, actually a permission request obscuring another question.
With the app failing to live up to the expectations it set (of a quick onboarding), the user might disengage. More questions. And this second set of questions doesn’t have a progression indicator, so there’s no indication of how many more questions there are to come. Just more.
The user is likely less certain of their progress than they would have been if no progression indicator had been shown at all.
Fabulous: am I getting anywhere?
At 20+ screens, habit-building app Fabulous has a pretty long onboarding flow. It (mostly) manages to maintain the user’s interest through concise, user-centric copy and beautiful, varied UI. But as the user reaches the middle of the onboarding, they’re hit with a series of questions that require a bit of thought and introspection. After 3 or 4 such questions, the user might well be thinking “Just how many of these are there?”.
Some sort of indicator or checklist would help maintain momentum for the user. Even something as simple as a note beforehand on how many questions are coming up. 7 questions probably sounds manageable to most users. And it’s certainly far fewer than their worst expectations might be when they’re staring at question 6 with no clear end in sight.
KEY TAKEAWAYS:DO:1. Show the user comprehensive and continuous progression indicators. Especially if you have a many-step onboarding flow. (Like Paypal, Shine, MyFitnessPal)2. Use checklists to group related (and important) actions. Checklists work particularly well where there's a small, set number of actions to complete. And when these actions, collectively, complete a specific part of the user's onboarding. (Like Discord)DON'T:1. Create false endings. Don't set expectations for the length of your onboarding that the app won't live up to. (Like Pinterest)2. Rely on the user to get through on their own momentum. Any user wondering "am I getting anywhere?", as they answer a series of questions with no clear end in sight, is a user at risk of dropping off. (Like Fabulous)
2. The top apps … use transition screens to get the user excited about what comes next ⏩
It’s unavoidable that some of your onboarding flow is going to be less engaging for users. Even the most dynamic apps end up asking their users to complete relatively prosaic steps. Like setting a password or opting in/out of marketing emails.
Transition screens are an opportunity to counteract any dip in the user’s engagement. These screens are an opportunity to remind users why they are there and rebuild momentum for the remaining steps of onboarding.
WHO DOES THIS WELL
Headspace, Nike Run Club, Fabulous: splash screens that reinforce the app’s promise
I wrote in part I of this series about the importance of making a concise, ambitious promise to the user. Those promises are (primarily) delivered through short, punchy sentences that tell the the user how the app will improve their life in some way (however small).
An app’s splash screen (which the user sees immediately on opening the app) is an opportunity to reinforce this message.
Fabulous and meditation app Headspace show subtle, calming animations on the splash screen. They set the tone for both of these apps and build expectations for what the apps will deliver.
Nike Run Club uses a series of still images showing groups of runners in urban settings. These aren’t professional athletes, but they are serious runners, running together, having fun.
In each case the apps signal to the user: “here’s what’s coming. Are you ready for this?”
Wakeout, Spotify, Reddit: celebrate even small successes with the user
Every step of onboarding that the user completes gets them closer to the promised land — to the better life that the app has promised them. Every step presents an opportunity for the app to both recognise the user’s actions and assure them that they are making progress.
Spotify provides a simple but clear celebration. The app congratulates the user on the great musical choices they just made (while their personalised feed is created in the background).
Micro-exercise app Wakeout pairs a rainbow-trailing unicorn (naturally) with the reassurance that everything is all set for the user. They are, they are promised, going to stay “active, energized and healthy” — all they need to do is click ‘continue’.
Reddit also assures the user that they’re getting to the good bit. And it reinforces the app’s tone with a cute/quirky dancing dog GIF. Who wouldn’t be excited about what comes next?
Duolingo: reward the user for the progress they’ve made
When the user finishes their first language lesson (as part of their onboarding), Duolingo turns the celebrations up to 11. High fives, muscles, lightning bolts, flames. It’s all there.
But it’s not just celebrations. Duolingo uses this opportunity to introduces concepts like ‘combo bonuses’ and ‘streaks’. It introduces the rewards system that becomes core to the app experience as the user continues their lessons.
It would be easy to look at this and think that these celebrations and rewards are out of proportion to how far the user has progressed so far. But that’s not how it feels as a user. For the user, they’ve overcome whatever obstacles (time, fear) was holding them back and have made the first step in learning a new language. They may have made only a little progress (so far) in the app, but they’ve made real progress in life. That’s something to celebrate!
(And, more simply, how often in life do we feel people over-celebrate and over-reward our achievements? Rarely right? It’s much easier for an app to err on the side of under-celebrating and under-rewarding the user’s achievements than the other way around.)
Fabulous: get the user saying “yes!”
Fabulous stops the user at key points, actively interrupting the onboarding flow to get the user saying “yes! This is what I want”. It uses a classic “foot-in-the-door” technique. It asks the user to make small commitments at first, then escalates those commitments as the user progresses through onboarding. This helps the user maintain momentum through what is, as mentioned earlier, a long, intense onboarding flow. The user is more likely to continue through the flow if they’ve just (a few screens ago) committed to continuing.
(This approach is particularly helpful for apps, like Fabulous, which are building up to a big commitment from the user. It asks the user to pay— or at least start a free trial — at the end of the onboarding flow.)
WHO DOES THIS NOT-SO-WELL
It’s hard to highlight specific failures in this area. Very few apps use transition screens, but then execute them poorly.
But we do see many apps miss the opportunity to use transition screens to counteract a dip in the user’s engagement as they go through onboarding.
KEY TAKEAWAYS:DO:1. Use splash screens to reinforce the app's promise. Signal to the user: "here's what's coming. Are you ready for this?". (Like Fabulous, Headspace, Nike Run Club)2. Celebrate even small successes with the user. Recognise the user's actions and assure them that they are making progress. (Like Spotify, Wakeout, Reddit)3. Reward the user for the progress they've made. Introduce and get the user started with any rewards system you have in the app. (Like Duolingo)4. Get the user saying "yes!". Ask them to make small commitments at first, then escalate these commitments as the user progresses through onboarding. (Like Fabulous)DON'T:Miss the opportunity to use transition screens to get the user excited about what comes next
3. The top apps … request phone permissions at the right time and with a good reason 🤳🏼
Phone permissions can play different roles for different apps. They can be absolutely critical for an app to function (location permission in a maps app, camera permission in a video calling app). They can be useful shortcuts for the user to complete key onboarding actions, without being essential for the app to function (contacts permission in a social app). They can be semi-useful for the user but a key part of the app’s activation and retention strategy (notifications permissions on a lot of apps).
In each case, the app gains a lot of value by getting permission from the user to access certain aspects of their phone. But the user can sometimes be skeptical. Everyone has heard stories of apps accessing more user data than they need to (and then, in the worst case scenario, losing this data in a security breach).
Requests for phone permissions need to be well timed and well justified to reduce the risk of slowing the user’s momentum. To reduce the risk that the user will pause and consider whether they really need to grant permission. Or, worse, that the user will decline a permission that’s essential for the app to deliver what it promised.
WHO DOES THIS WELL
Snapchat: clearly tie permission requests to user actions
Snapchat requests multiple permissions as the user goes through onboarding. It spaces out the requests, so they don’t become overwhelming, and attaches each to a specific user action.
The OS pop-up requesting access to the user’s contacts is triggered by the user finding friends on the app. The request to access the camera is triggered by the user creating an avatar. The request to access the microphone is triggered by the user creating their first snap.
Tying it to the user action makes the permission request (somewhat) expected. And it positions it as being in the user’s interest, rather than the app’s. Granting the request helps the user make progress in the app, quickly.
Wakeout, Strava, Nike Run Club, Duolingo: prepare users before requesting phone permissions
These apps explicitly warn users before requesting notification, location, camera, microphone or any other permissions. They explain why the app is requesting permission and why granting it will benefit the user.
These ‘permission primers’ fit the app’s UI style, blending into the screens the user has seen throughout onboarding.
Permission primers are particularly important if the permission request is not triggered by a user action — when there is nothing that the user is trying to accomplish right now that requires the permission.
Towards the end of its onboarding flow, Wakeout asks the user to allow it to send them activity reminders. Once the user hits “Allow”, the OS pop-up appears, asking for permission to send notifications.
This is an important permission for Wakeout. It needs the user to allow notifications so that it can send them a message when it’s time for their next exercise. It’s an important permission, but there is no obvious user action that could have triggered this request.
Strava and Nike Run Club show similar permission primers to the user as they request access to location and health data, respectively.
(In both cases, it is possible the app could have used a user action to trigger the permission request. They could have triggered the request when the user wanted to start their first run or, in the case of Strava, their first cycle or swim. But that may not have been a great time (just as they are about to jump into a swimming pool!) to ask the user to stop what they’re doing and pay even more attention to the app.)
Duolingo leaves nothing to chance. It ties its request to send notifications to a user action and prepares the user for this request with a permission primer.
It starts with the user picking a goal for how long to spend each day learning their chosen language. It then primes the user to accept the notification request. It positions the notifications that the user will receive as ‘daily reminders’ that will help them meet their learning goal. (That’s the goal they literally just set and, in this moment, really want to stick to.)
Shine, Voisey, Headpsace: show users what they’ll get if they allow the permission request
Shine gives users a little preview of the notifications they’ll receive before asking users to turn on these notifications. Music creation app Voisey (which was recently acquired by Snapchat) does something similar. It shows a series of notifications the user can expect once they are active and posting on the app.
Headspace doesn’t show a visual preview, but it gives a good description of what the user can expect if they accepts notifications. And it gives the user control over which types of notifications they will receive.
WHO DOES THIS NOT-SO-WELL
Facebook, Calm, TikTok: request notifications abruptly, interrupting another onboarding step
Facebook requests permission to access the user’s location while the user is in the middle of setting their profile picture. This request is unrelated to any user action and appears abruptly, without any priming on the app’s part. It interrupts the user just as they are completing another key onboarding step. (How many users, I wonder, hit “Not now” without absorbing what’s being asked, just so they can go back to their profile picture?)
Calm and TikTok, similarly, interrupt key moments in their app onboarding with requests to send the user notifications. In Calm, the request appears right as the user is pondering the question (‘what brings them there?’) that will help set their direction within the app. In TikTok, the request interrupts the first video the user is seeing. Right as they are ready to 🤣😢🙄, the app says “✋, we have some far less interesting business to attend to first.”
ESPN, Tasty, Yubo: ask for permissions that there’s no obvious reason the app needs
For every app that primes the users to grant phone permissions, explaining why they’re needed and what the app will do with the data, there’s another app that hits the user with a request out of left field.
Maybe there’s a good reason that ESPN needs to find and connect to devices on the user’s local network. (Maybe it’s it to sync up with the users ESPN account on, say, a streaming box?)
Maybe there’s a good reason that recipe app Tasty needs to send the user notifications.
Maybe there’s a good reason that friend discovery app Yubo needs access to the user’s phone location to set their country. (Rather than using, say, the app store they downloaded the app from as a default country and letting the user change it if needed.)
But if there are good reasons, these apps haven’t even tried to communicate them to the user. Instead, the apps leave the user guessing what will happen if they press ‘Ok’ or ‘Allow’. Guessing whether it will help them get closer to the value the app has promised them— or whether these requests are just self-serving moves that benefits the app but not the user.
KEY TAKEAWAYS:DO:1. Clearly tie permission requests to user actions. Granting these requests is in the user's interest, as they help the user make progress in the app, quickly. (Like Snapchat)2. Prepare users before requesting phone permissions. Permission primers are particularly important if the permission request is not triggered by a user action — when there is nothing that the user is trying to accomplish right now that requires the permission. (Like Wakeout, Strava, Nike Run Club, Duolingo)3. Show users what they'll get if they allow the permission request. (Like Shine, Voisey, Headspace)DON'T:1. Request notifications abruptly, interrupting another onboarding step and slowing the user's momentum. (Like Facebook, Calm, TikTok)2. Ask for permissions that there's no obvious reason the app needs, especially without warning and explanation. This can look, to the skeptical user, like a self-serving move that benefits the app but not the user. (Like ESPN, Tasty, Yubo)
4. The top apps … show the user just how much people like them have benefited from the app 🙏🏽
A user is likely influenced by a number of social proof markers before they’ve even download an app. They will have some idea about the popularity of the app (from app store rankings) as well as the opinions of existing users (from ratings and reviews).
An app can continue to provide this social proof at key moments, as the user progresses through onboarding. It can reinforce the idea, in the user’s mind, that “yep, this app is for someone like me”.
WHO DOES THIS WELL
Discord, Wattpad: show just how many users have already benefited from the app
Discord and writing community Wattpad each note the size of their user base prominently on the initial screens of the app.
These numbers can help increase the user’s confidence in the quality of the product and the community (“how could so many other users be totally wrong?”).
Mentioning this up front is particularly effective for apps where the size of the user base is bigger than most users might expect. And, in particular, when the size of the user base has a material effect on whether the user is likely to find value from the app. (Specifically: for apps with strong network effects, where the value of the product increases with each additional user.)
For Discord, 100 million users means that there is a decent likelihood any new user will know at least someone on the platform when they get started. For Wattpad, 80 million users means any new user will likely find some writing that appeals to them, even if they have very specific/niche tastes.
In both cases, this can increase the confidence a new user has that the app will be able to deliver the value that it has promised.
SoundCloud, Shine, Strava: create a sense of human connection
Faces stand out. They cut through other UI elements and grab our attention. They are the first thing on a screen that we look at and react to.
And they can make us feel things. A user loading up the SoundCloud app for the first time is likely to see two faces, smiling, having fun together and feel “yeah, I’d like that”. Faces create a sense of human connection.
They create a sense of community and help build trust. Shine asks the user to select a goal, to define why they want a self-care ritual. As soon as the user completes this, they’re shown the number and the faces of other users who are pursuing the same goal. The user can see that they’re not alone, that there are many others like them — all here on this app.
Strava similarly uses the the faces of its users to build community and trust. Like many other apps that have paywalls, Strava features user testimonials right at the point where it asks users to stump up some cash. These testimonials assure the user that, should they part with their £47.99 per year, the app will deliver for them, the same way it did for Fiona C. and Sarah S. and Dan T.
Noom: use data to show that the app can (and will deliver) on it’s promise to users
Weight loss app Noom repeatedly provides data to the user to build confidence that it can deliver on its promise. It refers to the substantial number of users who have gone through its weight loss program. And it displays the success rates of the program’s users (64%, 78%).
Now, many users might look at this only briefly, giving these screens only a cursory review. But the data (and the charts) help establish something essential to Noom’s program: that unlike other weight loss programs, this one is scientific. Don’t just believe us, it says. Believe the data. Lots of people — people just like you — have done this. And it’s worked for them.
(Noom, like Strava, has a paywall. Unlike Strava, Noom’s paywall is not skippable — there’s no free version of the app. So the belief the user needs to have in the app’s effectiveness, by the time they hit the paywall, is pretty high.)
Of course, most apps won’t have data on their effectiveness written up in an academic journal. But all apps do have some quantifiable data on whether they are living up to the promise they’ve made to users. From app store reviews, from NPS scores, from other internal measurements of effectiveness. Duolingo, for example, includes the claim that “[Duolingo] Plus learners are 4.2x more likely to finish the course” on its (optional) paywall.
WHO DOES THIS NOT-SO-WELL
Again, it’s hard to highlight specific failures in this area.
But we do see many apps missing the opportunity to use social proof to re-assure the user, as they go through onboarding, and to counter any uncertainty the user feels about whether the app really is for people like them.
KEY TAKEAWAYS:DO:1. Show just how many users have already benefited from your app. Because: how could this many other users be totally wrong? (Like Discord, Wattpad)2. Create a sense of human connection. Faces stand out. They cut through other UI elements and grab our attention. They can make us feel things. And they can create a sense of community and help build trust. (Like Soundcloud, Shine, Strava)3. Use data to show that the app can (and will deliver) on its promise to users. Quantifiable data, from as objective a source as possible. (Like Noom)DON'T:Miss the opportunity to use relevant social proof to re-assure the user, as they go through onboarding.
And that’s a wrap.
If you are re-thinking your onboarding flow and using any of the lessons above, I’d highly recommend checking out Darius Contractor’s “Psych Framework”. It’s a method for quantifying how users are feeling at any point in the experience with an individual app. As Contractor puts it:
Every UX interaction increases or decreases Psych, the unit of measure for motivation to complete an action.
You can get to a solid Psych measurement through some in-depth UX testing with a variety of users. Or as a quick starting point … just revisit your product with fresh eyes, installing it from scratch and noting your emotions at each step.
(For some inspiration on what a Psych measurement can look like for an individual app, check out some of the case studies at growth.design)
I’ll be back shortly with one more article on mobile app onboarding, which covers sign-up forms — how some apps nail it and others, um, don’t.
I’m a product consultant working out of cold, wet, grey London, UK. Follow me here on Medium for more on onboarding and user activation (plus some other stuff I have knocking about in my head). Or you can get in touch by email: firstname.lastname@example.org.