In Context: Permissions with the Hover SDK, part I

Welcome to our blog series, In Context. Throughout the next few weeks, we’ll be exploring in-depth examples of how Hover’s SDK helps you use USSD as an infrastructure rather than just an interface 😎 🚀 💸

While testing Hover’s alpha Android SDK in late 2018, we identified its required permissions as a key challenge to creating a successful user journey. Permissions were a major point of confusing friction for app users, and we weren’t sure how we could improve the experience given the limited amount of customizations we could make to our required permissions.

Having been recently accepted to Catalyst Fund, an early stage start up accelerator focused on financial inclusion, they organized and helped carry out UX research on Hover’s in-app permission user experience. We conducted 17 interviews, in 7 locations across Nairobi, while iterating over 5 prototypes in the process.

Hover permissions explained

Android has two levels of permissions:

• normal — permissions that don’t pose much risk to the user’s privacy or the device’s operation, and
• dangerous — permissions that could potentially affect the user’s privacy or the device’s normal operation.

Normal permissions are granted automatically upon download from the Play Store, while dangerous permissions must be explicitly granted by the user at app run-time. Typically these permissions only have to be granted once.

Hover’s SDK uses four permissions:

• Read SIM and make and manage phone calls to ensure proper SIM detection and initiate the USSD session through the dialer.
• Show drawing overlay to show the processing screen while the transaction automates in the background.
• Use accessibility services to complete USSD session on behalf of the user.
• (Optional) Read SMS to parse transaction confirmation SMS on a user’s device. If you do not need to parse the final confirmation SMS, or if the provider uses USSD confirmation messages, you can exclude this permission using our -noSMS version.

Results

Evidence from our tests suggest four principles for designing a smooth permission journey in an app that uses the Hover SDK.

• Explain why— letting people know exactly why you are requesting the permission(s), how you will store and use any data derived from the permissions, and what value they will receive in return helps build trust.
• Forward momentum — if the flow loops back to the beginning with no indication of progress or how to move forward, they are much more likely to feel stuck and abandon the app altogether. Presenting permissions to the user in the context in which they need to grant them is another way to provide forward momentum (e.g. asking them to grant dialer permissions only once they begin the transaction process).
• Set realistic expectations — telling people how many permissions you require can be helpful in setting their expectations of time required to onboard and give them an endpoint to work toward.
• Be literal and localize — use straightforward, simple, and descriptive language explaining how to turn on permissions and why you are asking for them. Include appropriate string translations to lessen any cognitive burden.

In 2018, ~30% of total end-users completed the permissions flow on the first try, with almost all friction and drop offs occurring at the accessibility permission screen. With our new out-of-the-box permissions flow implemented based on the above principles, this has improved significantly throughout 2019. On average, about 75% of end-users complete all permissions.

In part II of this post, we’ll explore the default end-to-end Hover permissions. Part III will show a real-world example in the context of an app.