Purposeful Design for User Permission

Vivian Cromwell

Published in

Chop Technologies

6 min readNov 23, 2016

(Credit: https://www.pexels.com/photo/iphone-checklist-hands-human-29765/)

“Design is the beauty of turning constraints into advantages.”

— By Aza Raskin

Design Within the Constraints

I love mobile design because it’s full of constraints. Those constraints force us to think carefully about how and when we present information to the user, and what questions we ask, leading the user to hopefully make the selection we want.

At Chop, we went through three design iterations with a few user testings in between, before we released the first version in October. The consumer mobile app is much less forgiving compared to web apps that often have very iterative processes. This is also the first mobile design and development experience for me, and I was very keen on delivering the experience that I would want as a user.

One example is the classic notification permission. Chop needs both geolocation and notification permission. We ask for geolocation so we can prepare the right nearby stores. We need notification permission so we can notify the user when their order is ready, and prompt them when they’re close to locations they’ve ordered from previously.

The Common Approaches

Brendan Mulligan from Launchkit has a great article that covers many of the design patterns for permission. The most common approaches are:

Ask users bluntly without any context

When you first open the app, you get the iOS system popup: “We would like to send you notifications”. This is the worst. It’s too easily ignored.

Explain and ask during onboard

A more widely adopted approach is to explain why the app needs notification permission during the onboard process. This approach is still suboptimal because the purpose of such permission is not always obvious during the initial steps.

The Initial Wireframe

Here is the very first wireframe for Chop. We tried to explain the benefits of geolocation and notification during the onboard. We gave a lot of information to the users upfront: we need your location so we know where you are, we will notify you when your order is ready, and notify you again if you visit the place frequently.

Design Iteration One

User Study

The above wireframe took a very typical approach, which is to ask permission upfront. I was curious as to how users actually react to those common design approaches so we recruited six users in San Francisco to test two freshly-installed apps. One was a news app, the other a commerce app. We asked them to discuss their thought processes when they saw the permission prompt.

Here’s what we found:

Users accept the fact they will be asked for notification permission.
When a user is asked for notification permission, they are much much more likely to say “yes” to a transaction-based app than to a content-oriented app. It is simple, they pay money in a commerce app, so they want to receive what they paid for.
More than 50% of the users don’t want to give permission to content-oriented apps because they are unsure of the app’s value. They want to give it a try and enable notifications later.
Some of them mentioned if they are getting too many notifications, they uninstall the app.

Design Iteration Two

The above user study confirms that the likelihood of a user giving us notification permission is decent because Chop is a transaction-based app. However, we wanted to push it further. We wanted to have the fewest number of screens between the user and their first order, and we wanted to be truly thoughtful for the user, and ask only what we really needed to know.

After recognizing what we wanted, we realized that we only needed to ask for notification permission after the user made their first purchase. So, we considered what would happen if we moved the notification permission to follow checkout. Some may argue that you want to get the user notification permission as soon as possible, so you can re-engage them with a popup. However, if you fail to get the user to make their first order on their first try, how likely is it that they will come back because of a notification? Perhaps you can entice them with a discount, but customers acquired this way typically have low retention. I know as a user, I would most likely ignore similar notifications.

We are betting on a clean and thoughtful user experience, where we focus on getting the user to complete their first purchase. We decided to move the notification screens to after checkout. If the user has already paid, obviously he or she would want to get notified when their order is ready, right?

Here is the design for iteration two:

A slight variation when we decided to omit the background image.

Design Iteration Three (the Current One)

We were pretty happy with the last design iteration — moving the notification to after the user makes their first purchase. But, we still felt there were too many screens before the user could complete their first purchase, including the onboard and login screens. We looked for opportunities to remove more, and an idea occurred to us: what if we move the notification permission ask screen inline with the order status screen? Instead of asking users to choose between “Notify me” and “Don’t notify me” as a separate screen, we will inline the ask and let the user initiate the request.

Here is the design iteration round three:

As you can see, we embedded, “Notify me when it’s ready” on the “Order Status” screen and the request is initiated by the user. The nice thing about this design is that if the user doesn’t initiate on their first order, the option is always there on their second or third order. While in the previous design, the user had an either/or choice to either get notified or not, they didn’t have the option to choose later.

Again, here we are betting on a clean and thoughtful design that we hope will lead users to come back on their own.

This design is currently in production, which we launched in mid October. Four weeks in, we are happy to report that 70% of the users enabled notification on their first order. Without ads and a big budget, we have a small set of users who love the service and come back regularly. It’s a wonderful feeling waking up in the morning, thinking that one of your customers might be ordering the same Acai bowl as you on their way to work, then it happens, just like that.

Next Step

So we summarized our design iteration on a simple notification permission, what’s next? There are quite a few things we want to improve.

For example, how can we increase that 70% notification permission to 90% on the first order? Can we make the UI a more intuitive “call for action”? Now that we know users’ regular ordering patterns, can we enable rich notification on the lock screen so that when a user is nearby, they can start their usual order without opening the app?

Good Reads

Special thanks to Andrew Littmann and Brian Benitez, who help create the thoughtful user experience for Chop and provide guidance as I learn about the mobile design .