The Notification Problem

Hopper
Hopper
Aug 17, 2015 · 7 min read

To “allow” or not to “allow,” that is the question.

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

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.

Image for post
Image for post

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

Image for post
Image for post

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

I iterated quickly by sketching, with the top series of screens in the sketches below reflecting our initial solution:

Image for post
Image for post

Translated to our app’s UI, it looked like the below:

Image for post
Image for post

For the notifications screen, we decided to test only one path forward: pressing the “Allow Push Notifications” button, triggering the iOS notification alert.

Image for post
Image for post

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

The Fork

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.

Image for post
Image for post

Within the existing flow, it looked something like this:

Image for post
Image for post

Natural Onboarding

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.

Hopper

Written by

Hopper

Hopper uses big data to predict when you should book your flights & hotels. We’ll instantly notify you when prices drop so you can book travel fast in the app.

Hopper

Written by

Hopper

Hopper uses big data to predict when you should book your flights & hotels. We’ll instantly notify you when prices drop so you can book travel fast in the app.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store