开发者社区 > 博文 > UE Design | JDCD·分享-B端业务系统用户权限交互可用性设计-案例分析
分享
  • 打开微信扫码分享

  • 点击前往QQ分享

  • 点击前往微博分享

  • 点击复制链接

UE Design | JDCD·分享-B端业务系统用户权限交互可用性设计-案例分析

  • 云与AI设计部
  • 2021-01-19
  • IP归属:未知
  • 692浏览



如何在复杂权限逻辑下提升交互体验?


根据权限业务逻辑的复杂程度,可以有不同的权限设计策略。小到Figma这样协作的设计工具,给每个项目成员设置具体项目编辑和查看权限,大到复杂的业务系统,涉及到复杂的权限逻辑,对某个页面、模块的功能操作权限和数据权限等。



图:Figma 项目成员权限设置


不同的业务,其权限逻辑是不同的,但权限设计原理和交互体验设计却是相通的。下面通过两个设计案例,分析用户权限交互体验设计思路和技巧。



2.1 案例一:蓝湖项目权限交互设计


下图是蓝湖的项目成员权限设置界面。


设计目的主要是帮助用户高效设置项目团队成员具体的权限。权限功能设计是基于角色的访问控制RBAC模型,即围绕用户、角色和权限三者展开设计。用户是指该项目中具体的成员,角色是指超级管理员、管理员、编辑者、查看者,权限则是指具体的项目权限项,如创建、删除项目、编辑画布、删除团队成员、移交团队。不同的角色,其权限范围不同。


同用户和权限直接关联的功能设计方案相比,通过引入角色,超级管理员无需给用户单独设置具体的权限项,一键完成,可有效提高权限设置效率。



图:蓝湖项目团队权限设置


围绕给用户设置权限的目的,可拆分任务为创建权限、分配权限和使用权限。


蓝湖将创建权限和角色的权限项这一复杂逻辑转移至系统,由系统设定好超级管理员、管理员、编辑者和查看者四种角色,并赋予每个角色对应的权限项,用户只需要针对具体用户设置角色即可,进一步提升了给用户设置权限的效率,让用户权限设置变得更加简单易用。


此外,邀请用户加入项目,默认首选项是查看者角色。


为什么?因为大多数场景下,用户邀请的项目新成员只需要查看,所以默认首选项可以设置为查看者角色,提高了用户邀请新成员加入项目的权限设置效率,如需变更权限,则点击变更角色即可。


小结:

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



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


下面以笔者负责的T-PaaS平台用户权限交互优化为例,阐述如何在复杂的权限逻辑下提升交互体验。


首先,需求来源于用户反馈,具体需求是用户在新建权限时,交互效率低下,可用性差。


下图是最终确定的交互设计方案,下面具体解释一下为什么这样设计,以及是如何想到这样的设计方案,这样的设计给用户带来的价值是什么,以此提炼出可提升权限交互体验的一些思路和方法。



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


整体设计过程分三个阶段,分别是定义问题、解决问题和输出交互原型设计方案。


阶段一:问题诊断。分析用户痛点,明确具体要解决什么问题。


你是怎么知道体验不好的?为什么不好呢?所以要先发现并验证用户需求痛点。可以通过分析用户心智模型,同线上的设计模型对比匹配,找到并验证用户具体的使用痛点,而不是根据设计师自身的经验去分析用户痛点。



图:模型匹配


用户心智模型分析


通过与产品经理详细沟通得知,用户权限功能的使用者是系统管理员,只有系统管理员才可见用户权限功能模块,所以锁定目标用户是管理员。用户需求场景是:管理员给系统用户设置权限时,通常是分配多个服务的权限,而每个服务又包含多个资源权限。


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


线上设计模型分析


线上的权限设计是引入权限组,权限组关联具体的服务权限项设置,但是权限组和具体的服务权限是分开创建的。具体交互路径是:管理员新建权限时,每次只能选择单个服务并设置对应权限,创建完成后保存。如需新权限,则重复新建权限并保存。最后是新建权限组,从已创建的权限列表中选择已设置好权限的服务,如下图所示。



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


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


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


因此,确定设计目标是提高管理员新建权限的效率。


阶段二:解决问题


围绕设计目标——提高新建权限的效率,根据用户具体的使用痛点,交互路径长等问题,我们可以缩短其交互路径,合并单个服务权限的创建,让管理员一次性设置所需服务的权限,交互步骤缩短至三步完成。


所以,变更后的交互方案是用户新建权限,批量选择所需服务并设置对应权限,完成权限创建,步骤如下图所示。



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


依然围绕设计目标,再继续拆解管理员新建权限的任务。我们将管理员新建权限的任务过程细分为选择服务前、选择服务时和选择服务后三个行为节点,构思交互方案。





选择服务前,需明确设计目的是如何帮助用户找服务。有哪些服务?用户找服务的目标是否明确?服务名称是否易识别?根据什么方式排序便于查找服务?用户常设置哪些服务?大概从这几方面思考设计策略,帮助用户选择所需服务。而具体该如何解决这个问题,则需要深入了解当前权限具体的业务逻辑和用户找服务的需求。


权限业务逻辑如下:

1)层级关系是服务-集群-应用-实例,应用空间与服务是并列关系,集群、应用、实例存在多个的情况。

2)服务的功能权限:查询、增加、删除、编辑、查看。

3)服务项56项,有新的服务时会递增。

4)字段有权限名称、描述、服务项权限设置


所以,我们从以上权限逻辑关系和数量范围,可以确定的是目前服务数量是有限的,根据信息优先顺序,先展示权限名称,再展示服务权限设置,服务的资源条件使用多选树状结构展示,既清晰表达资源层级关系,又易于实现,如下图所示。



图:具体服务的资源条件设置


而且,服务权限设置模块的下方已无内容。综上,权限设置采用列表平铺的方式全部展示,一目了然,查找服务效率高一些。


而用户找服务目标是明确的,由于服务名称多为英文字符,也无法确定哪些是常用服务,所以考虑列表采用按照服务名称首字母A-Z的有序方式排列,使用列表索引方式帮助管理员查找服务。因为用户在找服务的场景下,主要是依赖服务名称查找,找东西本身是有记忆成本的,因此,服务名称的定义、列表的排序方式是需要我们设计师深入思考的机会点,不要让用户思考。


当用户选择服务时,只需勾选即可。但是需要考虑点击区域和服务名称如何展示。选择服务后,则需要考虑用户具体要设置服务的哪些权限,如何设置具体的权限?可以根据大多数的场景提供默认功能权限的首选项,减少操作,提高效率。


此外,T-PaaS权限设计也使用了RBAC模型,平台用户对应的就是模型中的用户,权限组(权限集合)对应的是角色,服务权限对应的是模型中的具体权限。


小结

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


以上即为新建权限交互优化的思考过程和交互体验可思考的设计机会点,仅抛砖引玉。


更多的原理分析,将在下篇文章中详细道来,敬请期待~



共0条评论