软件分析与设计笔记 02：设计思维、用户驱动与数据驱动

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

贯穿案例：片区家电维修派单系统。这一篇是全系列的方法论底座 —— 后面 04 起的每一条需求，都遵循这里的判断方式。

0 从一个翻车案例说起

0.1 客服要的是「一张大表」

贯穿案例里的第一次访谈，客服小林说：

「我希望打开就能一眼看到所有工程师这周的排期，一张表全铺开，我一眼就知道谁有空。」

团队觉得这个诉求很具体、很合理，于是做了「全片区排期总览」页：一张表、40 行工程师 × 7 天、格子填满颜色。上线一周后，这个页面的使用率极低 —— 小林还是回去打电话了。

0.2 数据里的真实行为

而工单数据说的是另一件事：小林的真实行为是每天只在早上一小时看排期，而且她真正在找的不是「谁有空」，而是「谁能修这个型号、且离客户最近」。她平均要在 3–4 个候选人里挑一个，挑完还要打电话确认。

问题出在哪？小林没有说谎，团队也没有偷懒。问题在于：她给出的是她想象中的解决方案，而不是她真正的问题。她要解决的问题是「我怕派错人、派重了」，而「一张大表」只是她脑子里能想到的一种做法。

这个案例里藏着这一篇要讲的全部张力：光听用户说不够，光看数据也不够。

1 设计思维（Design Thinking）在这里指什么

先澄清一件事：设计思维不是「把界面做漂亮」。在这个语境下，它是一种开发解决方案的整体方式，共同点是：

1. 先理解人和场景，再定义问题，最后才想方案；
2. 整个过程是迭代的，允许回头推翻前面的结论；
3. 它的核心主张是：问题定义的质量，决定了方案的天花板。

第 3 条特别值得记住。上面那个案例里，团队不是缺创意，而是把问题定义错了 —— 定义成「需要一个总览页」，而不是「小林缺少一个『派对人』的把握」。

问题定义改一个字，方案就完全不同：

第二种方案正是后来真正被用起来的那个。

2 关于「左脑右脑分工」那类说法，我的保留意见

有一种很常见的分类把能力分成两边：一边是 Science / Technology / Engineering / Mathematics，另一边是 UI Design / UX Design / People Skill / Project Management，并暗示这是两种不同的人。

这个二分法在招聘语境里很常见，也容易被当成「我不擅长和人打交道」的借口。我的看法是：它对做软件的人没有指导意义。真实项目里这两边是同一件事的两面 —— 你要和技术讨论可行性（比如供应商接口超时 3 秒怎么办），也要和用户讨论他们到底在做什么（比如小林为什么宁可打电话），缺一边都会让方案悬空。

所以我在笔记里把它当作两类关注点，而不是两类人：一类关注「能不能做出来」，一类关注「做出来有没有用」。

3 用户驱动设计：从「用户说了什么」出发

3.1 它能发现数据里没有的东西

用户驱动设计（user-driven design）以用户的说法、感受和需求作为主要输入，常用手段是访谈、问卷（questionnaire）、观察和参与式设计（participatory design）。

它的价值在于能发现数据里没有的东西：

• 尚未被满足的需求 —— 本例里，小林从没说过「我担心派重了」，因为那对她来说是常识；
• 用户行为背后的动机和顾虑 —— 她反复打电话的真实原因是「看不到工程师当下在不在路上」；
• 用户对现状的不满具体卡在哪一步（也就是痛点，pain point）—— 「不知道谁有空」这句话背后其实是「不知道谁现在能接」。

3.2 它的四个盲点

它的盲点也很固定：

• 用户常把解决方案当成需求讲 —— 就像上面那个「一张大表」；
• 自我报告与实际行为常常对不上 —— 人对自己行为的记忆和描述并不可靠。小林说她「一天有半天在打电话」，实际统计是 20% 的往外拨号；
• 聚焦小组（focus group）会被少数声音带偏 —— 房间里说话最大声的人，往往不是最能代表用户的人；
• 用户描述不出他没见过的东西 —— 问小林「你想要什么新功能」，得到的答案基本逃不出她已经见过的 Excel。

最后一条有个直接的推论：不要指望用户帮你做设计，用户负责提供事实与感受，方案是你的工作。

4 数据驱动设计：从「实际发生了什么」出发

4.1 它的价值：客观、可量化、可比较

数据驱动设计（data-driven design）以行为数据为主要决策依据，手段包括埋点（event tracking）、交易记录、日志、A/B 测试、情感分析（sentiment mining）等。

它的价值是客观、可量化、可比较：

• 能看出真实的行为分布，而不是回忆出来的分布 —— 本例：来电分类统计推翻「半天在打电话」这个自述；
• 改进前后可以对比，结论不靠争论；
• 规模大，能发现小样本访谈发现不了的规律 —— 本例：某个片区的缺料率是别处的三倍。

4.2 它的四个盲点

它的盲点同样固定：

• 只记录已经发生的行为 —— 那些「想报修但放弃了」的客户，数据里根本没有；
• 能看出「是什么」，看不出「为什么」 —— 数据会告诉你「全片区排期总览」被跳过了，但不会告诉你为什么被跳过；
• 沉默的用户没有声音 —— 流失客户、放弃注册的人，他们的动机几乎不会出现在数据里；
• 数据本身可能是有偏的 —— 埋点埋错、口径不一致这类问题，比想象中常见（06 篇专门讲这个）。

5 两者的交集：data-informed design

5.1 区别在「数据是决策者还是输入之一」

真正可用的落点是把两路输入合起来，通常叫 data-informed design（数据知情设计）。

注意它和 data-driven 的区别：data-driven 把数据当决策者，data-informed 把数据当输入之一。

本例里这个区别很具体。如果只看数据，结论会是「排期总览页没人用 → 砍掉它」；但如果把小林的话也听进去，结论会变成「她不需要看全部，她需要在派单那一刻看到 3 个候选人」。后者才是真正的需求。

5.2 三者的分工对照

一句话概括：数据告诉你发生了什么，用户告诉你为什么，以及还可能想要什么。

6 从数据到设计决策的一条做法

把上面这套落成可执行的步骤，大概是：

1. 先问业务目标 —— 做这件事是为了提升什么？本例：把「问进度」来电从 50% 降到 20%；
2. 找出哪些数据能反映这个目标 —— 这一步会用到不同层次的 analytics（分析）：descriptive 回答发生了什么，diagnostic 回答为什么，predictive 回答可能会发生什么，prescriptive 回答应该怎么做（06 篇展开）；
3. 用定性方法解释数据里的异常 —— 定量（quantitative）数据给出规模和分布，定性（qualitative）访谈给出原因，数据里冒出的「不合理」通常都能在访谈里找到解释。本例：「排期总览页使用率 3%」这个异常，访谈一次就解释清了；
4. 把结论写成可验证的假设，再回到数据里验证 —— 比如「小林担心派错人 → 如果派单时直接给出 3 个候选人（按技能 + 距离排序），她的派单耗时会从 3 分钟降到 1 分钟」。

第 4 步是这套方法里最容易被跳过的：没有写成假设的洞察，最后都只是意见。

注意第 4 步里那个「→ 后面」的半句 —— 它不是修辞，而是验证条件。没有它，这只是一句愿望。

7 「数字人才」这个说法

「数字人才（digital talent）」常被形容成「一种新物种」，意思是既理解技术、也理解业务和用户。

我的理解比较朴素：这不是「什么都懂一点」，而是能在技术和用户之间做翻译。能把用户的一句抱怨，翻译成一条可验证的需求；也能把一个技术限制，翻译成用户能听懂的说法。

本例里这个「翻译」有个具体的样子：供应商接口要 3 秒才返回库存 —— 技术上的说法是「外部依赖有延迟」，翻译成小林能懂的说法是「如果查库存慢了，系统会先让你提交，标注『库存待确认』，不挡你」。同一件事，第二种说法她才知道该怎么用。

前面那个翻车的真正失败点，就是中间缺了这个翻译 —— 小林的说法（一张大表）被直接当成了需求。

8 有效提问：几条能直接用的规则

访谈的效果几乎完全取决于问出了「有效的问题」。我把它整理成几条能在访谈里直接执行的规则：

• 问过去的行为，不问未来的意愿。 「你昨天派单时是怎么找工程师的」远比「如果有个新功能你会用吗」有价值 —— 后者几乎所有人都会说「会」。
• 问「为什么」，少问「是不是」。 封闭式问题（dichotomous question）省时间，但只能验证你已有的假设，不能发现新东西。
• 不要问诱导性问题（leading question）。 「你是不是觉得现在派单很麻烦」已经给出了答案。
• 一次只问一件事。 「你觉得派单时速度和质量哪个重要」是两件事被粘在一起，答案无法解释。
• 用观察校验说法。 小林说她每次都会核对两遍时间，就去看看她实际操作 —— 常常对不上。

还有一条本例里特别有效的追问：「如果不考虑任何技术限制，你最希望哪一步消失？」 这个问题的答案往往直接指向真正的痛点 —— 小林回答的是「打电话问谁有空」，而那正是后来被做掉的那一步。

本节自测

1. 用户说「我想要一个能一次看完所有排期的界面」，这句话里哪个部分是需求，哪个部分是解决方案？
2. 用户驱动设计和数据驱动设计各自最容易忽略什么？各举本例中的一个例子。
3. data-driven 和 data-informed 的区别是什么？为什么后者更难执行？
4. 为什么「如果有个新功能你会用吗」是一个坏问题？换成什么问题更好？
5. 把「小林担心派错人」写成一个可验证的假设（要说清验证的数据和预期变化）。
6. 问题定义从「需要看全部排期」改成「需要快速找到能修这个型号且最近的人」，方案会有什么不同？
7. 「数字人才是能在技术和用户之间做翻译」——用供应商接口延迟 3 秒这件事，给出两种说法。

参考答案

1. 需求是「我怕派错人、派重了」这个担心；「一张大表」是他想象出的解决方案。用户给的是方案，不是问题（§0.2）。
2. 用户驱动最易忽略「自我报告与行为的偏差」（小林说半天在打电话，实际是 20% 往外拨号）；数据驱动最易忽略「为什么」与「没发生的事」（总览页使用率低，但数据不会告诉你为什么，也看不到那些放弃报修的客户）（§3.2、§4.2）。
3. data-driven 把数据当决策者，data-informed 把数据当输入之一。后者更难是因为两条腿都要有人做（既要做数据，也要做访谈），成本更高（§5.1、§5.2）。
4. 因为几乎所有人都会回答「会」 —— 它问的是未来意愿，不是过去行为。换成「你上次派单时是怎么找工程师的」，得到的是可验证的事实（§8）。
5. 「小林担心派错人 → 如果派单时直接给出 3 个候选人（按技能 + 距离排序），她的派单耗时会从 3 分钟降到 1 分钟」。后半句是可测量的验证条件（§6 第 4 步）。
6. 前者会做出「40×7 的大表」，后者会做出「按工单筛选出 3 个候选人的面板」。问题定义改一个字，方案完全不同（§1）。
7. 技术说法：「外部依赖有延迟」。用户说法：「查库存慢了，系统会先让你提交、标注『库存待确认』，不挡你」。后者小林才知道该怎么用（§7）。

术语表