https://www.uisdc.com/b-end-user-portrait
用户画像的价值在于被使用。当越来越多的团队使用用户画像，那么用户画像就会越来越像一个真实的用户，帮助团队从用户的角度出发去设计软件。
最近和产品经理又对撕了 N 次，心好累～
对撕的起因很简单，针对某些设计细节点，他认为「应当如此如此」，我认为「应当如此如此」………
于是我们俩如此来如此去，却猛然醒悟到一件重要的事情，不管我们俩怎样认为，我们都不属于产品设计的「目标用户」，我们的经验并不等同于用户的期望和想法。
为了避免以后反复发生此类无意义的争论，我们决定针对正在跟进的教育 B 端业务制作用户画像。
因涉及到教育产品的商业机密及受访者的隐私信息，下文中的画像案例已进行脱敏处理，对部分信息进行调整，请大家更关注其中涉及的方法，不要拿来直接使用哦～
文中所用 Sketch 模板地址：https://pan.baidu.com/s/1qmz4pZ40a_H2P0RkbV24wA
明确业务性质
首先，我们在开始制作画像前，要先明确画像所服务的业务。
- 业务性质：教育行业 SaaS 产品
- 目标客户：终端用户
- 服务内容：为教育企业（学校）提供解决方案
商业模式特点：有明确的目标客户（学校）；客户标杆效应明显（教育业内有影响力）；商业模式多元化（与学校、与学生、与家长都有可能构建交易关系和连接方式）。
明确画像意义
用户画像，是教育 B 端产品目标客户（学校）及其多个核心角色共同构成的画像。可以用于帮助我们解决版本设计中的如下问题：
解决需求定位模糊问题，帮助我们了解目标用户信息；
- 解决信息架构混乱问题，帮助我们更明确需求功能的合理性和优先级；
- 解决需求争议问题；
- 解决可用性测试问题，帮助我们锁定合适的测试用户；
-
创建画像
1. 识别关键画像
我们的用户画像需要体现目标客户（学校）以及拥有决策权的关键角色信息。
学校是我们的目标客户，我们进行产品设计的目的之一是要帮助学校达成目标，因此我们需要在用户画像中明确以下信息。
学校标识
包含学校 Logo、 名称以及公私性质。
上述元素应当简单并且容易记忆，可以形成快速的视觉记忆。
学校背景
该校的行业地位，学校规模及包含的年级。
学校目标
你的产品希望解决和能够帮助到学校的那部分，这也是我们必须满足校方的条件。
如下某中学范例：
原来在为你设计：我的 B 端用户画像构建总结
产品设计的另一个目的是为产品的实际使用者提供价值。使用者的接受度越高，我们跟学校之间的关系就越好，也能显著降低学校更换供应商的可能性。
但在学校的产品运转流程中一直存在诸多角色，只有在决策链上的角色，才是有价值的关键角色。
我们首先应该考虑希望获得谁（角色）的认同，然后再研究他们的个性。这就是为什么职位信息需要摆在第一位，它揭示了这个角色在学校组织结构中的地位，他们拥有什么样的经历，以及承担什么样的责任。
当我们想卖给公立学校时，我们首先要打动目标学校所属的教育局，因为设备采购需要教育局来出资购买，其次才是公立学校的校长，因此在初期购买阶段，公立学校决策链中最重要的是教育局和校长；而到了私立学校，因为出资人不是教育局，私立学校的校长会更具决策权，因此在初期购买阶段，私立学校决策链中最重要的是校长。
因此在销售阶段会更关注教育局/校长的角色画像。
那么在续费阶段呢？教师和学生的意见会开始在该阶段变得重要起来，因为他们是最终的使用者，是产品的检验者，他们将亲自检验这款软件是否真的适用。通常在学校决定购买我们的产品之前，教师和学生没有话语权，但在是否要续费时，他们的话语权比重会开始显著提升。
因此在我们的产品设计阶段，会更关注教师和学生的角色画像，我们现阶段的调研目标也是为了获取这两类角色的用户画像。
下图为公立学校中不同阶段的关键角色：
下图为私立学校中不同阶段的关键角色：
2. 采集角色资料
通过调研方法来收集不同职位角色的客观资料（基础特征、使用情况和使用环境）和主观资料（观点、目的和偏好），以此作为进一步细分的依据。
可通过以下方法采集所需的资料：
后台数据拉取
可以帮助我们利用现有资源搜索所需的客观资料。
罗列以上所需的客观资料类目，以需求的方式交由后端或数据分析师，请求帮助批量拉取现有数据，通过对现有客观资料进行分析建模可以帮助我们构建角色画像的外在行为特征。
定性访谈 确定访谈目标，本次访谈的目的是为了更了解目标用户群体，通过访谈信息来进一步构建所需的用户画像；
- 选择访谈对象，为了构建教师和学生两个角色画像，访谈会主要以教师和学生为访谈对象，每个角色访谈 4～6人；
- 进行访谈，需提前准备问题模版（以上资料类目已罗列）、录音设备、记录表格，并设置访谈员和记录员，进行访问和关键信息记录；
- 将收集到的信息汇总，进行分析建模。
实地观察
- 亲自去学校，坐在办公室内观察老师们的备课/批改行为，并记录他们的备课/批改操作及场景因素；
- 坐在课堂听课，观察老师和学生的课中行为，并记录他们的授课/上课操作及场景因素；
- 将收集到的信息汇总，进行分析建模。
问卷调研
- 确定问卷目标，本次访谈的目的是为了更了解目标用户群体，通过问卷来进一步搜集所需的用户画像；
- 进行问卷设计，尽量以选择题或判断题为主；
- 在学生端进行问卷投放（不可以收集个人信息），或通过运营老师进行线下投放；
-
3. 分析建模
根据角色对访谈对象分组
将收集到的数据大致分类后，根据角色不同对受访者进行分组，例如：教师和学生。
找出行为变量
根据角色不同对受访者进行分组后，把每种角色身上观察到的一些显著的行为列成不同的几组行为变量。
找 4～7 名左右职位相同但不同年级/学校的角色，结合我们的业务目标（周活/降成本），对比同类角色用户的多组行为变量，如下表格教师角色的变量行为整理：
映射访谈对象与行为变量的关系
将角色的行为变量做成一个区间轴，再把访谈对象放到区间轴上对应起来，不需要那么精确，标出相对位置即可，行为变量通常分成两种情况：
一种是连续性，比如教师角色使用我们产品的频率描述是：经常到较少。
另一种则是非连续性，比如教师角色的批改倾向：系统自动批改、学生自批、教师自主批改。
找出共性行为模式
完成映射后，寻找在变量轴上的对象群。如果一组对象聚集在多个不同的变量上，则可以代表一类角色存在显著的共性行为表现（通常每类角色会有2～3个共性行为）。
如上图最右侧的一组角色展示，这一类角色具备的明显的多种共性行为：较少使用智能教学产品、习惯自主批改、对智能教学产品操作不熟练等，而这几点行为具备了必然的逻辑或因果联系，不再是我们个人的假想关联。
不同角色根据其共性行为可以划分出更多的角色类型，如教师可以根据共性显著的态度和年龄来划分，学生可以根据共性显著的成绩和学习能力来划分：
一旦我们找到共性行为，就可以创造用户画像了，在用户画像中利用收集到的各自角色特征构建个性化资料，个性化用户资料可以帮助我们更深入了解用户特征，所处环境，工作强度，日常需求和遇到的问题，这样可以设身处地去理解他们。4. 画像呈现
职位信息和用户资料
建立角色的视觉形象，包含照片、名字、年龄、教育背景、人格特质和思维模式，重点突出态度和工作职责范围。
如下图中的年轻教师角色画像：
角色使用场景
结合使用场景进行故事描述，在描述中体现行为变量等因素，让角色的背景和形象更加鲜活。
如下图的年轻教师角色故事：
角色痛点 & 愿景
描述角色使用智能教学产品时的痛点和愿景，如下图关于年轻教师角色的相关描述：
角色的社会关系
角色们是同一学校的一部分，他们之间存在人际关系和社会关系。考虑角色的社会关系是否有意义时，可以考虑以下两点： 观察到的访谈主体的行为是否随着学校性质或者社会关系发生变化而变化。
- 在他们之间的工作流程或者社会交往非常关键。
5. 最终呈现的画像框架
客户画像模版，包含客户学校内的所有角色类型：
对应角色画像模板：
在团队中使用画像
用户画像通过使用而变得生动。要做到这一点，团队需要了解并能够引用这些用户画像。角色需控制在不超过5-7个，否则很难跟踪和分析用户群体。
我们希望用户画像是稳定的，但是有时候用户研究或者反馈会带来大量的新信息。重新塑造用户画像会带来认知负担，我们可以尝试用一条故事线来推动，比如用户画像中的人物升职了或职务内容发生了调整。再不行，可以尝试用启动会议来介绍这些改变。
在已获取的角色画像中，我们也需要根据场景来对角色类型进行主次区分，也可以考虑增加负面角色，如不爱学习/上课注意力不集中的学生无法视为我们自主学习场景下的目标角色用户。
我们可以将用户画像的描述做成一页纸贴在墙上，这样设计团队成员每天走进办公室就能看到。即便团队成员无法在一起工作，也可以采用以下方法：
- 向团队介绍用户画像。花点时间介绍研究的过程，展示照片给他们看，聊一聊画像的需求，期望，痛点，性格等
- 在需求评审会上使用用户画像。例如「XX 老师会想要这个功能吗？我觉得这个可能会导致 XX 学生在课上分神！」
- 在你的用户故事中使用用户画像。「如果我是 XX 老师，我想要在课堂上能实时检阅学生的作答笔迹，这样可以方便我提前了解学生对知识点的吸收状况。」
- 设计时，花点时间想象一下软件会被用户在工作中如何应用。以上文为例，考虑教师平时习惯如何找到备课文件，但关注是教师的行为，而非软件。
总的来说，用户画像可以帮助设计师跳出自己的需求，了解真正使用产品的人的需求。这个对于终端办公软件来说尤其重要，因为很多软件开发者与产品的用户完全不相似。用户画像的价值在于被使用，当越来越多的团队使用用户画像，那么用户画像就会越来越像一个真实的用户，帮助团队从用户的角度出发去设计软件。
B端设计规范：
从大厂实战中，总结了这份B端产品设计规范网上关于设计规范的文章写得都很专业，但没有区分 C 端产品和 B 端产品，其实同样是设计规范，由于不同的业务场景和不同企业形态存在很多差异。阅读文章>
参考文献：
若有收获，就点个赞吧
0 人点赞
