In Context: Permissions with the Hover SDK, part III

Example of in-app permission flow

Jess Shorland
Hover
3 min readNov 28, 2019

--

This is part III of a three-part post. Check out part I and part II to learn more about our UX research and required permissions.

In this example, a person has downloaded an app in which they need to float their digital wallet. They have already opened the app and chosen to top up their wallet with their mobile money account, at which point they enter the permission flow. We’ll go through each permission and explain key UX improvements.

  • Improve the hierarchy of information through font sizes and color contrasts.
  • Simplify the explanation by using a more conversational tone and shorter copy.
  • Remind people that these are just the initial steps to performing their action. This helps avoid drop offs of people who think that are in the wrong place in the app.
  • It’s a one time process.
    For people less familiar with permissions requests, remind them that this is a one time process.

Start with familiar permissions. People can quickly move through permissions they are more familiar with, giving them a sense of forward momentum. These permissions’ text and designs cannot be customized.

  • Users are very literal when they face an unfamiliar process and want guidance. We are as descriptive as possible on how to describe the actions that they need to take, rather than explaining the functionality of the permission. Use wording like “in next screen”.
  • The illustrations are a recognition strategy and give people a “visual cue” that mimics what they will see in the next screen.
  • Keep consistency in simulated permissions by using “CONTINUE”, which helps signal forward momentum on the right path.
  • Similar to the “Accessibility” permission, the Overlay is as descriptive as possible, and explains the expected action to be taken in the next screen.
  • Although more accurate, avoid using technical words like Toggle.
  • The use of a grey background under the illustrations gives the sense of an image rather than a button, in order to avoid people clicking on the toggle in this screen.

We hope this series of posts has given you more insight into the SDK’s required permissions and how best to display them to users. Have feedback or questions on the permissions process? Please reach out to us directly at support@usehover.com.

--

--