编者简介:B端业务系统中的用户权限功能是一个涉及多个角色的复杂功能。 复杂逻辑下如何提升交互体验? 本文主要讲述如何从用户体验的角度通过具体的用户权限交互设计案例分析,在复杂的权限逻辑下提升用户权限的交互体验,并理解用户权限的通用设计原理——RBAC模型。
1、B端业务系统功能共性
所有B端业务系统都有相同的功能共性——用户权限功能,涉及多个角色。
例如供应商管理系统、定价系统、CRM等涉及流程审批,Teambiton、Graphite Document、Blue Lake等项目协作工具也具有权限功能等。
为什么B端业务系统需要用户权限功能? (想想人物和场景的区别)
根据笔者个人的理解,可以根据产品的功能来推断产品解决的问题,以明确需求的真实性和价值。 场景故事法一般用于验证功能需求。 通用的公式是某个功能针对哪些用户、哪些场景解决特定的问题。 因此,作为用户权限功能的产品解决方案,我们可以思考B端产品所服务的用户群体和用户需求场景。 B端产品主要服务于企业组织,企业组织结构复杂,员工权限范围不同。
因此,用户权限功能解决了公司或组织中员工的权限问题。
2、复杂权限逻辑下如何提升交互体验?
根据权限业务逻辑的复杂程度,可以有不同的权限设计策略。 可以是像 Figma 这样的协同设计工具,为每个项目成员设置特定的项目编辑和查看权限,也可以是复杂的业务系统,涉及到某个页面或模块的复杂权限逻辑、功能操作权限和数据权限等。
图:Figma项目成员权限设置
不同的业务有不同的权限逻辑,但权限设计原理和交互体验设计是相同的。 下面通过两个设计案例来分析用户权限交互体验的设计思路和技巧。
2.1 案例一:蓝湖项目权限交互设计
下图是Blue Lake的项目成员权限设置界面。 设计目的主要是帮助用户高效地为项目组成员设置特定权限。 权限功能设计是基于角色的访问控制RBAC模型,围绕用户、角色和权限进行设计;
用户 - 项目的特定成员。
角色 - 超级管理员、管理员、编辑者、查看者。
权限 - 特定项目权限,例如创建、删除项目、编辑画布、删除团队成员和转移团队。 不同的角色有不同的权限范围。
相比于用户与权限直接相关的功能设计方案,通过引入角色,超级管理员无需单独为用户设置具体的权限项,一键即可完成,可以有效提高权限设置的效率。
图:Blue Lake项目组权限设置
围绕为用户设置权限的目的,任务可以分为
创建权限;
分配权限;
使用权限。
Blue Lake将创建权限和角色权限项的复杂逻辑转移给系统,系统设置了四种角色;
超级管理员;
行政人员;
编辑;
观众。
每个角色都被赋予了相应的权限项。 用户只需对特定用户进行角色设置,进一步提高了用户设置权限的效率,让用户权限设置更加简单易用。
此外,当邀请用户加入项目时,默认首选项是查看者角色 - 为什么? 由于大多数场景下,用户邀请的新项目成员只需查看,因此可以将默认偏好设置为查看者角色,从而提高用户邀请新成员加入项目的权限设置效率。 如果您需要更改权限,请单击“更改角色”。 能。
概括:
·将复杂的权限逻辑转移到系统中,方便用户设置权限。
·根据用户的主要场景提供默认的权限偏好。
·基于RBAC模型(基于角色的访问控制)设计权限功能,引入角色,提高权限分配效率。
2.2 案例2:T-PaaS平台用户权限交互体验优化
下面以笔者负责的T-PaaS平台用户权限交互优化为例,讲解如何在复杂的权限逻辑下提升交互体验。
首先,需求来自于用户反馈。 具体需求是,用户创建新权限时,交互效率低,可用性差。
下图是最终的交互设计方案。 我们来详细解释一下为什么要这样设计,我们是如何想出这样的设计方案,以及这样的设计给用户带来什么价值。 这样我们就可以提取一些可以提升权威交互体验的特征。 思路和方法。
图:T-PaaS平台新增权限交互优化
整体设计流程分为三个阶段,即定义问题、解决问题和输出交互式原型设计方案。
第一阶段:问题诊断
分析用户痛点,找出需要解决的具体问题。 你怎么知道你有不好的经历? 为什么不好? 因此,我们首先要发现并验证用户的需求和痛点。 通过分析用户的心理模型并与在线设计模型进行比较,可以找到并验证用户的具体痛点,而不是根据设计师自身的经验来分析用户痛点。
图:型号匹配
1、用户心智模型分析:
通过与产品经理的详细沟通,我们得知用户权限功能的使用者是系统管理员。 只有系统管理员才能看到用户权限功能模块权限管理设计角色,因此目标用户就是管理员。
2、用户需求场景为:
管理员在为系统用户设置权限时,通常会将权限分配给多个服务,每个服务又包含多个资源权限。
3.场景描述:
管理员在多个不同的实例上为一个用户设置相关权限,而这些实例分散在不同集群的不同应用中。 因此判断管理员用户的目标是给予系统用户同时设置多个服务的权限。 这就是目标用户的心理模型。
4.在线设计模型分析:
在线权限设计引入了权限组。 权限组与具体业务权限项设置关联,但权限组和具体业务权限是分开创建的。 具体交互路径为:
管理员创建新权限时,一次只能选择单个服务并设置相应的权限,创建后保存。
如果需要新的权限,请重新创建新的权限并保存。 最后,创建一个新的权限组,并从创建的权限列表中选择设置权限的服务,如下图所示。
图:在线新建权限组交互路径(优化前)
大多数场景下,至少需要9步才能完成一个权限组的交互,而且还需要在跳转页面之间反复来回切换。 用户目标是给予系统用户同时设置多个服务的权限(步骤比较复杂)。 从用户体验的角度来看,设计目标是帮助用户高效地设置多个服务的权限。 在线设计模型无法同时为多个服务设置权限,无法更高效地匹配用户的心智模型。 因此,确定问题是创建新权限的效率较低。
综上,我们发现用户的具体痛点是:在创建新的权限组之前,管理员一次只能为一项服务创建权限。 页面来回跳转,交互路径过长,导致管理员在新建权限组时花费过多时间。 需要花费大量时间,效率比较低,用户体验不友好。
因此,设计目标是提高管理员创建新权限的效率。
第二阶段:解决问题
围绕设计目标——提高创建新权限的效率,针对用户的具体痛点、交互路径较长等问题,可以缩短其交互路径,合并单个服务权限的创建,并允许管理员设置一次性获得所需服务的权限。 交互步骤缩短为三步。 因此,改变的交互方案是用户创建新的权限,批量选择所需的服务并设置相应的权限,完成权限创建。 步骤如下图所示。
图:新权限交互路径(优化后)
仍然围绕设计目标,继续拆解为管理员创建新权限的任务。 我们将管理员创建新权限的任务流程细分为选择服务前、选择服务时、选择服务后三个行为节点,并构思交互方案。
1、选择服务之前,需要明确设计目的是如何帮助用户找到服务?
可以提供哪些服务?
用户寻求服务的目标是否明确?
服务名称是否容易识别?
服务以什么方式排序以便更容易找到它们?
用户经常设置哪些服务?
从这些方面思考设计策略,帮助用户选择自己需要的服务。 具体如何解决这个问题,需要深入了解当前权限的具体业务逻辑以及用户对服务的需求。
2.权限业务逻辑:
因此,从上述逻辑关系和权限数量范围可以判断,当前的服务数量是有限的。 根据信息优先级,先显示权限名称,再显示服务权限设置。 采用多选树形结构显示服务的资源状况。 ,不仅清晰地表达了资源层次关系,而且易于实现,如下图所示。
图:特定业务的资源条件设置
而且,服务权限设置模块下面没有任何内容。 综上所述,权限设置全部以平面列表形式展示,一目了然,搜索服务更加高效。
3、用户的使用场景
用户寻找服务的目标是明确的。 由于服务名称大多是英文字符,因此无法确定哪些服务是常用的。 因此,列表应按照服务名称AZ的首字母有序排列,并且可以采用列表索引的方法来帮助管理员查找服务。 。 因为用户在寻找服务的时候,主要是依靠服务名称来找东西。 寻找东西会消耗内存。 因此,服务名称的定义以及列表的排序方式都是需要我们设计者深入思考的机会。 不要让用户思考。
当用户选择一项服务时,他们只需检查它即可。 但你需要考虑点击区域和服务名称如何显示。 选择服务后,您需要考虑用户想要为该服务设置哪些权限。 具体权限如何设置? 可根据大部分场景提供默认功能权限偏好,减少操作,提高效率。
另外创作人,T-PaaS的权限设计也采用了RBAC模型。 平台用户对应模型中的用户,权限组(权限集)对应角色,服务项对应模型中的具体权限。
概括:
·针对繁琐的交互流程,回归目标用户的需求场景,缩短交互步骤,合并重复流程,将用户任务的完成控制在三步之内。
·当权限服务项数量有限时,权限服务项设置以扁平化列表方式展示,一目了然,查找服务更高效。
·寻找用户目标通过用户场景故事找到设计目标。
·通过比较设计模型是否符合用户心智模型,可以发现并验证用户痛点。
· 聚焦用户需求场景(问题),不断将设计目标拆解为具体的任务行为节点,思考解决问题的交互设计机会。
·权限体验设计需要深入了解具体的业务权限逻辑和用户需求场景。
·在为用户设置权限时,需要考虑去重。 如果有重复,则取并集。
·权限是设定关系。
· 基于角色的访问控制(RBAC)模型设计权限。
以上就是优化新的权限交互的思考过程以及交互体验的设计机会。 这只是一个起点。
3、用户权限设计原理RBAC模型
上述两个权限设计案例均采用RBAC(Role-Based Access Control)模型,这也是B端业务系统权限功能设计常用的设计模型。
RBAC模型是指基于角色的访问控制。 具体来说,用户与角色和权限相关联。 通过引入角色,提高了为用户分配权限的效率。 RBAC模型由用户、角色和权限组成。 一般来说,用户和角色是多对一的关系,角色和权限是一对多的关系,如下图所示。
图:RBAC模型及对应关系图
用户是指参与系统活动的主体。 角色是指特定权限的集合,例如Blue Lake权限角色超级管理员、编辑者和查看者。 每个角色都是权限的集合。 权限是指角色对页面和模块的具体功能操作和数据权限。 它们是特定的权限项,例如编辑者可以编辑画布、管理设计图和注释。
权限具体包括页面权限、功能操作权限和数据权限。 页面权限是指只有特定用户有权限访问的页面。 例如,财务可以查看公司的财务报表,但运维人员不能。 功能操作权限是用户对页面或模块进行增、删、改、查的权限。 例如,蓝湖项目文档,只有项目超级管理员和管理员可以修改文档,研发无法修改。 数据权限是指用户可以查看哪些数据。 例如,集团公司的老板可以看到集团各个分公司的所有销售数据,而分公司的总经理只能看到自己分公司的销售数据,而看不到其他分公司的销售数据。
此外,为了解决更复杂的权限业务逻辑,RBAC模型也在不断升级。 例如,在角色中引入继承关系,将角色划分为多个级别。 每个级别都有不同的权限,实现更细粒度的权限管理。 或者,添加用户组权限管理设计角色,管理员直接为该用户组分配角色,然后将用户添加到该用户组中。 同一角色的权限可以批量授予更多用户。 用户除了拥有自己的权限外,还拥有其所属用户组的所有权限。 权限。
4. 总结
本文主要关注B端业务系统的功能共性——用户权限。 通过两个权限设计案例,介绍了如何在复杂的权限逻辑下提升交互体验。 具体总结了12点设计经验游戏开发素材,帮助你在做用户权限体验设计时得到一些帮助和启发。
·将复杂的权限逻辑转移到系统中,方便用户设置权限。
·根据用户的主要场景提供默认的权限偏好。
·针对繁琐的交互流程,回归目标用户的需求场景,缩短交互步骤,合并重复流程,将用户任务的完成控制在三步之内。
·当权限项数量有限时,权限项设置以扁平化列表方式展示,一目了然,查找服务更高效。
·通过用户场景故事找到设计目标。
·通过比较设计模型是否符合用户心智模型,可以发现并验证用户痛点。
· 聚焦用户需求场景(问题),不断将设计目标拆解为具体的任务行为节点,思考解决问题的交互设计机会。
·权限体验设计需要深入了解具体的业务权限逻辑和用户需求场景。
·在为用户设置权限时,需要考虑去重。 如果有重复,则取并集。
·权限是设定关系。
·权限粒度尽可能小。
·基于基于角色的访问控制RBAC模型(Role-Based Access Control)设计权限功能,引入角色,将角色与具体业务结合,对角色进行分级或引入用户组,提高对目标用户分配权限的效率。
文章来源:https://maimai.cn/article/detail?fid=1676302478&efid=Li36h5Gc8pYZilwOM6_ESw