如何理解复杂的b端业务（B端业务系统用户权限交互可用性设计）
如何理解复杂的b端业务（B端业务系统用户权限交互可用性设计）根据权限业务逻辑的复杂程度，可以有不同的权限设计策略。小到Figma这样协作的设计工具，给每个项目成员设置具体项目编辑和查看权限，大到复杂的业务系统，涉及到复杂的权限逻辑，对某个页面、模块的功能操作权限和数据权限等。因此，用户权限功能解决的是企业或组织中员工的职权问题。根据笔者个人的理解，可以根据产品功能倒推其解决的问题是什么，以明晰需求真伪和需求价值。一般使用场景故事法去验证功能需求，常用公式是某功能解决什么用户在什么场景下具体什么问题。所以，用户权限功能作为产品的解决方案，我们可以从B端产品服务的用户群体和用户需求场景进行思考。B端产品主要是面向企业组织服务，企业组织结构复杂，员工的职权范围不同。场景一：一个项目团队在工作过程中，项目经理、产品经理、视觉设计师、前端开发和后端开发是不可以随意修改交互设计师的设计稿的，否则设计不可控，出现矛盾和纠纷。场景二：公司产品定价策略是不宜对外公开
编辑导读：B端业务系统中的用户权限功能，是一个涉及到多个角色的复杂功能。如何在复杂逻辑下提升交互体验呢？本文主要从用户体验的视角，通过具体的用户权限交互设计案例分析，分享如何在复杂权限逻辑下提升用户权限的交互体验，理解用户权限的通用设计原理-RBAC模型。
一、B端业务系统的功能共性
所有的B端业务系统都具有一条相同的功能共性——用户权限功能，涉及多个角色。
比如，供应商管理系统、定价系统、CRM等涉及流程审批，Teambiton、石墨文档、蓝湖等项目协同工具也存在权限功能等等。
为什么B端业务系统都需要用户权限功能？
根据笔者个人的理解，可以根据产品功能倒推其解决的问题是什么，以明晰需求真伪和需求价值。一般使用场景故事法去验证功能需求，常用公式是某功能解决什么用户在什么场景下具体什么问题。所以，用户权限功能作为产品的解决方案，我们可以从B端产品服务的用户群体和用户需求场景进行思考。B端产品主要是面向企业组织服务，企业组织结构复杂，员工的职权范围不同。
场景一：一个项目团队在工作过程中，项目经理、产品经理、视觉设计师、前端开发和后端开发是不可以随意修改交互设计师的设计稿的，否则设计不可控，出现矛盾和纠纷。
场景二：公司产品定价策略是不宜对外公开的，一旦泄密则需要追究责任，从公司信息安全角度，就需要限制员工职权。
因此，用户权限功能解决的是企业或组织中员工的职权问题。
二、如何在复杂权限逻辑下提升交互体验？根据权限业务逻辑的复杂程度，可以有不同的权限设计策略。小到Figma这样协作的设计工具，给每个项目成员设置具体项目编辑和查看权限，大到复杂的业务系统，涉及到复杂的权限逻辑，对某个页面、模块的功能操作权限和数据权限等。
图：Figma 项目成员权限设置
不同的业务，其权限逻辑是不同的，但权限设计原理和交互体验设计却是相通的。下面通过两个设计案例，分析用户权限交互体验设计思路和技巧。
2.1 案例一：蓝湖项目权限交互设计
下图是蓝湖的项目成员权限设置界面。设计目的主要是帮助用户高效设置项目团队成员具体的权限。权限功能设计是基于角色的访问控制RBAC模型，即围绕用户、角色和权限三者展开设计。用户是指该项目中具体的成员，角色是指超级管理员、管理员、编辑者、查看者，权限则是指具体的项目权限项，如创建、删除项目、编辑画布、删除团队成员、移交团队。不同的角色，其权限范围不同。
同用户和权限直接关联的功能设计方案相比，通过引入角色，超级管理员无需给用户单独设置具体的权限项，一键完成，可有效提高权限设置效率。
图：蓝湖项目团队权限设置
围绕给用户设置权限的目的，可拆分任务为创建权限、分配权限和使用权限。蓝湖将创建权限和角色的权限项这一复杂逻辑转移至系统，由系统设定好超级管理员、管理员、编辑者和查看者四种角色，并赋予每个角色对应的权限项，用户只需要针对具体用户设置角色即可，进一步提升了给用户设置权限的效率，让用户权限设置变得更加简单易用。
此外，邀请用户加入项目，默认首选项是查看者角色。为什么？因为大多数场景下，用户邀请的项目新成员只需要查看，所以默认首选项可以设置为查看者角色，提高了用户邀请新成员加入项目的权限设置效率，如需变更权限，则点击变更角色即可。
小结：
- 将复杂的权限逻辑转移给系统解决，让用户设置权限更简单。
- 从用户主要场景出发，提供权限默认首选项。
- 基于角色访问控制RBAC模型（Role-Based Access Control）进行权限功能设计，引入角色，提高分配权限效率。
2.2 案例二：T-PaaS平台用户权限交互体验优化
下面以笔者负责的T-PaaS平台用户权限交互优化为例，阐述如何在复杂的权限逻辑下提升交互体验。
首先，需求来源于用户反馈，具体需求是用户在新建权限时，交互效率低下，可用性差。
下图是最终确定的交互设计方案，下面具体解释一下为什么这样设计，以及是如何想到这样的设计方案，这样的设计给用户带来的价值是什么，以此提炼出可提升权限交互体验的一些思路和方法。
图：T-PaaS平台新建权限交互优化
整体设计过程分三个阶段，分别是定义问题、解决问题和输出交互原型设计方案。
阶段一：问题诊断
分析用户痛点，明确具体要解决什么问题。你是怎么知道体验不好的？为什么不好呢？所以要先发现并验证用户需求痛点。可以通过分析用户心智模型，同线上的设计模型对比匹配，找到并验证用户具体的使用痛点，而不是根据设计师自身的经验去分析用户痛点。
图：模型匹配
用户心智模型分析：
通过与产品经理详细沟通得知，用户权限功能的使用者是系统管理员，只有系统管理员才可见用户权限功能模块，所以锁定目标用户是管理员。用户需求场景是：管理员给系统用户设置权限时，通常是分配多个服务的权限，而每个服务又包含多个资源权限。
场景描述：管理员给某用户设置多个不同实例的相关权限，而实例分散在不同集群下不同的应用。因此，判断管理员用户目标是给系统用户同时设置多个服务的权限，这是目标用户的心智模型。
线上设计模型分析：
线上的权限设计是引入权限组，权限组关联具体的服务权限项设置，但是权限组和具体的服务权限是分开创建的。具体交互路径是：管理员新建权限时，每次只能选择单个服务并设置对应权限，创建完成后保存。如需新权限，则重复新建权限并保存。最后是新建权限组，从已创建的权限列表中选择已设置好权限的服务，如下图所示。
图：线上新建权限组的交互路径（优化前）
在大多数场景下，完成一个权限组的交互至少要9个步骤，而且还需要反复来回切换跳转页面。而用户目标是给系统用户同时设置多个服务的权限。从用户体验角度看，设计目标是帮助用户高效设置多个服务的权限。而线上的设计模型无法同时设置多个服务的权限，无法更高效地匹配用户的心智模型，所以问题确定是新建权限的效率比较低。
综上，我们发现用户具体的使用痛点是：管理员在新建权限组前，每次只能创建一个服务的权限，页面来回跳转，交互路径过长，导致管理员在新建权限组时花费太多时间，效率比较低，用户体验不友好。
因此，确定设计目标是提高管理员新建权限的效率。
阶段二：解决问题
围绕设计目标——提高新建权限的效率，根据用户具体的使用痛点，交互路径长等问题，我们可以缩短其交互路径，合并单个服务权限的创建，让管理员一次性设置所需服务的权限，交互步骤缩短至三步完成。所以，变更后的交互方案是用户新建权限，批量选择所需服务并设置对应权限，完成权限创建，步骤如下图所示。
图：新建权限的交互路径（优化后）
依然围绕设计目标，再继续拆解管理员新建权限的任务。我们将管理员新建权限的任务过程细分为选择服务前、选择服务时和选择服务后三个行为节点，构思交互方案。
选择服务前，需明确设计目的是如何帮助用户找服务。有哪些服务？用户找服务的目标是否明确？服务名称是否易识别？根据什么方式排序便于查找服务？用户常设置哪些服务？大概从这几方面思考设计策略，帮助用户选择所需服务。而具体该如何解决这个问题，则需要深入了解当前权限具体的业务逻辑和用户找服务的需求。
权限业务逻辑如下：
- 层级关系是服务-集群-应用-实例，应用空间与服务是并列关系，集群、应用、实例存在多个的情况。
- 服务的功能权限：查询、增加、删除、编辑、查看。
- 服务项56项，有新的服务时会递增。
- 字段有权限名称、描述、服务项权限设置
所以，我们从以上权限逻辑关系和数量范围，可以确定的是目前服务数量是有限的，根据信息优先顺序，先展示权限名称，再展示服务权限设置，服务的资源条件使用多选树状结构展示，既清晰表达资源层级关系，又易于实现，如下图所示。
图：具体服务的资源条件设置
而且，服务权限设置模块的下方已无内容。综上，权限设置采用列表平铺的方式全部展示，一目了然，查找服务效率高一些。
而用户找服务目标是明确的，由于服务名称多为英文字符，也无法确定哪些是常用服务，所以考虑列表采用按照服务名称首字母A-Z的有序方式排列，使用列表索引方式帮助管理员查找服务。因为用户在找服务的场景下，主要是依赖服务名称查找，找东西本身是有记忆成本的，因此，服务名称的定义、列表的排序方式是需要我们设计师深入思考的机会点，不要让用户思考。
当用户选择服务时，只需勾选即可。但是需要考虑点击区域和服务名称如何展示。选择服务后，则需要考虑用户具体要设置服务的哪些权限，如何设置具体的权限？可以根据大多数的场景提供默认功能权限的首选项，减少操作，提高效率。
此外，T-PaaS权限设计也使用了RBAC模型，平台用户对应的就是模型中的用户，权限组（权限集合）对应的是角色，服务项对应的是模型中的具体权限。
小结：
- 针对交互流程繁琐，回到目标用户的需求场景，缩短交互步骤，合并重复流程，控制在三步内完成用户任务。
- 权限服务项数量有限的情况下，权限服务项设置采用列表平铺展示，一目了然，找服务效率更高。
- 通过用户场景故事找到用户目标，从而找到设计目标。
- 可通过对比设计模型和用户心智模型是否匹配，挖掘并验证用户痛点。
- 围绕用户需求场景(问题)，不断拆解设计目标到具体的任务行为节点，思考交互设计机会点，以解决问题。
- 权限体验设计需要深入理解具体业务的权限逻辑和用户需求场景。
- 给用户设置权限需要考虑去重处理，如果有重复，取并集。
- 权限是集合关系。
- 基于角色的访问控制（RBAC）模型设计权限。
以上即为新建权限交互优化的思考过程和交互体验可思考的设计机会点，仅抛砖引玉。
三、用户权限设计原理RBAC模型以上两个权限设计案例，都使用了RBAC（Role-Based Access Control）模型，也是目前B端业务系统权限功能设计普遍使用的设计模型。
RBAC模型指的是基于角色的访问控制。具体而言，就是用户通过角色与权限进行关联。通过引入角色，提高用户分配权限效率。RBAC模型由用户、角色和权限组成。一般而言，用户和角色是多对一关系，角色和权限是一对多的关系，如下图所示。
图：RBAC模型及对应关系示意
用户是指参与系统活动的主体 。角色指的是特定权限的集合，如蓝湖权限角色超级管理员、编辑者和查看者，每个角色是被赋予了权限的集合体。而权限则是角色对页面、模块的具体功能操作和数据权限等，是具体的权限项，如编辑者可编辑画布、管理设计图、批注。
权限具体会包含页面权限、功能操作权限和数据权限。页面权限是指只有特定用户才有权限访问的页面，例如财务可以查看公司的财务报表，而运维人员不可以。功能操作权限，就是用户对页面或模块具有的增删改查等权限，比如蓝湖项目文档，只有项目超级管理员、管理员可以修改文档，研发是不可以修改的。而数据权限，就是用户可查看哪些数据。比如集团企业老板可以看到集团下各分公司的全部销售数据，而分公司的总经理只能看到自己所在分公司的销售数据，其他分公司的销售数据是看不到的。
此外，为了解决更复杂的权限业务逻辑，RBAC模型也在不断升级。比如，在角色中引入继承关系，把角色分成几个等级，每个等级权限不同，实现更细颗粒度的权限管理。或者，增加用户组，管理员直接给用户组分配角色，再把用户加入到用户组，可以批量给更多用户赋予同一角色的权限，用户除了拥有自身的权限外，还拥有所属用户组的所有权限。
四、总结本文主要围绕B端业务系统的功能共性-用户权限，通过两个权限设计案例，介绍了如何在复杂权限逻辑下提升交互体验的方法。具体总结了12点设计心得，帮助大家在做用户权限体验设计时，有一些帮助和启发。
- 将复杂的权限逻辑转移给系统解决，让用户设置权限更简单。
- 从用户主要场景出发，提供权限默认首选项。
- 针对交互流程繁琐，回到目标用户的需求场景，缩短交互步骤，合并重复流程，控制在三步内完成用户任务。
- 权限项数量有限的情况下，权限项设置采用列表平铺展示，一目了然，找服务效率更高。
- 通过用户场景故事找到设计目标。
- 可通过对比设计模型和用户心智模型是否匹配，挖掘并验证用户痛点。
- 围绕用户需求场景(问题)，不断拆解设计目标到具体的任务行为节点，思考交互设计机会点，以解决问题。
- 权限体验设计需要深入理解具体业务的权限逻辑和用户需求场景。
- 给用户设置权限需要考虑去重处理，如果有重复，取并集。
- 权限是集合关系。
- 权限颗粒度尽可能更小。
- 基于角色访问控制RBAC模型（Role-Based Access Control）进行权限功能设计，引入角色，结合具体业务，把角色分成等级或引入用户组，提高目标用户分配权限效率。
本文由 @沉一 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash ，基于 CC0 协议
