To “allow” or not to “allow,” that is the question.
The Hopper app analyzes billions of flight prices daily to predict how prices will change, and tells you when to buy your tickets.
The app can predict — insanely accurately — if you should buy your tickets now or if you should wait, based on future price predictions. If you should wait, you can press “watch” and the app will literally watch the flight prices until it hits its expected “good deal” range (a historically great price), before your departure date, and then it will send you a push notification to buy. Whoa.
Our product team wanted more users to discover and understand the “watch” feature, and in turn, use it more. We were sure our numbers for conversion on this metric had not reached their peak and understanding users’ willingness to watch is an integral part of our product strategy. Given that the watch feature has important engagement hooks — i.e., a user who watches trips is more likely (by a significant multiplier) to return to the app and engage with it and other features — we wanted to make sure their first visit is set up properly and that they understood the value. We set out to improve our onboarding flow.
The Notification Problem
Notifications are really important to this “watch” concept. If the user doesn’t allow notifications for the app, they can’t receive our message that the price is at its expected low, completely undermining the power of the feature. Apple requires that you get permission from the user to send them push notifications, and restricts the firing of an iOS alert request to one time.
If the user presses “Allow,” all is well. If not, it is really difficult for a user to change course — they must exit the app, go into settings, find notifications, find the app in a long list of apps, and then set their desired level of notification.
No notifications means we could lose the user forever, so we needed to be really careful when triggering this one-time-use modal. Any “improvements” would need to take this into account.
Existing Flow
The current flow started with three educational screens in an “app tour” format to try and sell the value prop and functionality of the app; after, it sent the user off into the wild to use the app.
The problem with this was that reality had proven to us that most users didn’t want to sit and read even three short blurbs about the app — they wanted to get straight to doing. The content of these types of onboarding screens is often very general and detached from the actual places and interactions the user would be in or have with the user interface (UI).
One of these screens included our pitch for the Watch feature, but it said very little about the feature’s UI or notifications explicitly, nor their relationship to each other and iOS alerts. If users weren’t reading these messages, because there were too many and/or it wasn’t useful or timely information, that user would likely also not understand the Watch feature properly and its relationship to notifications, and thus not allow the notifications when prompted.
Onboarding = Notifications
We decided we would cut back on the initial tour screens, landing on two more practical messages: The first as a welcome and context to the overall app, and the second to focus on the value of notifications. Before the user lost interest, we would then let them into the wild of the app, contextualizing the rest of the content into small tool tips during the actual use, to improve its timeliness and usefulness.
I iterated quickly by sketching, with the top series of screens in the sketches below reflecting our initial solution:
Translated to our app’s UI, it looked like the below:
For the notifications screen, we decided to test only one path forward: pressing the “Allow Push Notifications” button, triggering the iOS notification alert.
Our hypothesis was that even though this was an aggressive gate to progression, that the button would (1) put more pressure on the user to read the tour copy before progressing, i.e., “What am I agreeing too?”, which may (2) increase awareness of the relationship between notifications, watching in the app, and saving money on Hopper — but even more importantly, we were curious if it would (3) lead to increased “allows,” despite letting potentially fewer users past onboarding. The ultimate result: a larger proportion of qualified users (users who have allowed notifications, thus benefiting from this powerful app feature) on the app.
Lesson Learned
This proved to be too heavy-handed. Further down the funnel, conversion metrics greatly improved — a much greater percentage of users were getting all the way though onboarding successfully and watching trips — likely attributed to the in-context tool tips later in the flow. But fewer people were actually getting to that point, as they either (1) dropped off right away on the notifications onboarding screen, or (2) pressed “don’t allow” on the iOS alert, even after pressing “yes” on our custom button for allowing notifications, then finding out they couldn’t watch a trip without visiting their settings outside the app. The net of this in our analytics was that we hadn’t lost any qualified users, but we also hadn’t gained any — we hadn’t improved the numbers, we just changed how we were achieving them.
The Fork
The simple lessons for us were that our users would not significantly read the onboarding screens, or even if they did and understood the content, they were not afraid to wait to “allow” us notification access until they had gotten a feel for the app first. For a user to press “allow,” they have to trust us not to abuse our newly granted power and understand the value of how we will use that power. Like our tool tips, we hypothesized that triggering the notification alert in context would increase those willing to do it, but we also didn’t want to restrict it until that moment in the app, further down the funnel.
We decided to keep the notifications screen but to instead add an “opt-out” button, forking the app to either (1) the users who don’t yet trust us and want to get a look around first, having read the copy or not and not triggering the iOS alert — allowing us to trigger it in context later — and (2) the user who were highly likely to press “allow,” triggering the modal.
Within the existing flow, it looked something like this:
Natural Onboarding
This greatly increased the number of users who continued through to the rest of the onboarding process, while maintaining the higher back-of-flow numbers we achieved through the addition of in-context tool tips. Success.
I came away with resounding support for user onboarding that feels as natural as possible, to not feel as if it is a secondary part of the experience but as if it is part of the very fabric of the app. Our tool tips helped bring us closer to that goal, with positive effects on our user engagement. And trust, well, it takes time. Our willingness to allow users to take a look around, before being forced into deciding whether to do so or not, helped establish just enough of it.
You can find Hopper for iOS on the App Store, and soon for Android.
-Pantelis Korovilas (@pantelisak), Lead Product Designer at Hopper
Interested in becoming part of the Hopper team? Click on our Jobs page for more information and to apply.
