Quick onboarding and reliable onboarding are treated as the same design goal of onboard but they are not. Quick onboarding pivots around a single metric the speed with which a new user takes the first meaningful step. Reliable onboarding measures a more difficult-to-quantify metric: whether the user thinks that providing actual information to the particular app is a good idea at this point in time. A particular flow can perform at the top level with respect to the first metric but fail tremendously at the second, and the app which is good at the first metric can scare away a customer as soon as the latter is required to provide some real information.

The most evident example of this idea is permission timing. If the new app asks for camera access, answers to location, and other personal data as soon as it opens before the user understands what the app is about—it feels like asking for the user’s wallet before the app has done any thinking. If the app asks for the same permission exactly when the user is trying to do something that needs this permission, the prompt sounds reasonable rather than intrusive. For example, Waze asking for location as soon as the app opens works well because it has already become clear that the app would be useless without this location.

In a sense, it can be said that the cost of using a front-loaded approach to data collection exceeds expectations. Every field in a registration form is perceived as a form of trust transaction and, if the user has not provided any information, there is no reason for him or her to trust the software. In contrast, a process of trust-building that is spread throughout the relationship helps in changing the situation from the very beginning. The data collected is often identical either way. What changes is whether the user experiences the request as a toll booth before they’ve seen anything, or as the natural next step in something that’s already working for them.

When considering permission requests, framing is just as important as timing. A permission request that discloses the exact benefit at that time is more likely to succeed than a vague request because the user keeps engaging in an unspoken cost-benefit analysis every time they encounter a permission request. Vague requests provide no relevant information for the calculation. When a phrasing addresses the task, the user is currently undertaking, it answers the only question they care about – why should they grant that permission? 

croncode’s apps sit closer to the hard end of this problem than most consumer apps do, because a numerology profile, wardrobe data, and personal photos are all meaningfully more sensitive than an email address. The logic of asking for everything at the get-go needs to be revised. Successful onboarding strategies were those that asked for minimum information necessary for obtaining one real result first, i.e. a birth date for Numira or one photo for YourStyle and subsequently using this first result to justify to the users why they should grant permission for further, more sensitive requests.

The unpleasant truth is that effective onboarding takes significantly longer than rapid onboarding in general, at least during the first minute. The applications that succeed in retaining their clients for longer than the first minute are not those that enable quick registration. Rather, they are the product offerings that have created an impression in the first minute of usage that makes the user feel additional registration is also a good investment of time.