软件分析与设计笔记 05：范围界定（用户侧）：用户画像与客户旅程图

这是我在学习软件分析与设计时整理的系列笔记。概念部分是我按自己的理解写的，示例场景与图示都是自己编、自己画的。理解有偏差的地方欢迎指出。

贯穿案例：片区家电维修派单系统。04 篇做了预习，这一篇做范围界定（谁来用、用在哪、什么不做）。

0 「所有用户」是个陷阱

需求讨论里最常见的一句话是：「这个功能所有用户都会用到。」

问题在于，「所有用户」根本不存在。在贯穿案例里，「客户」这个词至少包着三种完全不同的人：

• 赶时间的上班族 —— 只想知道「今天下午能不能来」，能请假等他；
• 独居老人 —— 关心「师傅靠得住吗」，宁愿等也要熟人；
• 替父母报修的子女 —— 人在外地，只能远程盯着进度。

面对同一个「报修」页面，他们焦虑的点完全不同。为所有人设计，通常等于为没人设计。

范围界定（scoping）的第一步，就是先做一次用户分群（user segment），再从里面挑出真正要服务的那几个。

1 先把边界划出来

1.1 两份清单

在谈用户之前，先明确项目的边界，通常写成两个清单：

• in scope（在范围内）：这次要做的业务、角色、渠道；
• out of scope（在范围外）：这次明确不做的部分。

贯穿案例的第一版可以这样写：

1.2 为什么 out of scope 更值钱

第二个清单比第一个更值钱。项目后期一半的争执，来自「这个当初是不是说了要做」—— 如果一开始就写清「本期不含在线支付」，后面就不需要争。

而且这张表有个隐蔽的好处：它逼你说出「本期做不到的事，用户怎么办」。比如「不做在线支付」，那就要在界面上写清「费用由工程师上门收取」，否则客户会来问。

边界与 scope boundary（范围边界）是同一个东西的两种叫法：它划的是责任范围，不是能力范围。

2 用户画像（Persona）：五个要素

2.1 五个要素

Persona（用户画像）是一个虚构但典型的用户档案。它的价值不在于「像真人」，而在于让团队讨论需求时有一个具体的人可以指。

一份有用的用户画像至少包含五个要素：

2.2 「行为」这一栏最容易写废

「行为」这一栏最容易被写废。常见的错误是把用户画像写成人口统计表：35 岁、女性、本科学历、年收入 8.5 万 —— 这些信息很难指导任何设计决策。

能指导决策的是行为：他上一次做这件事时的实际操作是什么样的。

对比一下两种写法：

右边这一栏直接告诉了你三件事：她的工作记忆靠 Excel 和便签本、她必须串行确认、她会因为联系不上而中断流程。每一条都能变成设计输入。

3 客户旅程图（Customer Journey Map）

3.1 一列里放什么

Persona 说清「他是谁」，Customer Journey Map（客户旅程图）说清「他经历了什么」。它把一件事拆成连续的阶段（stage），每一列包含：

• 阶段 —— 报修前 → 等待上门 → 上门中 → 上门后；
• 他在做什么 —— 具体动作；
• 他在想什么 —— 每个阶段的顾虑和疑问；
• 触点（touchpoint） —— 他在哪个界面、渠道或人那里接触到你；
• 情绪（emotional curve） —— 把每个阶段的感受高低连成一条线。

贯穿案例里，客户这条旅程填出来大致是：

3.2 情绪曲线才是重点

最后那条情绪折线是整张图的重点。它把「哪里让人不爽」从模糊的感受变成看得见的位置 —— 图上情绪最低的那一格，就是最值得先动手的地方。

注意上面那张表里「等待上门」这一行的触点写的是「无」。这是个很重要的发现：不是这个环节做得不好，而是这个环节根本不存在 —— 客户付完报修电话之后就进入了信息真空。这比笼统地说「客户体验差」有用得多，因为它直接指向了「进度可见性」这个具体缺口。

3.3 旅程图同时也是用例图的底稿

这一点和考试直接相关。样卷里有一问要求「用客户旅程图，标出每个阶段的期望由哪些用例回应」。那张表其实就是把上面这张旅程图的最后两列，配上用例名：

写完旅程图，用例图的骨架就有了。这也是为什么这两件事在课程里挨着讲 —— 它们本来就是同一份材料的两面。

4 只挑关键的那一两个

用户画像不是越多越好。常见的做法是分主要用户画像（primary persona） 和次要用户画像（secondary persona）：主要的那一个决定核心流程怎么设计，次要的只要求「不被妨碍」。

贯穿案例里，主要画像应该是客服小林，而不是客户 —— 这个判断可能反直觉，但理由是成立的：系统的核心动作是派单，而派单是小林在做。客户是受益者，但不是操作者；如果按客户的画像去设计，会做出一个漂亮的查询页，而派单依然靠 Excel。

次要画像给客户和工程师：客户只要求「能看到进度」，工程师只要求「别给我排冲突的单」。

如果团队能画出五个同样重要的用户画像，通常说明还没有做出取舍 —— 访谈取样时要按类别挑代表性用户（representative user），而不是随手找最方便的人。

5 从这两样东西推到需求

5.1 从画像到需求的三步

有了 persona 和 journey map，往前推需求的路就清楚了，大致三步：

1. 找情绪最低点。 定位到具体阶段与触点 —— 本例是「等待上门」，触点是「无」；
2. 问为什么低。 回到用户的想法栏 —— 「到底几点到？我要不要请假？」；
3. 写成可验证的需求假设。 「客户在等待阶段的主要焦虑是不知道时间 → 如果提供工程师实时位置与预计到达时间，客户来电询问进度的次数会下降」。

第 3 步是这三步里唯一有交付价值的：它同时写清了要做什么、以及怎么判断有没有效。

注意第 3 步里那个「→ 后面」的半句。它不是修辞，而是验证条件。没有它，这只是一句愿望；有了它，你才知道上线后该看哪个数字。

6 常见的四个错误

• 把 persona 写成简历。 堆人口统计信息，看不出行为特征，对设计没有帮助；
• journey map 只有流程没有情绪。 那它就退化成一张普通的流程图，失去了「哪里最痛」这个信息；
• 只画「应该发生」的旅程。 旅程图要画用户实际怎么走，包括那些变通做法（workaround）—— 本例里客户为了知道几点到，会再打一遍电话，这个「重复拨打」就该画进去；
• 画像和需求脱节。 画完贴在墙上，后续文档再也用不到 —— 好的用法是让每条需求都能指回某个画像的某个痛点。

本节自测

1. 为什么「所有用户都会用」这句话对设计没有帮助？本例中「客户」至少可以分成哪三类？
2. in scope 和 out of scope 两份清单，哪一份在项目后期更有价值？为什么？
3. 用户画像的五个要素里，哪一栏最容易被写成无用信息？应该改成记录什么？
4. 客户旅程图里的情绪曲线解决了什么问题？本例情绪最低的那一格有什么特别之处？
5. 把「客户老是打电话问几点到」改写成一条可验证的需求假设。
6. 为什么本例的主要用户画像应该是客服小林，而不是客户？
7. 客户旅程图和用例图是什么关系？

参考答案

1. 因为「所有用户」不存在，为所有人设计等于为没人设计。本例「客户」至少分三类：赶时间的上班族（只关心能不能今天来）、独居老人（关心师傅靠不靠谱）、替父母报修的子女（只能远程盯进度）（§0）。
2. out of scope 更值钱。因为项目后期一半的争执来自「这个当初说了要做吗」，写清不做什么能直接消掉这些争执；它还逼你说出「做不到的事用户怎么办」（§1.2）。
3. 「行为」这一栏。最容易写成人口统计（年龄、学历、收入），这些指导不了设计。应该记他上一次做这件事的实际操作，例如小林怎么翻便签本、怎么打第二次电话（§2.2）。
4. 它把「哪里不爽」从模糊感受变成看得见的位置。本例情绪最低的是「等待上门」，特别之处在于它的触点是「无」 —— 不是做得不好，而是这个环节根本不存在，客户进入了信息真空（§3.2）。
5. 「客户在等待阶段不知道工程师何时到达 → 如果提供实时位置与预计到达时间，来电询问进度的次数会下降」。后半句是验证条件，没有它只是愿望（§5.1）。
6. 因为系统的核心动作是派单，而派单是小林在做。按客户画像设计会做出漂亮的查询页，而派单依然靠 Excel。客户是受益者但不是操作者（§4）。
7. 旅程图的最后两列（期望 + 回应方式）配上用例名，就是用例图的骨架。样卷要求「用旅程图标出每个阶段由哪些用例回应」，那张表正是两者之间的桥（§3.3）。

术语表