Backstage Permission Interaction Design Guide

Backstage permission interaction design guide, This article is aimed at elementary product managers, product experience designers , and interaction designers who undertake part of the product boundary work. 

This article systematically introduces the model composition of the middle and back-end authorization system, as well as the many key points of element combing and process interface design . Readers can follow This comes from checking whether the content is sufficient and the key points in the interface design for obtaining permissions.

What is “Permission Design”

“Authorization design” is the bottom design of the middle and back office , used to clarify what the operator can do in the platform; that is, what kind of person can do what .

The meaning of permissions

• Allow users to access authorized resources within effective limits .
• Let managers control different users to reasonably access corresponding resources based on the system’s security rules and policies .

It is the permission system that allows the division of labor between different people and organizations in the work group , allows different roles to focus on their scope of work, reduces the probability of operational risks , and facilitates management.

Permission application

There are two main scenarios for the application of permission design, namely version cutting and role permission management:

• Role authority management: As the name suggests, role authority management is to assign permissions based on user role types ; a role corresponds to a set of permission groups, and a user may have multiple roles . It is suitable for application scenarios where there are many complex logic function modules in the middle and backstage, and the system needs to be cut according to permissions.
• Version management: There are commercial requirements in some middle and backstages. Based on the former’s role permission assignment (or there may be no role distinction), the complete system is divided into functions, and the entire system is divided into normal version, advanced version , or even according to function . More versions; the functional scope of these versions is basically in an inclusive relationship.

In the design of the B-side middle and backstage, the most common application scenario is “role authority management” , and the dimensions involved in role authority management will be more complicated than “version cutting”. This guide will focus on the design in the role authority management scenario .

Permission design requirements

A good permission design needs to meet the following three requirements:

• System security: Design based on system security rules and strategies , and at the same time, it is necessary to reduce the risk probability caused by user operation errors .
• Clear relationship: It is necessary to define the boundaries and relationships of permissions and follow certain rules to associate with users.
• High scalability: It is necessary to ensure the scalability of authority management , the capacity building of the system is continuous, and users are constantly flowing; maintain high scalability to reduce the impact of changes on security and stability .

Scope of work for permission design

• Interface design: a series of page designs such as permission query, management and authorization.
• Business combing: combing the logic and elements of authority composition, grant and exercise.
• Data verification & management: At the data management level, the ultimate goal is to be expressed as an algorithm, experience the rationality and scalability of the plan, and verify the effectiveness of the design.
• Low-level architecture development: the design and research and development of the low-level architecture of the system favoring the development level.

The complexity of the permission system determines the level of involvement in the design ; the general designer’s scope in the permission design includes clarifying the business logic of the permission , paying attention to the design of the page itself, and other data and implementation levels can be handed over to the product and development.

Tips: If it involves a permission system with large user levels, multi-dimensional roles and complex permission division logic, designers also need to pay attention to the underlying architecture.

How to do “authorization design”

Business combing

Preparation: understanding and selection of permission model

There are many technical models of permission systems in the industry. Common ones are ACL, ABAC, DAC, RBAC, etc., for different sizes of permission systems, we can refer to different permission models to sort out and design.

RBAC0 model

The basic idea of ​​RBAC0 is to assign the concept of “role” to users, and to associate users with permissions through roles to achieve flexible configuration.
The three elements of the RBAC model are: users, roles, and permissions.

• User: It is the main body that initiates the operation , such as: the user of the back-end management system, the internal staff of the OA system, and the user-oriented user.
• Role: Used to connect users and permissions . Each role can be associated with multiple permissions. At the same time, a user can also be associated with multiple roles. Then this user has multiple permissions for multiple roles.
• Permissions: The resources that users can access , including: page permissions, operation permissions, and data permissions.   

If your system composition requirements are relatively simple, and rights need to have two elements: users and authorization points, you can choose ACL

ACL model

ACL is the permission control list of the query operation object . When the authority system is small and users can directly correspond to specific function points to meet the system requirements, consider using the ACL model as a reference.
In ACL permissions, there are only two elements: user and permission :

If your permission system not only requires roles, but also involves the classification of roles, and the hierarchy has a certain inheritance relationship; or you need to control role constraints, you need to consider choosing the RBAC1 and RBAC2 models extended from the RBAC model.

RBAC1 model: add role inheritance based on RBAC0

The RBAC1 model is based on the RBAC0 model and introduces the concept of role inheritance , that is, roles have a subordinate relationship, and each level has different permissions, so as to achieve more fine-grained permissions management .

RBAC2 model: Introduce role constraint control based on RBAC0

The RBAC2 model is based on the RBAC0 model, which controls roles . The RBAC2 model adds the separation of responsibilities, which stipulates the mandatory rules that should be followed when permissions are assigned to roles or roles are assigned to users , and when users activate a role at a certain moment. It mainly includes the following constraints:

• Mutually exclusive roles: The same user can only be assigned to at most one role in a set of mutually exclusive roles . Mutually exclusive roles refer to two roles whose respective permissions restrict each other . For example, the design department has two roles : interaction designer and visual designer . If they are mutually exclusive roles in the system, then users cannot have these two roles at the same time, which reflects the principle of separation of duties .
• Cardinality constraints: a. The number of users assigned to a role is limited ; b. The number of roles a user can have is limited ; c. The number of access permissions corresponding to the same role is limited ; to control the allocation of advanced permissions in the system .
• Prerequisite role: Simple understanding is that if a user wants to obtain a higher-level role, he must first obtain his next-level role , which is a prerequisite.

Start to sort out: inventory elements based on the RBAC model

RBAC0 is used more frequently in actual work, and the corresponding beginner designers are also more helpful to the understanding of permissions , so this article will introduce the combing and design of the permission system based on the RBAC model.

The next work is related to the five requirements of interaction design that we usually organize. We need to find out the division of roles that the system participates in, what tasks each role needs to complete, and how the role-task relationship between each role forms a closed loop.

The first step: inventory roles

Roles are the bridge connecting users and permissions. In this step , the roles participating in the system are exhaustively listed . It is necessary to ensure that the operation of the system can be absolutely closed-loop , so it is very important to clarify the roles in the system.
There are two main ways to perform a role inventory :

• Refer to the job division of the organization itself: In most cases, the job responsibilities in the system are closely related to the actual job positions. We can refer to the existing positions to count the roles in the system.

🌰For example, role definitions in R&D operation and maintenance tools. Different positions correspond to different roles and have the right to use different tools.

• Inventory based on task flow: Exhaustively enumerate roles based on system task flow, that is, inventory which roles need to be created for task retreat.

🌰For example, the role of the intelligent customer service knowledge base supporting the A platform is generated by our definition during the product planning process.

Tips: Generally, it is necessary to reserve a “super administrator” role for the initial configuration of the system, which is used to add the first batch of administrators (management authority authorization) and configure basic roles. Some systems allow the existence of administrator roles from the perspective of God , It can be displayed in the role configuration list as a “super administrator”; some systems do not allow this role to exist, you can set it to a disabled state, and only assign it to the staff who maintain the system.

The output of this step: “role list”

Step 2: Counting permissions

Permission is the resource that the user can access. In this step, all permission points in the system need to be sorted and classified according to types, and finally into a table . There are mainly the following types of authority points that need to be counted:

Page permissions

In layman ‘s terms, the pages that the user can see in the system are controlled by navigation/menu , including first-level navigation/menu, second-level navigation/menu, and even third-level navigation/menu; as long as the user has the corresponding navigation/menu authority, they can access page.
🌰For example, the page permissions of the intelligent customer service knowledge base system:

Operation authority

In layman’s terms, it refers to the function buttons of the page , including view, add, modify, delete, review and so on.
🌰For example, intelligent customer service knowledge base system-sensitive word management-blacklist page operation authority: add blacklist, modify, delete

In actual operating scenarios, some operating permissions will change due to status . When counting operating permissions, you need to use the state flow conversion diagram to check whether there are any omissions.

Tips: It is necessary to reduce the duplication of operation authority when there is an inventory. A role is essentially a set of permissions. In the system, the general situation is that the number of permissions is more than the number of roles.

data permission

Tips: Data authority is not a fixed authority of the system, and has extremely high fluidity and flexibility. When counting permissions, we need to clarify the basis of the system’s data permissions (region/organizational structure/project). It is not necessary to list all data permissions.

Data authority means that the data that users see on the same page is different . For example, department A can only see the data under its department, and department B only sees the data of department B. The solution for data authority division is:
Create user groups – group users with the same attributes or the same data range, and different user groups have different data permissions.

According to whether the user group has a superior-subordinate relationship, the user group can be divided into: a subordinate-subordinate user group and a common user group.

• User groups with subordinate relationship: The most typical example is departmental organization.

🌰For example, there is a more rigorous process for the acceptance and approval of matters. Each unit needs to perform its own duties , and the matters handled by the public belong to all levels of regions, so the platform authority system needs to form a more rigorous regional structure and departmental organization . For example, the service data of the Municipal Public Security Bureau, Civil Affairs Bureau, and Water Conservancy Bureau are opposed. We can isolate data permissions through user groups established by departmental organizations.

• Ordinary user group: group of users without subordinate relationship . The most common common user group in the daily system is the “project group”, and the user’s data permissions are divided according to the project group.

🌰For example, use the latitude of the application project to control the range of data that the user can access .

The output of this step: “Permission Point List”

Step 3: Connect role permissions

The main work of this step is to connect the relationship between authority points and roles, and finally sort out a complete role authority table. When sorting out the relationship between roles and permissions, you can use the design analysis method “exhaustive role task behavior” to transform and connect permissions points.

Under normal circumstances, users need to complete certain tasks in order to achieve their goals. These tasks and the aggregation of tasks often affect our design considerations for the entire system information architecture . Therefore, the tasks of each role often correspond to our page one-to-one , resulting in page permissions. And because some specific actions are required to complete the task, and these actions correspond to the operation buttons one-to-one , thus generating the operation authority.

🌰Example:

The output of this step: “Role Authority Summary Table”

The fourth step: design user import and authorization process

After establishing the relationship between roles and permissions, you need to clarify the user authorization/import method , and assign role permissions to the imported users.
Clear account systemSome middle and back offices under the company domain have unified authentication methods for users , such as Tencent OA authentication; some middle and back offices require users to create independent ID accounts and passwords for authentication . We first need to clarify which of the above methods is used as identity verification in the middle and back office we designed , which will affect the design of the user import process.
Initial user authorization process

• Existing account: If it is imported for the user in the middle and back office under the company domain, the user account is ready-made, we don’t need to consider the user account. You can directly grant permissions to users. There are two ways to grant authorization: select roles for users and add users to roles.

Selecting a role for a user can be used in a single authorization scenario . The following is the authorization process for reference:

Adding users to roles can be used in batch authorization scenarios . The following is the authorization process for reference:

In order to enrich the scene and enhance the experience, two methods are recommended to coexist.

• No account: If you need to import a user with an ID created by the user , the following process applies:

To ensure safety, the invitation code must be time-sensitive .

Authorization application processIn actual work, when a user does not have permission to complete a task, it is necessary to provide a clear application process for the user . There are two scenarios for applying for permissions.

• Scenario 1: Permissions are divided into job identities, and the identity is bound to a certain group of permissions . After the user actively applies for the job identity and is approved, the group of permissions can be obtained. Refer to the following figure for the process:

Scenario 2: When a user accesses the system, the system page prompts that the user does not have access/operation permission, and the user applies for permission for the page/operation . After passing the permission, the page/operation permission can be obtained. Refer to the following figure for the process:

Draw state transition diagramIf you need to show a state transition relationship, attention state change process , even if there is a defect testing process, we can draw the system state transition diagram to sort out the transfer status. In the process of using the state diagram, the designer can clearly understand the various states of the same interface, which is convenient for the systematic design of the design scheme . In the same interface, you can modularize and compare design differences.

Message notification after import/authorizationMessage notification can reach users in time for status and content updates . In the authorization system, the import of users or the approval of user authorizations are inseparable from timely message notifications. Especially in the user link, in order to ensure security, the invitation code has a certain timeliness , so the timely delivery of messages is very important, and it is necessary to push the users in time .

Three, how to do “authorization design” interface design

Page permissions design points

Design of Guidelines for Unauthorized Page Application

In chapter 2.2.4, we mentioned that in order to complete a certain task in actual work, users will have application scenarios for unauthorised pages/operations . In addition to providing users with a clear application process, we also need to have a clear application process. The guidelines are actually designed for the empty state.

• Online application:The user initiates an application by triggering the application button, and fills in the online form to complete the application. In this scenario, in addition to the application button, we need to clearly inform the user that the user is currently not authorized , and even give a brief explanation of the reason; at the same time, it is recommended to inform the user who is the approver of the application and how long it needs to be approved .

🌰Example: Unauthorized page 

• Offline application: The page only tells the user how to apply, generally the contact information of the authorized person .

🌰Example: Unauthorized page

Data authority design points

Display and switch of data permission scope

In chapter 2.2.2, the difference in data permissions leads to different data that users see on the same page . The scope of data permissions can be divided by the organizational structure with hierarchical relationships, or by ordinary user groups. Generally, the system allows users to have single or multiple data permissions ; therefore, in our system interface, we need to have a design to display and switch the scope of carrying data permissions.

Since the display and switching of data permissions control the user’s data range for the entire system, it needs to exist in the first level of the system architecture, and can generally be placed independently on the first level menu .
Project switching:

Design point of operation authority

Unauthorized operation display design

• Can apply

For the display of operating permissions for open applications, the operating permissions can be grayed out to indicate that the user is not currently able to operate ; when the user hover the grayed out permissions, a bubble will be provided to indicate that the reason for the grayed-out is that there is no operating permission and an entry to apply for permissions is provided . 

• Not applicable

Some systems require users to see the entire operation, that is, all operations are visible regardless of whether they have permission or not; if they do not have permission and cannot apply , they will be grayed out directly.

Some systems require “visible and operable”, that is, authorized operations are displayed , and non-privileged operations are hidden . Here, front-end cooperation is required. Front-end development caches the user’s permission information , and judges whether the user has this permission on the page .
From the perspective of user experience, it is more recommended to use the latter method to isolate permissions.

Summarize

In the middle and back office, the permission system may not be as valued as the business module . It is only a function that is silently supported behind the middle and back office, but it must not be ignored . It is the permission system that can make the work group different The division of labor between personnel and different organizations allows different roles to focus on their own scope of work, reducing the probability of occurrence of operational risks and facilitating management.

In actual projects, you will encounter multiple systems, multiple user types, and multiple usage scenarios . This requires specific analysis of specific issues; however, no matter how complex it is and how the logic changes, the core RBAC model is still The same applies .