Agreements & Permissions

Usage

There will be scenarios where the Mini Program in use invokes device functions and user account information. These actions can be done only when agreed and permitted by users. The Mini Program requests to users for related agreements and permissions, which are deemed a prerequisite for the user to obtain the complete services of the Mini Program.

For a Mini Program, Agreement means that a user agrees to the terms of use provided by the developers and operators of the Mini Program, or other agreements. Permission means that a user grants the relevant function permissions on the mobile phone to a Mini Program to invoke in a specific scenario. The agreement and permission interfaces of a Mini Program is one of the interfaces that interact most with users at the system level, and has an important impact on the user experience.

Anatomy

Agreement and permission components mainly appear in the form of a Bottom Sheet.

Bottom Sheet Menu Compositions

A Bottom Sheet Menu is a floating layer that appears from the bottom of the screen when a user performs an operation or triggers a scenario. On this floating layer, a user can start a new task, make a choice, or double-check a destructive operation. The difference from an alert box is that a dialog box is more disturbing to a user and is generally system generated to hope that a user will deal with it immediately. A Bottom Sheet Menu often appears after a user has performed an operation, which is often somewhat expected.

A Bottom Sheet Menu for the agreement and permission consists of Mini Program information, permission request information, and operation buttons. We recommend that you design the information area of the Mini Program at the top in such a way that you can tap the area to jump to the About page of the Mini Program. You can place a right arrow icon to the right of the name to remind users that this area can be tapped. In the permission request information, the required permission shall be specified with icons corresponding to the permission content for users to quickly recognize. For the texts of the operation buttons, the words with permission semantics shall be applied on the primary button. We recommend that you use the form of "being negative to the texts of the primary button" for the secondary button, instead of using a single word with negative semantics. Therefore, the users can quickly recognize that the two buttons represent opposite meanings.

Types

In the current application scenario of a Mini Program, you need to obtain user agreements and permissions in the following scenarios:

User Device Permissions

Read the user location, use the device camera, use the device microphone, read the device album, use the device Bluetooth, and read the user Contacts.

User Information Permissions

Read the phone number, basic information, membership rights, and bonus points of a user in the application to which the Mini Program belongs to.

In view of the design concept of the "Exit-As-You-Go" of the Mini Program, the obtained permissions are usually one-time effective. If the relevant permissions are needed for the Mini Program again after a period of time, a request must be initiated again. Therefore, it is a good practice to provide users with the "Remember Your Selection" function in the design.

Device Permission

According to the preceding menu structure, the main permissions for device functions include contacts, photo album, location, microphone, and Bluetooth. See the following figure for the reference sample of UI components:

Permission of Mobile Phone Numbers

The source of mobile phone numbers shall be specified. The source is normally the account information of the app where the Mini Programs built in. Buttons shall also be provided for the users to use other mobile phone numbers.

User Information Permission

For the permission of user account information, the button for the users to switch other accounts shall be provided. If the required information involves a relevant agreement, the hyperlink to this agreement shall be given for the users to access.

Design Suggestions

1. Ask Users Only When Related Scenarios Appear

Instead, do not request permissions when users use the Mini Program for the first time. Because users may not agree to authorize multiple permissions at one time, do not request all the permissions from users at one time. For Mini Programs with strict terms of use, as the necessary decision-making information for the entire Mini Program, these terms of use appear immediately when users access the Mini Program.

2. Users Must Make A Choice

The primary button is "Allow", and the secondary button is "Do Not Allow". We recommend that you do not write the text on the button as "Cancel", because "Cancel" is actually a kind of "Do Not Allow". Do not make users think that they have not made choices at the moment. There is no intermediate state for the result of the permission selection. There are only two paths available so that users need to make clear choices.

3. Show Users the Specific Contents To Be Permitted

For example, to ask for the permission for a phone number, both the phone number and where the information is sourced should be displayed. To ask for the permission for personal information or some information, show the user exactly what permissions to obtain.

4. Provide Guidance Info For Users Who Have Denied Permissions

Even if users select the "Do Not Allow" option, you still need to prompt users with the benefit of granting the permission when the relevant scenario appears, and guide users with where to change the permission setting.

Scenarios

The scenarios are divided into required scenario and non-required scenario, according to the necessity of agreements and permissions in the business process of a Mini Program.

1. Required Scenario

This is a scenario in which the business process cannot continue if a Mini Program does not obtain the related permissions from the user. When users deny permissions, we recommend that the page path needs to be set to "return to the previous page". If users trigger the corresponding page again, the permission component will still appear until the users grant permissions.

2. Non-Required Scenario

This is a scenario in which the business process can continue even if a Mini Program does not obtain the related permissions from the user. In such scenarios, Mini Programs usually allow users to manually enter required information to compensate for the information that cannot be obtained due to unauthorized access. The permission control will appear again when the users trigger a function that needs the permission.

3. Do-Not-Disturb Selection and Resetting

For non-required scenarios, a "Remember and Never Ask Again" checkbox can also be provided on the component interface, and the permission will no longer be triggered when this page is accessed later. However, when other services that need to be permitted occur in subsequent operations, an alert will be triggered to ask and guide users to reopen the permission dialog box on the "Mini Program Permission Setting" page. This will provide a better user experience.

4.Permit to Log On With a Wallet Account and Associate With a Merchant Account

If a Mini Program merchant detects that the email or phone number of the wallet has registered in the Mini Program, users can be guided to associate the wallet account with the merchant account.

Case Study

South African Wallet For Mobile Payment - Vodapay

In the business strategy, Vodapay decides to start external cooperations through Mini Programs to develop more scenarios for the wallet app.  When the users visit the third-party Mini Programs through Vodapay for the first time, these Mini Programs need to obtain user permissions as required so that suitable services can be provided.  Meanwhile, the users need to confirm and sign the agreement with the third-party Mini Programs before using the Mini Programs.