# 产品思维的基础
LLMS 索引： [llms.txt](/llms.txt)
---
> 来吧，开始吧，开始吧
>
> 那么，说吧，说吧，这到底是什么场景？
>
> — A Tribe Called Quest
如果产品思维有一个核心原语，那就是*场景*。它本质上是一个为了产品设计而组织的用户故事。
来看一个关于密码的场景：
> Darla 是一位退休的婴儿潮一代用户，45 岁才开始使用电脑。她正在本地茶饮店注册账号，以便在线下单。当系统要求输入邮箱和密码时，她选择了“女儿生日 + 儿子名字”，这样容易记住。她大约有 30 个线上账号，因此多数账号都用同一个密码，否则根本记不住；而且她又被建议不要把密码写下来。
你可以猜到后面会发生什么：这家茶饮店发生数据泄露，她的密码（也正是她在银行使用的那个）被泄露。也许暗网上有人买下了她的登录信息，并转走了她的钱。
这个噩梦般的场景揭示了密码体系的问题，但并不完全是产品*内部*某个组件本身的问题。只盯着注册界面、加密协议、安全存储等细节，你很难看到它。但当你写出包含可预见人性弱点的完整故事时，安全问题就会立刻显现。
在本节中，我们将拆解并分析有效场景的组成，并教你如何构建一个好场景。粗略地说，一个场景由“情节”和“角色”组成。我会先展开这两个概念，再给出实操建议。
不过照例，先用一个案例研究来引导讨论。
### 案例研究 {#id7}
Tea++ 是一家拥有 300 家门店的连锁茶饮店。它扩张过快，经营勉强维持，因此公司的目标是在极低预算下尽快提升订单量，避免关店。
Tea++ 有一款流行的移动应用，支持点单体验；通过反馈组件，用户一直在请求“收藏”功能，希望系统能记住偏好、加快下单。软件团队认为这可能是提升订单的低成本办法。
### 第一次尝试：没有场景 {#id276}
我们来看 Bob，一位移动端工程师。他在工作中并不使用用户场景。
Bob 查看了应用反馈组件里收到的用户意见。喝咖啡的用户厌倦了每次下单都要重新设置定制项，也不喜欢在近期订单里翻找。有时想要的商品埋在包含多个商品的订单中，拆分起来很麻烦。
Bob 做了一个与现有应用结构契合度很高的原型（见[图 1-1](/ch1/#coffee_app_mockup)）。他准备在应用底部新增一个 Favorites 菜单项，并增加一个展示用户收藏的新页面。页面右上角有一个 *+* 按钮，用来新增收藏。
**图 1-1.** Bob 展示了他提议的移动应用改动。新增元素以阴影标出。
令人高兴的是，这会很容易实现，因为收藏列表复用了现有菜单组件。用户点击 *Order* 后，将进入现有购物车流程。
新的收藏数据库表按最近购买时间排序，Bob 还给出了（SQL）数据库结构，并注明会按时间建立索引以便快速查询。
```
Table: favorite_items
- created_time : timestamp
- updated_time : timestamp (Index)
- item_id : long
- milk_customization: varchar
- sweetness_customization: varchar
- special_instructions: varchar
```
Bob 还提议把首页“新品广告位”替换为收藏入口，但“New Products”团队否决了这个想法，因为他们需要该位置来推广当季新品。Bob 只得不情愿地把这部分从设计里删掉。
随后召开了大型评审会，大家都喜欢这个设计，尤其因为实现成本低。有人指出，星巴克应用会在近期订单和购物车里提供“心形”按钮，为什么不也加一个可把条目加入收藏的按钮？
但 Bob 反对，称这会让开发周期翻倍，因为改动更具侵入性，比如需要在多个页面新增数据库查询。团队接受了这个判断，项目按原方案构建并上线。
#### 效果平平 {#id8}
几周后复盘数据，有好消息也有坏消息。好消息是收藏功能上线稳定、没有重大缺陷。不幸的是，只有 6% 的活跃用户使用收藏，订单量仅增长 0.3%。
Tea++ 的应用埋点完善，Bob 深挖数据后发现：点击 Favorites 菜单的人很少，而点击进去的人多数会立刻离开。尤其是收藏列表为空的用户，极大概率会直接退出，而不是点 + 按钮。
Bob 想起“心形按钮”的建议，与 Carlos 讨论，提议补上它以提升转化率。但遗憾的是团队优先级已转向月度订阅，短期内无暇开发。大家都在为可能关店而焦虑，Carlos 对他的提案似乎也有些不耐烦。Bob 带着愤怒离开，觉得自己不被允许把产品真正做完。
#### 问题出在哪？ {#id277}
Bob 做对了很多事：倾听用户反馈、追踪指标、收集并分析用户交互；他还控制范围，做出了高效、可达成、稳定的设计。
但他的提案仍然薄弱。评审会上团队提出的问题虽有价值，却不是最根本的。
第一，他跳过了发现（Discover）阶段（我在序言提过的四个阶段中的第一步），直接进入数据库设计。
换句话说，他把一个核心难点在于“产品决策及其与实现约束如何相互作用”的项目，包装成了“实现细节才是最关键”。只是他没有幸运地遇到能看出这个问题的队友。
下面我们看看一个会用场景来思考用户需求的开发者。
### 第二次尝试：引入场景 {#id278}
六个月后，Bob 仍在做订阅功能。此时 Alice（一位资深工程师）被引入来实现 Bob 一直后悔没做的“星巴克式心形按钮”。
她不止于此，她*还*做了“收藏门店”概念。这样一来，常去某家门店的用户可以在结账流程里少点几步，而这一点 Bob 当时完全没考虑，因为他接到的任务只聚焦“收藏饮品”。
第三，她做了 A/B 测试：将首页新品推广替换为一对巨大的“立即下单”按钮，并露出第三个按钮顶部，提示页面可滚动（见[图 1-2](/ch1/#quick_order_mockup)）。这个思路和 Bob 曾设想的类似，但他当时没能说服产品营销团队让出首页空间。
随着时间推移，Alice 的实验表明，这些改动合在一起使转化率提升了 3.8%。由于移动端订单贡献了 Tea++ 一半营收，这足以显著改善利润。拿到数据后，Alice 得以说服市场部门把新品广告下移到前两个收藏项之下，并将实验全量发布。
Bob 几乎没参与她的方案制定，不禁疑惑 Alice 为什么对该做什么有这么准的直觉。她又是如何说服其他人放手去做的？
**图 1-2.** Alice 做了一个可滚动的快速下单页面原型，包含“立即下单”按钮
### 作为启发故事的场景 {#id9}
场景的一个用途，是用来沟通并激发团队。
Bob 发私信问 Alice 她是怎么做到的，Alice 回了一个很有感染力的故事：
> Eliana 是一位忙碌的职场人，每天通勤都会买一杯加豆奶的印度香料奶茶拿铁。某天早晨，她忘了提前下单。开车途中，她按下方向盘上的语音助手键，说：“给我点 Tea++ 的老样子。”她的语音助手 Siri 回复并让她确认金额和门店，她确认了。
Bob 有些困惑：“好吧……但这也不是你最终做的东西啊？”
“我知道。Carlos 觉得做这个太贵了，”她遗憾地说，“他可能是对的。但我想先把标杆设高，展示潜力。我也想讲一个高频场景：在这个场景里，收藏流程不只是方便，而是直接决定用户能不能喝到那杯茶。”
“听起来很酷，不过我当时也觉得我们没有这种时间。”
“梦想本身有价值。”Alice 说，“收藏饮品和收藏门店会让用户以后更容易使用语音指令，前提是我们将来真去做。”
在发现（Discover）阶段，探索多种可能的故事线非常关键。
### 捕捉用户访谈的场景 {#id10}
如果你做过一些用户研究，场景可以是对访谈素材的虚构合成，能够简洁传达常见情境。
Bob 反驳道：“我的意思是，我也可以随便编个故事，让我的方案显得更好。开车时点单真的那么重要吗？”
Alice 回答：“我也挺希望有定位数据来验证这一点。但主要是我访谈了十来位朋友和熟人，甚至问了很多看似琐碎的点单细节。是的，通勤场景反复出现。Eliana 代表的是*在疯狂早晨里忙乱、健忘的人*。”
我们会在[第 6 章](/ch6/#ch06_target_aud)讨论用户访谈。
### 揭示产品缺口的场景 {#id11}
场景也可以用来展示“缺了什么功能”。
“刚才那是我的*改后*故事，”Alice 说，“你要不要看*改前*版本？”
“呃，好。”
她把内容私信发了过来：
> Eliana 是一位忙碌的职场人，每天通勤都会买一杯加豆奶的印度香料奶茶拿铁。某天早晨，她忘了提前下单。开车时，她在停车标志前停下，打开 Tea++ 应用并点进 Favorites。她在列表顶部找到自己的拿铁，点击“Order now”。后车按喇叭，她只好继续前进并专心驾驶。但她确实需要咖啡因，于是到高速匝道口时把车停到路肩。在购物车页，她选择“Order and Pay”。这个页面要求选择门店。地图加载后，她用手指猛戳 Main St. 的图钉并点 OK，然后进入支付页，使用 Apple Pay 完成交易。她放下手机，确认来车后重新并入匝道。
“我明白你为什么做收藏门店了，”Bob 说，“有人提过这个需求吗？”
“有个用户问过，为什么每次都得重选门店。而且当我自己代入、想象自己在车里时，我意识到心形按钮未必是最重要的。”
Bob 深吸一口气：“懂了。无论如何，心形按钮做成了，还是恭喜你。我当时也试着说服 Carlos 投入这块，但他要我做订阅。”
### 揭示摩擦体验的场景 {#id181}
你可以构造故事，来展示使用现有产品的痛点。这个例子里，Alice 设计了一个带一点反讽意味的小故事。
“这个我也有场景，”Alice 说，“它是从用户反馈间接提炼出来的。下面是*改前*故事。”
> Eliana 是 Tea++ 的新用户，有乳糖不耐受，记得自己上次点的饮料不错。她本想复购，看到 Faves 菜单，但自己从没往里加过东西。她看到了 *+* 按钮，但想不起饮料名和定制项，于是点进 Recent Orders，发现那杯叫 Tiger Chai Latte，且自己改成了豆奶。她上次还点了点心，但这次不想要。恼人的是，Reorder 想把点心也一并塞给她，而她找不到只选拿铁的方法。她退出后进入常规点单流程。完成定制并下单后，她想在末尾找 Favorites 按钮，但没找到。好吧，至少拿铁已经在路上了，也许下次再说。
Bob 再次皱起眉头：“这就是我当时想做心形按钮的原因。”
Alice 笑了笑：“我坦白一件事。我最初其实是想让 Carlos 让*你*来做这个按钮。我把这个故事发给了他。三周后，他让我来调研，但先让我找别的低垂果实。于是我才发现了收藏门店和替换广告位这两个机会。”
我会在[第 5 章](/ch5/#ch05_user_feedback)讨论如何收集用户反馈，并把它转化成此类故事或用户原话。
### 验证拟建功能的场景 {#id12}
我最常见到的场景用途之一，是模拟用户将如何与你正在设计的产品交互。
例如，下面是 Alice 的*改后*故事，不仅包含心形按钮，还把“收藏门店”“收藏页入口”和“首页入口位调整”三项一起串联：
> Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。她想复购，于是点进 Recent Orders，看到那杯叫 Tiger Chai Latte。她点了旁边的心形图标。系统将她重定向到 Favorites 菜单，这杯饮料在列表顶部，她点击其旁边的“Order now”按钮。接着出现门店选择器，默认是她上次去的 Main St. 门店。她点击该门店并用 Apple Pay 完成支付。由于她已经去过同一家门店两次，系统弹窗询问是否将 Main St. 设为收藏门店。她点击 Yes。
>
> 下次她想喝的时候，打开应用，顶部就出现了“Tiger Chai Latte from Main St.”，位于季节限定推荐上方。她一点就直接进入支付页。
“这个故事是我的北极星之一，”她解释道，“它让我确信自己在构建并推动正确的事情，也帮助 Carlos 形成认同。”
像这样引导产品设计的场景，被称为“北极星场景（north star scenarios）”，将在[第 7 章](/ch7/#ch07_product_discovery_sim)讨论。
### 作为测试的场景 {#id279}
Alice 和 Bob 没聊到这一点，但她在编写自动化测试时也写了“场景测试”：它不只覆盖单个页面，还确保页面之间衔接正确，验证用户确实能走完整个常见流程。
场景测试会在[第 4 章](/ch4/#ch04_dogfooding)重点介绍。
### 寻找关键答案 {#id280}
看 Bob 的初版设计和那些原型时，你可能会觉得自己难以下判断，或者信息不足。也许你会基于过往经验提出一些改进建议；也许你会把注意力放在数据库模式上，质疑一些技术细节。
但 Alice 的故事把我们的注意力引向了更重要的问题：
- 他们能不能做语音助手？
- 通勤前或通勤中下单到底多常见？
- 收藏功能对用户是否真的好用？
- 点单流程里还有哪些摩擦点？
这些才是高产出的问题。它们能帮助团队缩小范围并给不同功能排优先级。她既让我们对当前应用感到不满足，也设定了一个“易用性高标”，而团队可以用“离这个标杆有多近”来衡量最终方案。
在这个过程中，她成功凸显了三个最关键的改进点。
### 所以，到底什么是场景？ {#id13}
现在 Alice 已经充分说明了场景的重要性，我们来拆解场景，并帮助你自己写出来。
一个场景是为激发产品批判性思考而设计的用户故事。它由两部分构成：一个角色，以及该角色在发现并穿行产品或功能以解决问题时的行为模拟。
先看角色。角色由以下要素组成：
- **Persona（人物画像）**：背景信息，包括其具备的技能与能力
- **Motivation（动机）**：他们在当前使用产品时想获得或需要获得的东西
下面是 Alice北极星场景的一段：
> Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。她想复购，于是点进 Recent Orders，注意到 Tiger Chai Latte 旁边有个心形图标并点了它。系统随即把她带到 Favorites 菜单，这杯饮料在顶部，她点击条目旁边的“Order now”按钮。
你可以试着找找这里的“动机”和“人物画像”。下面我分别展开。
#### 一个动机 {#id281}
思考用户的第一条规则，是先理解他们想要什么。
在小说中，角色欲望推动故事前进。我们会为主角实现目标而欢呼，也会在其受阻时共情。众所周知，音乐剧常在开场用一首“我想要（I Want）”之歌来建立角色动机。《绿野仙踪》里是 Dorothy 的 *Somewhere over the Rainbow*，《Hamilton》里是 Alexander Hamilton 的 *My Shot*。
当动机写得很差时，我们会抱怨角色行为“不像他会做的事”。
场景里的用户也需要动机。这能帮助我们在产品按预期帮助用户达成目标时感到张力释放，也帮助我们判断他们的行为是否合理。如果涉及付费，我们也会据此判断他们是否有足够动机购买我们的产品。
我们把动机从场景里拿掉看看会怎样。
> Eliana 是 Tea++ 的一位较新用户 。她点进 Recent Orders，注意到 Tiger Chai Latte 旁边有个心形图标并点了它。系统把她带到 Favorites 菜单，列表顶部显示了该饮料，她点击了条目旁边的“Order now”按钮。
Eliana 真的会这样做吗？我们不知道。她为什么点 Recent Orders 而不是 Favorites？她一开始就想去收藏某个条目，并且神奇地知道“收藏入口藏在 Recent Orders”吗？我们会怀疑故事作者 Alice 像提线木偶一样操纵 Eliana 的行为来证明自己的观点，也会质疑这个功能到底是否容易被发现。
一旦我们看到她的心理状态：她记不清饮料名字，但记得那杯很好喝，我们就能理解她为什么先去 Recent Orders。
##### 写出动机 {#id14}
确保你的动机足够强，足以驱动角色去使用你的功能。
如果你的产品很粗糙，用户通常需要较强动机才会去用。下面是 Alice 可用于批评旧设计的一个*改前*故事：
> Eliana 是一位乳糖不耐受的 Tea++ 新近用户，记得自己之前点过的饮料很好喝。她想复购，于是点进 Recent Orders，发现那杯叫 Tiger Chai Latte。她当时有一点空闲时间，也很了解自己“喜欢上某样东西就会反复点”的习惯，所以她进入 Favorites 菜单，点击 *+* 按钮，搜索 “tiger”，点击结果，重新配置定制项（豆奶、中等（medium）），然后点击 OK。接着她再点击 “Order now”。
这个版本强调：要使用当前收藏系统，用户必须足够勤勉、足够投入；而 Tea++ 的目标恰恰是*降低*下单所需的动机强度。
强迫自己以这种方式写出能贯穿动作链条的清晰用户动机，能够暴露糟糕的产品设计。
要小心：写动机时，很容易给用户强加“稻草人式”动机，例如“<某人>想用<我的酷功能>”，却没有解释其底层需求。比如“Eliana 想查看近期订单”。这不是她的目标，而只是达成目标的手段。那她真正的目标是什么？
如果你不熟悉这个概念，*稻草人论证*是指把对方并不持有的立场强加给对方，以服务论证者自身利益。政治讨论中常见：我们会很快替不喜欢的政策或政客脑补糟糕动机和糟糕论点。类似地，*稻草人用户*也是一种虚构角色，其行为不合理，往往只是因为我们需要他们这么做，才能让产品看起来成功。
> [!WARNING]
> 避免把场景角色写成稻草人。
如果你发现动机很弱，就深入挖掘角色。你可以把这称为*根因分析*（RCA）。根因就是用户采取某一动作背后的 *why* 或 *so that*：Eliana 记得自己喜欢之前点过的一款饮料。她之所以能这样做，是因为她是回头客。
> [!TIP]
> 对用户动机做根因分析。
如果你仍不确定，就去和一些用户聊聊，或与本地产品经理、技术负责人讨论，厘清真实动机。
在我的根因分析中，当我说 Eliana 是回头客时，已经从“即时动机”延伸到了人物画像。既然触到了角色背景，我们现在就来谈人物画像。
#### 人物画像 {#id182}
如果理解用户的第一条规则是“知道他们想要什么”，第二条就是“用户并非铁板一块”。他们有不同背景与经历，而这会影响他们希望从产品中得到什么。
这种角色背景叫做 *persona*（人物画像）。人物画像是快速建立对目标用户同理心的关键工具。它可用于与团队沟通并达成对齐，也能有效凸显不同用户群的差异。
人物画像通常以某个群体特征为锚点。
在 Alice 的“车载语音下单”场景中，我们看到 Tea++ 的核心受众是通勤职场人。（顺着这个认知，门店多分布在道路沿线和火车站附近，且 Tea++ 主打高价位精品饮品。）
这样的画像意味着一组“能力条件”：这类人使用产品时会带来哪些技能、知识和行为倾向。它还可以被场景进一步收窄，比如强调“新用户”状态。
例如，在 Alice 的北极星场景中，Eliana 的画像是“刚开始形成复购、但尚未形成习惯的回头客”，据此我们推断她并不熟悉菜单和下单流程。
如果去掉人物画像：
> Eliana 记得自己喜欢之前点过的饮料。她想复购，于是点进 Recent Orders，看到 Tiger Chai Latte 旁边有心形图标并点了它……
这个故事缺少“能力线索”，会让我们难以判断它是否与业务策略相关。Eliana 是 Tea++ 应该重点关注的人吗？只有当我们把她框定为“可能成为、也可能不会成为习惯用户的人”，这个场景的价值才清晰起来。
人物画像也有助于理解这个功能*不*为谁而做。对首次下单用户来说，“收藏”几乎没有价值，所以不应把它作为新用户增长策略的关键环节。若 Tea++ 门店主要服务一次性到访游客，它也不应被优先投入。
##### 写人物画像 {#id183}
首先，团队最好先就一个或多个*目标受众*达成一致，即你的应用会服务哪些人物画像，也可能面向哪些人物画像进行营销。我会在[第 6 章](/ch6/#ch06_target_aud)带你定义目标受众。
如果你还不清楚目标受众，就去和团队对齐。你的场景人物画像应当落在目标受众范围内。
你还常常需要让画像具备多个侧面，才能更完整呈现用户拥有的技能、知识和动机。
这里有一些常见维度：
- 用户处在“产品漏斗”的哪个阶段？是否已注册？你是否注意到，很多网站把注册入口做得很显眼，却把“已有账号登录”埋得很深？这反映了一个判断：老用户不需要像新用户那样被“手把手照顾”。
- 轻度用户 vs 重度用户。假设重度用户只占 10%，你上线了一个能解决普遍痛点但使用门槛较高的功能。如果其余 90% 的用户难以发现或懒得使用，那么你实际上只为 10% 的用户解决了问题。
- 市场两侧用户，例如司机与乘客，或免费用户与广告购买者。两侧诉求常常截然不同，不应把他们当作一个没有差异的用户团。
- 不同编程语言的开发者。如果你的 SDK 同时服务 Python 开发者（写机器学习数据管道）和 Go 开发者（写控制平面），你可能需要为 Python 与 Go 分别刻画不同侧面。
所以，Eliana 属于“通勤职场人 / 新用户”。
人物画像能凸显为多群体构建产品时的差异与复杂性，是更精确思考用户的优秀工具。我会在[第 6 章](/ch6/#ch06_target_aud)更深入讨论人物画像，讲清如何在团队沟通、优先级制定与设计思考中使用它。接下来我也会频繁引用这一概念。
##### 确定人物画像的“能力条件” {#id15}
了解用户具备哪些条件，会帮助你帮助他们达成目标。
你的画像会有一些特定优势。比如忙碌职场人通常有一些可支配收入、数字素养较高，但时间匮乏；而固定收入的退休人群往往相反。
除了这类画像特有条件外，你还可以利用一些几乎普适的人类共性。事实上，我可以直接“指控”你也有这些特征：
首先，你会希望在使用产品时尽可能少耗费脑力：
- 你不懂实现细节，也无法读懂作者的心思。
- 能不看文档你就不看。你更愿意从产品本身直觉出“该怎么做”。
- 除了极少数你特别在意的产品外，你通常不会系统遍历一个应用或框架的全部功能。你更倾向快速定位并找到当前任务所需工具。
其次，你还有其他局限：
- 你会多任务并经常分心。你希望能在一个或几个小“工作步”里推进，并在中断后得到提醒再回来完成未尽事项。
- 你会走最短路径。你希望尽快完成任务，除非收益明显，否则不愿额外投入。
- 你倾向规避风险。你不想到了店里才发现茶没下成功，也不想因此误了火车。
- 你会遗忘。几个月后再回来时，你可能需要冗余线索或提醒。
下面是 Alice 的一个*改前*故事版本，它忽略了“人会忘”和“人很忙”这两点：
> Eliana 是一位乳糖不耐受的 Tea++ 新近用户，记得自己喜欢 Tiger Chai Latte，并且知道自己还会再点几次。她点进 Favorites 菜单，点击 *+* 按钮，搜索 “tiger” 并选择这款饮料。然后她重放定制项（豆奶、中等（medium）），再点 OK。当它出现在列表里后，她点击“Order now”。
这种故事往往会导向一种产品：上线后采用率不及预期，而用户为何不买账看起来又“莫名其妙”。
记住这些共性的一个方法是*换鞋思考（shoe-shifting）*：把自己放到用户的位置，思考你在那个位置会知道什么、会怎么做。
关键之一是培养*选择性失忆*，主动忘掉你在开发过程中获得的内部知识。
可怎么做到呢？我们是否永远被“看过就回不去”的禁忌知识污染？是否只能依赖新用户反馈才可能共情他们？
好消息是，不必如此。虽然与新手用户做研究和测试不可忽视（我们也会做），但现实里并非每个决策都能等到完整数据。因此你必须在自己工位上、仅凭自己的思考完成“换鞋思考”。
做法是：每当我发现自己调用了开发过程中才知道的知识或记忆，就把它识别为“禁忌知识”，然后假设自己并不知道它，再继续推演。
就 Alice 而言，她在写用户故事时会“忘掉”系统里已有“收藏门店”这一概念。所以当系统检测到用户在同一门店复购时，她才通过弹窗引导设置收藏门店。
我在日常中一直用“换鞋思考”和“选择性失忆”来共情用户。本书后面会频繁回到这个方法，例如在[第 4 章](/ch4/#ch04_dogfooding)写“摩擦日志”时。
##### 角色小结 {#id16}
一个场景中的角色，是“人物画像 + 动机”的组合：人物画像提供较宽泛的目标与能力条件，动机解释其当下为何使用你的产品。接下来我们把注意力转向情节。
#### 模拟 {#id184}
*模拟*（simulation）是场景的情节，它会把角色在完成任务过程中所需的每一步动作细致走一遍。模拟的目的，是把设计者的注意力拉到会真正影响用户体验的关键细节上。
一个好模拟像一份优雅的数学证明：每一步都有依据，且与前一步逻辑连贯。它会挑战设计，而不是迎合设计。糟糕的模拟会含糊跳步，或只突出有利部分、自我服务。
如果这种思路让你陌生，你并不孤单。大多数学校和编程训练营并不教用户模拟。敏捷方法强调场景（称为用户故事），但对“模拟”这个层面的关注很少。不过，下次当你尊敬的资深工程师与你讨论棘手设计时，留意他们的话。你可能会听到“如果 X 发生会怎样？”“如果用户是 Y 呢？”这类句子。即使他们没有把内容正式写成场景，他们很可能也在做心理模拟。
我遇到更多的是受过良好训练的“模式匹配型”工程师。他们看到一个问题与过往问题相似，就会调用已有解法，就像 Bob 的同事记起星巴克在近期订单里用过心形按钮，来类比他们拟做的收藏功能。这些解法会形成不断增长的经验库，可迁移到新公司继续发挥作用。
用场景模拟强化你的内在模式匹配器。它会把你的注意力聚焦到最需要的位置，然后让你的模式识别能力尽情发挥。
例如，下面是 Alice 最完整的北极星场景，覆盖了她新增的三项功能：
> Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。她想复购，于是点进 Recent Orders，看到那杯叫 Tiger Chai Latte。她点了旁边的心形图标。系统把她重定向到 Favorites 菜单，该饮料位于顶部，她点击旁边的“Order now”按钮。接着出现门店选择器，默认是她上次去的 Main St. 门店。她点击并使用 Apple Pay 完成支付。由于她已经去过同一家门店两次，系统弹窗询问是否将 Main St. 设为收藏门店。她点击 Yes。
>
> 下次她想喝的时候，打开应用，顶部（在季节限定推荐之上）出现“Tiger Chai Latte from Main St.”。她点击后直接进入支付页面。
这个场景同时高亮了许多功能及其交互：近期订单、收藏、下单、门店选择、收藏门店、支付流程和首页展示。
我个人读到这里时会想：点单流程的其他环节呢？小费呢？系统是否应记住用户的小费偏好，从而减少点击并为未来语音点单铺路？Alice 没触及这一点，但也许她应该考虑。就我自己而言，是在我编辑时补进 Apple Pay 这一情节点后，才注意到这个问题。
当她后续进入更细设计时，会把这些高层步骤继续细化，并可能配上原型页面示意，形成故事板。我会在[第 7 章](/ch7/#ch07_product_discovery_sim)讨论这种“用户流程（user flows）”。
##### 写出模拟 {#id17}
当我写模拟时，我希望它足够完整，以确保能想到潜在坑点。我通常会从正在构建的功能起笔，比如心形按钮：
> Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。在 Recent Orders 标签页里，她发现那杯叫 Tiger Chai Latte。她点击旁边的心形图标。系统把她带到 Favorites 菜单，并把这款饮料列在列表里。
然后，我会强迫自己沿三个方向推进：
- 在这一刻之前发生了什么？是什么把用户带到这里？她是如何知道该这么做的？
- 接下来会发生什么？
- 这个步骤是否需要补足更细节？
> [!TIP]
> 讲完整个故事，不要只盯着你新增的那个功能。
如果我卡住了，或者发现自己完全在瞎编，就说明我可能需要去访谈用户、看指标、找 PM 聊，或请教其他团队，才能建立更稳固的判断基础。
有时我会得出结论：这功能不该做，达不到我希望的影响力。也有时我会意识到：不能只做这一项，还得多做一些，或者需要找另一个团队一起改进他们的那一段。无论哪种，我都学到了有价值的信息。
不关注完整流程的团队，最终做出的产品往往粗糙、割裂。你很可能遇到过这样的登录流程：你通过深链进入某网站，登录后却发现系统已经忘了原始深链目标。这类团队多半没有用场景来设计软件。
写场景时还有一个技巧：寻找“情节漏洞（plot holes）”。
一种情节漏洞是“跳步”。归根结底，你的产品就是用户旅程。用户不是静态地“使用”产品，而是在其中移动：发现它、想到它、学会它、使用它，并承受其后果。如果只盯界面本身（我们看得见的那部分），就会产生隧道视野。
经典失误之一是漏掉“发现机制”。比如 Tea++ 的门店从未提过有点单应用，导致本可发现该应用的用户里只有 10% 真正发现了它，只有那些愿意去应用商店主动搜索的人才会找到。
另一类情节漏洞是边界情况。你需要为不同情况写不同故事。比如用户在早晚会去两家不同门店怎么办？Alice 大概应该处理并排优先级，但要在另一个故事里完成。
> [!NOTE]
> 在撰写或评审场景时，主动寻找“跳步”和“边界情况”。
#### 如何使用场景？ {#id185}
场景应贯穿软件开发的每个方面：从最初发现（正如 Alice 在本章所做）直到实现规格文档。因此，本书很大部分内容都会依赖“故事”的力量。
- 在开发阶段，你会用场景来选择好名字（[第 2 章](/ch2/#ch02_naming)），并设计错误层级和可执行的优质错误消息（[第 3 章](/ch3/#ch03_errors)）；你还会把它们转化为场景测试（[第 4 章](/ch4/#ch04_dogfooding)）。
- 在发布后，你会从用户反馈中收集这些场景（[第 5 章](/ch5/#ch05_user_feedback)）；在起步阶段，你会通过“客户发现访谈”获取它们（[第 6 章](/ch6/#ch06_target_aud)）。
- 在设计阶段，你会基于“按优先级整理的场景全集”制定产品路线图，并形成更细的用户流程（[第 7 章](/ch7/#ch07_product_discovery_sim)）。
- 场景还会指导细粒度交互设计（[第 8 章](/ch8/#ch08_interaction_design)）和架构决策，例如用于生成负载模拟（[第 9 章](/ch9/#ch09_product_architecture)）。
使用场景需要练习，但我们并非从零开始。毕竟我们从很小就学习故事。我们天生能够阅读并理解故事。作为产品思维工程师，我们还必须学会生成故事并批判故事。
Alice 在解释她如何使用故事时，用了一个词：*conviction*（确信）。当她构建出正确场景时，她能感受到这种力量，并由此相信自己的产品会奏效。在需要取舍的讨论中，她可以通过推演不同故事出现的相对概率来决策。她能带着确信发布，因为她的测试覆盖了最关键的场景。她也能把这些场景一路串到所有需要实现的组件上，确保它们共同让故事成立。
### 章节小结 {#id18}
我梳理了工程师进行产品思维的基础，并给出以下建议。
- 场景是“行为模拟 + 人物画像”的组合。用完整场景理解用户及其处境，并指导产品决策。
- 模拟是把注意力聚焦到关键处的强大工具。不要只看界面，要看到用户旅程。
- 人物画像确保你与产品目标受众真正连接。
- 通过“换鞋思考”与“选择性失忆”在日常中持续共情用户。
- 在整个产品生命周期使用场景。随着设计走向实现，让故事逐步细化。
这些基础会贯穿全书。你当然可以从这里开始跳读，但我接下来会先讲产品如何与用户沟通，深入命名和信息架构等主题，因为它们是最常见的产品决策。练好这些，是让产品思维变成本能的好路径。
### 练习 {#id186}
在这些练习中，我们假设自己在 Wikipedia.org 工作。
1. 列出至少两类使用 Wikipedia 的人物画像，并分别描述。请确保你考虑到这些用户重视什么。（我的答案会覆盖两类宽泛画像。）
2. Wikipedia 想提升文章质量，尤其是低热度语言条目。当前用户必须点击“Edit”链接才能编辑内容。Wikipedia 是否应该提供顺滑的行内编辑体验来消除这层摩擦？
3. 假设你在设计 Wikipedia 页面顶部搜索框里的搜索功能。选用问题 1 中的一个画像，写一段场景，展示读者如何使用“typeahead”功能（即在输入时内联展示可能结果），从而不必加载单独搜索页。请用该场景凸显实现需要解决的问题。
4. 假设你在设计 Wikipedia 的“Watch this page”功能，让编辑者订阅页面变更。选用问题 1 中的一个画像，至少写两段场景，帮助团队思考人们会如何使用它。（即便你从未使用过该功能也没关系，请按你认为合理的方式设想。）
### 参考答案 {#id19}
1. Reid（读者）是一个以任务为导向的 Wikipedia 文章读者。Reid 看重 Wikipedia 提供的事实性与中立性信息，也重视其透明度，特别是在政治内容上。他希望快速找到并读完所需信息，然后继续一天的其他安排。
Eddie（编辑者）是一位历史学者，会创建自己专业领域内的 Wikipedia 条目，也会审阅他人的内容。他把自己视为内容守护者，因此会持续关注他人对其页面的修改，以确保内容和引用准确。他也希望成为社区的一部分，因此协作者群体的健康度、包容性和可信度对 Eddie 至关重要。
2. 不应该。Wikipedia 主文章页的首要目标应服务 Reid 画像，因为 Reid 的数量比 Eddie 高三个数量级。Reid 需要快速页面加载，而行内编辑可能会拖慢这一点；他也不希望自己随手敲的按键就触发编辑。至于 Eddie，他是投入度更高的用户，不会被少量额外摩擦劝退。
3. 在这个场景里，我重点强调了搜索排序、拼写纠正，以及 typeahead 候选都不命中时的处理。
Reid 想知道 *Paradise Lost* 的作者是谁。他点进搜索框输入 “Paradice Lost”（他不会拼），注意到顶部结果是 “Paradise Lost. Epic Poem by John Milton”，并带有封面缩略图。他还看到几个歧义项（比如一个英国哥特金属乐队），但顶部结果是正确的，因为链接按热度排序。若他真正想查的是该金属乐队的第七张专辑，他可以点击列表底部的放大镜条目，其文案是“search for pages containing *paradice lost*”。
4. 我写了几个场景，覆盖了查看编辑便利性、取消订阅和通知渠道。你也可能会关注我没想到的点，比如用户如何联系与自己意见相左的编辑者。
Eddie 曾大量编辑一篇关于古代美索不达米亚建筑的页面，对其后续反馈有些紧张。他希望知道是否有人改动自己新增的段落。他在编辑表单里点击 “Submit” 按钮旁的 “Watch this page” 复选框，然后提交。之后他又做了几次编辑。现在该复选框默认已勾选，他保持不变。
之后 Eddie 在邮箱里收到一封变更通知邮件。邮件说明这些变更不涉及他编辑的部分，于是他忽略了。几天后，确实有人修改了他的段落，他又收到一封邮件。他点击邮件里的链接，进入“修改前/修改后”并排对比页，页面自动跳到并高亮改动处。他发现只是措辞更清晰，于是很满意。
几个月后，Eddie 觉得很多邮件都在提示他不关心的改动（页面太长了）。于是他点击邮件底部的 “Change or unsubscribe to notifications for this page”。在设置页上，他看到几个以前没注意到的复选框：可以取消“接收未编辑区段的通知”和“接收小改动通知”。他意识到自己只愿意订阅与本人编辑区段相关的变更，于是取消勾选了前一个选项。