腾讯5000字干货！深度分析B端产品设计中的「用户角色」

1. 前言

作为体验设计师，用户永远是我们最关注的部分。对于 C 端产品，我们常常绘制用户画像进行分析；而 B 端产品由于特有的复杂业务性质，用户更多通过「角色」的概念与系统进行链接。因而 B 端用户角色的分析对于产品设计有着更大的意义。

在我近期参与的 B 端项目中，遇到过这样的问题：

无关功能对用户造成了干扰

有用户反馈，某 CI 产品的 A 功能他并不需要使用，却占据了界面的核心模块，造成了一定的干扰；另一类用户则表示他只需要 A 功能，其他完全不关心，所以觉得现有产品形态太过复杂了。

事实上，这两类用户的确存在不同的业务需求，这决定了他们使用产品时的目标和路径。B 端产品尤其注重效率和目的性，与业务无关的内容通常也并不该引起用户过多关注，否则将影响用户的操作流畅度和整体体验。

不同角色的用户操作路径交错无序

另一款面向游戏营销活动的管理平台，也存在类似的问题。尽管平台划分了「运营中心」和「开发中心」两个模块，但在经历多轮快速迭代后，有大量运营管理操作杂糅在了开发中心流程中，并未真正解耦合。这使得运营用户需要在两个模块之间反复横跳，操作路径不清晰。

这些问题都源于前期对用户的分析不够透彻，缺少业务流程中针对不同用户的差异化设计。而「用户角色」的概念在这里能更明确地定义各类用户的分工和目标，有效形成业务闭环。

2. 关于用户角色

根据拉里·康斯坦丁 (Larry Constantine) 的定义：用户角色 (User Role) 是一种抽象的概念模型，是对一类用户及其问题之间关系的定义，包括需求、兴趣、期望和行为模式。

可见「用户角色」和「用户」是完全不同的概念、不同的意义——

1. 角色是抽象的，用户是具体的
2. 角色表示的是一种身份和逻辑关系，用户表示的是切实、独立的个体

角色建立在用户与问题/业务/系统之间，帮助我们概括两个问题：

① 业务需要什么用户做什么事；② 用户希望如何完成 Ta 的业务。

当然，C 端产品也有「用户角色」的概念，只是一般比较宽泛，不会显式强调出来这一名词。

比如教育类 APP，显而易见就有「讲师」和「学员」两种角色，只不过在设计研究中，角色的概念通常直接融入到用户画像里进行描述了。

从宏观意义上，C 端与 B 端的「用户角色」可以说并无不同，因为不管 C 端 B 端，我们都需要通过分析不同角色的目标来有针对性地拆解问题，解决用户痛点，完成体验设计；但从具体的操作思路上，二者还是有区别的。

我认为一个比较大的区别在于：

C 端用户角色是「外驱」的，由外部条件和场景影响用户行为，从而创造用户画像；B 端用户角色则是「内驱」的，是业务由内而外赋予用户角色的定义。

如何理解这两个词呢？

C 端在做体验分析的时候，更多是通过场景来对用户进行观察剖析，然后才会产生相应的角色，这些角色很多时候也不会有太明确的边界。

比如高德地图的驾车导航最近出了「新手模式」和「标准模式」，产生了「新手司机」和「老司机」两种角色。其实这一变化就是基于两种用户场景给出不一样的播报体验，而基础的用户目标和设计策略本质上还是一致的。

反观 B 端则是以业务为核心，由业务直接决定了用户角色的存在和定义，而具体的单个用户个体我们几乎不再关心了，哪怕去做用户调研、访谈，视角也是围绕“这类角色的用户遇到什么问题、如何解决”等等。

B 端的用户角色具有很强烈的边界，比如常见的 OA 审批，提单者和审批者的操作流程完全不一样，他们的目标也不一样，前者追求简单快速，后者追求安全准确，那么设计时的关注点也会大大不同。

3. 为什么要分析用户角色

业务层面

用户体验设计的根本目标就是解决「用户」的问题，而 B 端产品除了面对人，还与复杂的「业务」息息相关。「用户角色」常常就是链接用户与业务的一种逻辑概念。

正是由于 B 端产品具有显著的业务特性，设计师在分析逻辑、处理用户体验问题时，首先要明确「业务场景」。不同场景下，用户的体验目标和任务路径有很大差异，这就需要对用户角色有清晰的认知。

另一方面，设计师需要有同理心，那么我们对用户角色进行分析的过程，同时也是我们开始用同理心站在业务视角去理解用户的过程。

用户角色的分析对于建立心智模型有很大帮助，只有对角色有了充分的理解和认识后，才能产生同理心，做出真正有价值、受人认同的设计方案。

技术层面

B 端产品中的角色权限系统是必备的基础能力，这也使得「用户角色」在 B 端的产品设计中更具研究意义。

这是典型的 RBAC 权限结构，源于计算机数据库系统，用来管理用户在操作使用时的权限，也就是通过角色来约束哪些用户能访问什么、变更什么。

在这里「角色」同样不是一种「实体」，而是一种「关系」，它的作用是解耦合。

在计算机的世界里，天然存在「权限」的课题，因为不可能每个用户都拥有完全的权限；而如果没有角色这个中间层，那么系统管理员需要对每一个来访用户单独配置对应权限，显然是很低效的做法。

角色就把这层关系进行了松绑，因为角色是有限的，只要定义了角色所拥有的权限，无论加入多少用户都只需赋予其角色即可。另外，当权限分配发生变化时，也只需对角色进行调整，不必每个用户都排查一次，维护成本也大大减少了。

B 端常见的权限中心设计，必定会接触到这一逻辑结构。目前大部分的 B 端平台也都是采用这套权限管理机制的，属于平台的基础能力。

某一角色的用户在平台中能做什么、怎么做，一定程度上已经由权限系统进行定义和限制，那么设计师就更应该全面掌握各类角色所处的背景，明确业务流程中每个环节所参与的角色，从他们的视角中挖掘操作体验的问题。

比如常见的运营 SaaS 平台中会有「开发者」和「运营者」两种角色。哪怕在同一业务场景中，这两种角色的用户认知习惯和操作流程都会不同，设计师就需要针对角色的目标进行深入分析。

由此可见，相比 C 端，在 B 端的体验设计中将更有必要面向「用户角色」进行设计分析。

4. 用户角色有哪些特征

作为一种技术性的抽象模型，用户角色有别于人物模型或用户画像 (Personas)。人物模型是一种比喻模型，它们被构造为类似真实的用户，更像身边的普通人。而用户角色是抽象属性的集合，通过背景、特征和指标来综合表现。

具体而言，人物模型会尽可能真实地描述一名用户的性别、年龄、所在城市和日常习惯偏好；而用户角色则并不纠结这些细节，而是把构建的精力放在业务特性中，沿着关键决策链来划分用户群体。

那么，结合理论资料及 B 端领域的实践经验，我归纳了「用户角色」的如下三个特征：全覆盖、差异化和收敛性。

全覆盖

覆盖，指的是用户角色的覆盖范围。我们在初期对角色进行分组定义时，必须涵盖系统中的每一类角色，从而保证业务闭环的完整性，避免流程断裂而跑不下去。

比如上图所示三种角色，他们共同完成了产品上线所需的三个核心环节，缺一不可。

再比如开篇提到的开发运营工具，我们知道显然存在「开发者」和「运营者」两种角色，但除此之外，经过洞察会发现还会有部分用户属于「测试人员」或「产品经理」，同时也必定会有各级别「管理员」权限的角色。所有这些角色的配合才能构成完整业务的协作流，而每个角色所处的环节都是设计师需要换位分析的。

因此，设计师需要在分析问题之前先明确所有角色，保证全面覆盖到业务。

差异化

用户角色与人物模型的其中一个鲜明区别，就在于用户角色有着更为明确的边界。由于业务分工的明确性，也由于系统权限的客观定义，角色和角色之间定有比较清晰的分界线，使得用户目标、操作流程等都存在显式的差异化。

比如腾讯英语君通过初次使用时选择身份来提供差异化的服务，让不同角色的用户能更快更好地达成他们使用 APP 的目标。

又比如我最近参与的 CI 产品，两类用户对于产品的诉求完全不同，正是因为他们的角色有明确的业务分工，需要完成的任务有差异性，因此需要针对他们所处的场景和目标，具体问题具体分析，定制符合各自预期的体验方案。

收敛性

我们知道，C 端产品在做人物模型会尽可能丰富地展现用户的多面性，以发散的视角去还原一个「真实的人」。但 B 端分析用户角色时明显相反，受限于业务的既定范围，用户角色天然具备收敛性；简言之：B 端用户一般不会进行与其角色目标无关的操作，也不太会有额外的个性化的想法。

好比一款 OA 系统，普通员工一般无法进行审批，所以审批相关的操作流程不需要引起他们关注；而即便是审批者或管理员，在这个系统中也不会凭空希望增加评价功能的体验，或增强审批过程的趣味性，因为他们角色的业务目标是高效准确地完成批复。

5. 如何针对用户角色进行设计

B 端产品中，角色定义通常已经由业务所决定，但我们在设计中仍然需要关注各角色的特点和任务目标，可通过同理心地图等研究工具进行拆解分析，解决不同用户路径中存在的体验问题。

业务边界

站在内部视角，我们知道用户角色是源于自身业务属性的。不同角色之间体现了差异性，也就存在较为明确的业务边界。当我们能清楚划分这些边界时，我们也就可以梳理出某一角色在某一场合下既定的操作流程。

那么，设计师需要做的就是结合这些业务特性，确定各角色的用户能做什么、不能做什么，从而排除冗余的信息和操作，提高信噪比，聚焦任务目标。

我比较常用的工具是泳道流程图，在一些多角色协作的业务场景中，泳道的分隔线就提供了直观的边界，我们可以清晰梳理出协作的每一个环节，以及每个角色所关注的信息。

以前面提及的 CI 产品为例，第一类用户的业务操作不涉及 A 功能模块，但第二类用户反而以 A 功能为核心任务，这就是角色之间的差异性。当我们清楚了解这些边界之后，就可以寻求更优的方案，使用户不被过多无关信息所干扰，操作流程就会更聚焦也更顺畅。

同理心地图

站在外部视角，带着用户的眼光进行审视，我们可以运用同理心地图等用户研究工具，代入角色去了解目标用户。

但值得注意的是，「同理心」对于抽象的角色模型其实是不起作用的。所以我们仍然需要在用户角色基础上进一步开发出人物模型，多维度表现用户目标及复杂行为模式，为同理心地图提供更全面具体的情境。

来源：《Updated Empathy Map Canvas》——Dave Gray

在《About Face》中也提到，用户角色是抽象概念，也存在着局限性。

换言之，我们在审视用户角色的时候，并不会认为那就是一个具体的人、一个真实的用户。所以它并不等同于用户画像。

那么我们在 B 端项目中进行了用户角色分析后，仍然有必要结合具体的场景和行为进行讨论。比如，同一个用户很有可能同时属于「开发者」和「项目管理员」，那么他的诉求将会更为具体也更为复杂。

6. 案例浅析

那么，对于开篇提到的两款产品，在设计分析阶段如何找到切入点呢？

案例之一是一款 CI 产品，集成了测试自动化、运维可视化的代码交付部署平台，并能帮助业务上线前高效收集体验反馈。

产品分为两大功能模块：代码部署的流水线管理、业务内测安装体验，由此产生两大类用户：开发运维用户、产品体验用户。

问题就在于，目前移动端的信息架构划分了四个板块，A 作为首页，推送的都是与 B 板块相关的产品体验内容，而只有 C 是面向运维的流水线管理功能。于是就收到了前述的一些用户反馈。

为什么会出现这样的问题呢？因为产品在迭代过程中只是粗暴地堆砌功能，没有先对用户角色进行拆解分析，于是所有的用户都看到完全一样的信息，却并不是他们最想看到的内容。

于是我从「收敛性」的角度进行用户分析，找准不同角色的目标。

结合反馈和进一步访谈结论，可以定位到一个关键的问题：缺少针对不同用户角色的 APP 首页差异化设计。因无法将不同用户快速引流到他们预期的功能板块，从而阻碍了他们处理业务的操作流程。

针对这一问题，可以将设计目标定义为「精准」——让用户在自身角色场景下更轻松、更准确地找到当前需要处理的任务。

通过用户分层设计，减少与角色无关的信息干扰。开发运维用户的业务操作不涉及 A、B 功能模块，但业务体验用户反而以 A 功能为核心任务，这就是角色之间的差异性。当我们清楚掌握这些边界之后，就可以寻求更优的方案，使用户不被过多无关信息所干扰，操作流程就会更聚焦、更顺畅。

案例二是面向游戏营销活动的开发运营平台，通过统一的自研的前端开发框架，实现游戏项目内嵌的运营活动，使不同游戏业务都能复用相同的开发资源，快速发布、运营游戏内营销活动。

这个项目处于快速迭代功能的阶段，也就是先后追加功能模块的过程。在这个过程中就出现了“熵变”，信息架构越来越混乱无序。主要体现在平台的两个主要板块：运营中心和开发中心。

从字面可以理解，两个板块分别面向运营人员和开发人员。然而，当前运营中心里只有运营数据以及第三方运营平台的入口，而运营人员日常高频操作的应用发布、管理，却全部集中在开发中心里。

造成这一困扰的原因也是初期追求快速迭代，希望将开发中心已实现的一套功能直接对运营人员开放，协同完成开发和发布。

而后果就是，运营人员需要在两个板块间反复横跳，操作路径无序又冗长；而且大多数情况下需要深入到看起来与角色无关的开发中心里管理他们的运营业务，显然对新手非常不友好。

从用户角色的「差异化」入手，通过对角色分析和信息架构的重新梳理，可以得到设计目标就在于「聚焦」——依托业务边界，使用户聚焦关注自身角色的业务流程。
前面提到用户角色具有业务边界，那么边界外的信息就应该尽量减少，从而提高认知和操作效率。

进一步推导设计策略：通过对运营人员角色的流程疏导，整合搭建运营中心的信息架构，将运营业务从开发中心中抽离，从而简化运营操作路径。

7. 总结

「当(某角色)用户使用产品某项功能的时候，他们是为了完成某个特定的任务(到达某种目标)」

一旦理解了这句话，并在设计过程中切实围绕场景、角色、目标去深入分析，我们的设计方案将会更有效地解决体验问题、提高业务效率。

欢迎关注作者微信公众号：「腾讯设计族」