编辑指南:B端业务系统中的用户权限功能是一个涉及多个角色的复杂功能。复杂逻辑下如何提升交互体验？本文从用户体验的角度，通过用户权限交互设计的具体案例分析，分享如何在复杂的权限逻辑下提升用户权限的交互体验，理解用户权限的一般设计原则——RBAC模型。

1.b方业务系统的功能共性

所有B端业务系统都有相同的功能共性——用户权限功能，涉及多个角色。

比如供应商管理系统、定价系统、CRM等。涉及流程审批，团队、石墨文档、蓝湖等项目协作工具也有权限功能等。

为什么B端业务系统需要用户权限？

根据作者个人的理解，可以根据产品功能推断出问题是什么，从而明确需求的真实性和价值。一般用场景故事法来验证功能需求，常见的公式是某个功能解决什么场景下什么用户的具体问题。所以作为产品解决方案，可以从B端产品和服务的用户群体和用户需求场景来思考。b端产品主要面向企业组织服务，企业组织结构复杂，员工的职权范围不同。

场景一:在一个项目团队的工作过程中，不允许项目经理、产品经理、视觉设计师、前端开发、后端开发人员随意修改交互设计师的设计稿，否则设计无法控制，造成矛盾纠纷。

场景二:公司产品的定价策略不应该公开。一旦泄露，就要追究责任。从公司的信息安全角度来说，限制员工的权限是必要的。

因此，用户权限功能解决了企业或组织中员工的权限问题。

二、如何提升复杂权限逻辑下的交互体验？

根据权限业务逻辑的复杂性，有不同的权限设计策略。从像Figma这样为每个项目成员设置编辑和查看权限的协同设计工具，到复杂的业务系统，涉及到对某个页面和模块的复杂权限逻辑、功能操作权限和数据权限等。

图:Figma项目成员权限设置

不同的业务有不同的权限逻辑，但是权限设计的原则和交互体验设计是相通的。以下两个设计案例，分析用户权限交互体验的设计思路和技巧。

2.1案例1:蓝色泻湖项目权限交互设计

下图是蓝泻湖项目成员权限设置界面。设计的主要目的是帮助用户高效地设置项目团队成员的特定权限。权限功能设计是基于角色的访问控制的RBAC模型，围绕用户、角色和权限进行设计。用户是指项目的特定成员，角色是指超级管理员、管理员、编辑者和查看者，权限是指特定的项目权限，如创建和删除项目、编辑画布、删除团队成员和移交团队。不同的角色有不同的权限范围。

相对于用户和权限直接相关的功能设计方案，超级管理员通过引入角色，不需要单独为用户设置具体的权限项目，一键完成，可以有效提高权限设置的效率。

图:蓝礁湖项目组权限设置

为了给用户设置权限，任务可以分为创建权限、分配权限和使用权限。蓝泻湖将创建权限和角色权限项的复杂逻辑传递给系统，系统设置超级管理员、管理员、编辑者、查看者四个角色，并给出每个角色对应的权限项。用户只需要为特定用户设置角色，进一步提高了为用户设置权限的效率，使得用户权限的设置越来越容易使用。

此外，还邀请用户加入项目，默认首选项是查看者角色。为什么？因为在大多数场景下，用户邀请的新项目成员只需要查看，所以可以将默认首选项设置为查看者角色，提高了用户邀请新成员加入项目的权限设置效率。如果需要更改权限，可以单击更改角色。

总结:

将复杂的权限逻辑转移给系统解决，让用户设置权限更简单。从用户主要场景出发，提供权限默认首选项。基于角色访问控制RBAC模型（Role-Based Access Control）进行权限功能设计，引入角色，提高分配权限效率。

2.2案例2:T-PaaS平台上用户权限交互体验的优化

以T-PaaS平台上用户权限交互的优化为例，阐述了在复杂权限逻辑下如何改善交互体验。

首先，需求来自用户的反馈。具体需求是用户新建权限时交互效率低，可用性差。

下图是最终的交互设计方案。在这里，我们将详细说明为什么要做这个设计，这个设计方案是如何构思的，这个设计给用户带来了什么价值，从而提炼出一些可以增强权限交互体验的思路和方法。

图:T-PaaS平台上新权限的交互优化

整个设计过程分为三个阶段，即定义问题、解决问题和输出交互式原型设计。

第一阶段:问题诊断

分析用户痛点，明确具体要解决什么问题。你是怎么知道体验不好的？为什么不好呢？所以要先发现并验证用户需求痛点。可以通过分析用户心智模型，同线上的设计模型对比匹配，找到并验证用户具体的使用痛点，而不是根据设计师自身的经验去分析用户痛点。
分析用户的痛点，明确要解决什么问题。怎么知道体验不好？为什么不可以？所以首先要发现和验证用户需求的痛点。我们可以通过分析用户的心理模型，并与在线设计模型进行比较，来发现和验证用户的具体痛点，而不是根据设计者自己的经验来分析用户的痛点。

图:模型匹配

用户心智模型分析；

通过与产品经理的详细沟通，得知用户权限功能的用户是系统管理员，只有系统管理员才能看到用户权限功能模块，所以目标用户是管理员。用户需求场景是管理员在为系统用户设置权限时，通常会为多个服务分配权限，每个服务包含多个资源权限。

场景描述:管理员为一个用户设置几个不同实例的相关权限，这些实例分散在不同集群下的不同应用中。因此，判断管理员用户的目标是同时为系统用户设置多个服务的权限，是目标用户的心智模型。

在线设计模型分析:

在线权限设计是引入权限组，权限组与特定的服务权限项相关联，但是权限组和特定的服务权限是分开创建的。具体的交互路径是:管理员新建权限时，一次只能选择一个服务并设置相应的权限，创建完成后保存。如果您需要新权限，请重复创建新权限并保存它们。最后，创建一个新的权限组，从创建的权限列表中选择设置了权限的服务，如下图所示。

图:在线新权限组交互路径(优化前)

在大多数场景下，完成一个权限组的交互至少需要9个步骤，还需要反复来回切换跳转页面。用户的目标是同时为系统用户设置多个服务的权限。从用户体验的角度来看，设计目标是帮助用户高效地设置多个服务的权限。但是在线设计模型无法同时设置多个服务的权限，无法更高效地匹配用户的心智模型，所以问题是创建新权限的效率相对较低。

综上所述，我们发现用户的具体痛点是:在创建新的权限组之前，管理员一次只能创建一个服务权限，页面来回跳转，交互路径过长，导致管理员在创建新的权限组时花费太多时间，效率低下，对用户体验不友好。

因此，设计目标是提高管理员新权限的效率。

第二阶段:解决问题

围绕提高创建新权限效率的设计目标，根据用户的具体痛点和交互路径长，可以缩短其交互路径，合并单个服务权限的创建，让管理员一次性设置所需服务的权限，将交互步骤缩短为三步。因此，更改后的交互方案是用户新建权限，批量选择需要的服务，设置相应的权限，完成权限的创建，如下图所示。

图:新权限的交互路径(优化后)

还是专注于设计目标，然后继续拆解为管理员创建新权限的任务。我们将为管理员创建新权限的任务流程细分为三个行为节点:选择服务前、选择服务时和选择服务后，并构思了一个交互方案。

在选择服务之前，有必要明确设计的目的是如何帮助用户找到服务。有哪些服务？用户找服务的目标是否明确？服务名称是否容易识别？根据什么样的排序方法容易找到服务？用户经常设置哪些服务？从这些方面思考设计策略，帮助用户选择自己需要的服务。但是如何解决这个问题，需要深入了解当前权威的具体业务逻辑和用户寻找服务的需求。

权限业务逻辑如下:

层级关系是服务-集群-应用-实例，应用空间与服务是并列关系，集群、应用、实例存在多个的情况。服务的功能权限：查询、增加、删除、编辑、查看。服务项56项，有新的服务时会递增。字段有权限名称、描述、服务项权限设置

所以从上面的逻辑关系和权限的数量范围可以确认，目前服务的数量是有限的。根据信息优先级顺序，首先显示权限名称，然后显示服务权限设置。服务的资源条件以多选择树结构展示，不仅清晰表达了资源的层次关系，而且易于实现，如下图所示。

图:特定服务的资源条件设置

而且服务权限设置模块下面没有内容。综上所述，所有权限设置都是以列表平铺的形式显示，一目了然，搜索服务效率更高。

然而，用户寻找服务的目标是明确的。由于服务名称大多是英文字符，因此无法确定哪些服务是常用的。所以列表是按照服务名称的第一个字母A-Z有序排列的，列表索引是用来帮助管理员查找服务的。因为用户在寻找服务的时候主要是靠服务名，找东西是有内存成本的，所以，服务名的定义和列表的排序方式是我们设计师深入思考的机会，不要让用户去思考。

当用户选择一项服务时，只需检查它。但是，需要考虑如何显示点击区域和服务名称。选择服务后，您需要考虑用户应该为服务设置哪些权限，以及如何设置特定的权限。根据大多数场景，可以提供默认功能权限的偏好，可以减少操作，提高效率。

此外，T-PaaS权限设计也使用RBAC模型，平台用户对应模型中的用户，权限组(权限集)对应角色，服务项对应模型中的特定权限。

总结:

针对交互流程繁琐，回到目标用户的需求场景，缩短交互步骤，合并重复流程，控制在三步内完成用户任务。权限服务项数量有限的情况下，权限服务项设置采用列表平铺展示，一目了然，找服务效率更高。通过用户场景故事找到用户目标，从而找到设计目标。可通过对比设计模型和用户心智模型是否匹配，挖掘并验证用户痛点。围绕用户需求场景(问题)，不断拆解设计目标到具体的任务行为节点，思考交互设计机会点，以解决问题。权限体验设计需要深入理解具体业务的权限逻辑和用户需求场景。给用户设置权限需要考虑去重处理，如果有重复，取并集。权限是集合关系。基于角色的访问控制（RBAC）模型设计权限。

以上是新权限交互优化的思考过程和交互体验，可以认为是设计机会。

三、RBAC模式的用户权利设计原则

以上两种权限设计案例都使用了RBAC(基于角色的访问控制)模型，这也是目前B端业务系统权限功能设计常用的设计模型。

RBAC模式指的是基于角色的访问控制。具体来说，用户通过角色与权限相关联。通过引入角色，提高了用户权限分配的效率。RBAC模型由用户、角色和权限组成。一般来说，用户和角色是多对一关系，角色和权限是一对多关系，如下图所示。

图:RBAC模型及对应关系示意图

用户是指参与系统活动的主体。角色是指特定权限的集合，比如蓝色泻湖中的超级管理员、编辑者、查看者，每个角色都是一组权限。权限是角色对页面和模块的具体功能操作和数据权限，是一个具体的权限项，比如编辑者可以编辑画布、管理设计图、批注等。

权限包括页面权限、功能操作权限和数据权限。页面权限是指只有特定用户才能访问的页面。比如财务可以查看公司的财务报表，运维人员却不能。功能操作权限是指用户对页面或模块的添加、删除、修改和查询权限，如蓝礁湖项目文档，只能由项目超级管理员和管理员修改，不能由研发人员修改，数据权限是数据用户可以查看的。例如，集团企业的老板可以看到集团下各分公司的所有销售数据，而分公司的总经理只能看到自己分公司的销售数据，而看不到其他分公司的销售数据。

此外，为了解决更复杂的特权业务逻辑，RBAC模式正在不断升级。比如在角色中引入继承关系，将角色分为几个级别，每个级别有不同的权限，从而实现更细粒度的权限管理。或者，如果添加用户组，管理员可以直接给用户组分配角色，然后再给用户组添加用户，这样可以批量给更多的用户相同角色的权限。除了自己的权限外，用户还拥有用户组的所有权限。

四.总结

本文主要针对B端业务系统的功能共性——用户权限，通过两个权限设计案例介绍如何在复杂权限逻辑下提升交互体验。本文详细总结了12条设计经验，有助于我们在设计用户权限体验时有所帮助和启发。

将复杂的权限逻辑转移给系统解决，让用户设置权限更简单。从用户主要场景出发，提供权限默认首选项。针对交互流程繁琐，回到目标用户的需求场景，缩短交互步骤，合并重复流程，控制在三步内完成用户任务。权限项数量有限的情况下，权限项设置采用列表平铺展示，一目了然，找服务效率更高。通过用户场景故事找到设计目标。可通过对比设计模型和用户心智模型是否匹配，挖掘并验证用户痛点。围绕用户需求场景(问题)，不断拆解设计目标到具体的任务行为节点，思考交互设计机会点，以解决问题。权限体验设计需要深入理解具体业务的权限逻辑和用户需求场景。给用户设置权限需要考虑去重处理，如果有重复，取并集。权限是集合关系。权限颗粒度尽可能更小。基于角色访问控制RBAC模型（Role-Based Access Control）进行权限功能设计，引入角色，结合具体业务，把角色分成等级或引入用户组，提高目标用户分配权限效率。