1. 产品思维的基础

来吧，开始吧，开始吧

那么，说吧，说吧，这到底是什么场景？

— A Tribe Called Quest

如果产品思维有一个核心原语，那就是场景。它本质上是一个为了产品设计而组织的用户故事。

来看一个关于密码的场景：

Darla 是一位退休的婴儿潮一代用户，45 岁才开始使用电脑。她正在本地茶饮店注册账号，以便在线下单。当系统要求输入邮箱和密码时，她选择了“女儿生日 + 儿子名字”，这样容易记住。她大约有 30 个线上账号，因此多数账号都用同一个密码，否则根本记不住；而且她又被建议不要把密码写下来。

你可以猜到后面会发生什么：这家茶饮店发生数据泄露，她的密码（也正是她在银行使用的那个）被泄露。也许暗网上有人买下了她的登录信息，并转走了她的钱。

这个噩梦般的场景揭示了密码体系的问题，但并不完全是产品内部某个组件本身的问题。只盯着注册界面、加密协议、安全存储等细节，你很难看到它。但当你写出包含可预见人性弱点的完整故事时，安全问题就会立刻显现。

在本节中，我们将拆解并分析有效场景的组成，并教你如何构建一个好场景。粗略地说，一个场景由“情节”和“角色”组成。我会先展开这两个概念，再给出实操建议。

不过照例，先用一个案例研究来引导讨论。

案例研究

Tea++ 是一家拥有 300 家门店的连锁茶饮店。它扩张过快，经营勉强维持，因此公司的目标是在极低预算下尽快提升订单量，避免关店。

Tea++ 有一款流行的移动应用，支持点单体验；通过反馈组件，用户一直在请求“收藏”功能，希望系统能记住偏好、加快下单。软件团队认为这可能是提升订单的低成本办法。

第一次尝试：没有场景

我们来看 Bob，一位移动端工程师。他在工作中并不使用用户场景。

Bob 查看了应用反馈组件里收到的用户意见。喝咖啡的用户厌倦了每次下单都要重新设置定制项，也不喜欢在近期订单里翻找。有时想要的商品埋在包含多个商品的订单中，拆分起来很麻烦。

Bob 做了一个与现有应用结构契合度很高的原型（见图 1-1）。他准备在应用底部新增一个 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 反对，称这会让开发周期翻倍，因为改动更具侵入性，比如需要在多个页面新增数据库查询。团队接受了这个判断，项目按原方案构建并上线。

效果平平

几周后复盘数据，有好消息也有坏消息。好消息是收藏功能上线稳定、没有重大缺陷。不幸的是，只有 6% 的活跃用户使用收藏，订单量仅增长 0.3%。

Tea++ 的应用埋点完善，Bob 深挖数据后发现：点击 Favorites 菜单的人很少，而点击进去的人多数会立刻离开。尤其是收藏列表为空的用户，极大概率会直接退出，而不是点 + 按钮。

Bob 想起“心形按钮”的建议，与 Carlos 讨论，提议补上它以提升转化率。但遗憾的是团队优先级已转向月度订阅，短期内无暇开发。大家都在为可能关店而焦虑，Carlos 对他的提案似乎也有些不耐烦。Bob 带着愤怒离开，觉得自己不被允许把产品真正做完。

问题出在哪？

Bob 做对了很多事：倾听用户反馈、追踪指标、收集并分析用户交互；他还控制范围，做出了高效、可达成、稳定的设计。

但他的提案仍然薄弱。评审会上团队提出的问题虽有价值，却不是最根本的。

第一，他跳过了发现（Discover）阶段（我在序言提过的四个阶段中的第一步），直接进入数据库设计。

换句话说，他把一个核心难点在于“产品决策及其与实现约束如何相互作用”的项目，包装成了“实现细节才是最关键”。只是他没有幸运地遇到能看出这个问题的队友。

下面我们看看一个会用场景来思考用户需求的开发者。

第二次尝试：引入场景

六个月后，Bob 仍在做订阅功能。此时 Alice（一位资深工程师）被引入来实现 Bob 一直后悔没做的“星巴克式心形按钮”。

她不止于此，她还做了“收藏门店”概念。这样一来，常去某家门店的用户可以在结账流程里少点几步，而这一点 Bob 当时完全没考虑，因为他接到的任务只聚焦“收藏饮品”。

第三，她做了 A/B 测试：将首页新品推广替换为一对巨大的“立即下单”按钮，并露出第三个按钮顶部，提示页面可滚动（见图 1-2）。这个思路和 Bob 曾设想的类似，但他当时没能说服产品营销团队让出首页空间。

随着时间推移，Alice 的实验表明，这些改动合在一起使转化率提升了 3.8%。由于移动端订单贡献了 Tea++ 一半营收，这足以显著改善利润。拿到数据后，Alice 得以说服市场部门把新品广告下移到前两个收藏项之下，并将实验全量发布。

Bob 几乎没参与她的方案制定，不禁疑惑 Alice 为什么对该做什么有这么准的直觉。她又是如何说服其他人放手去做的？

图 1-2. Alice 做了一个可滚动的快速下单页面原型，包含“立即下单”按钮

作为启发故事的场景

场景的一个用途，是用来沟通并激发团队。

Bob 发私信问 Alice 她是怎么做到的，Alice 回了一个很有感染力的故事：

Eliana 是一位忙碌的职场人，每天通勤都会买一杯加豆奶的印度香料奶茶拿铁。某天早晨，她忘了提前下单。开车途中，她按下方向盘上的语音助手键，说：“给我点 Tea++ 的老样子。”她的语音助手 Siri 回复并让她确认金额和门店，她确认了。

Bob 有些困惑：“好吧……但这也不是你最终做的东西啊？”

“我知道。Carlos 觉得做这个太贵了，”她遗憾地说，“他可能是对的。但我想先把标杆设高，展示潜力。我也想讲一个高频场景：在这个场景里，收藏流程不只是方便，而是直接决定用户能不能喝到那杯茶。”

“听起来很酷，不过我当时也觉得我们没有这种时间。”

“梦想本身有价值。”Alice 说，“收藏饮品和收藏门店会让用户以后更容易使用语音指令，前提是我们将来真去做。”

在发现（Discover）阶段，探索多种可能的故事线非常关键。

捕捉用户访谈的场景

如果你做过一些用户研究，场景可以是对访谈素材的虚构合成，能够简洁传达常见情境。

Bob 反驳道：“我的意思是，我也可以随便编个故事，让我的方案显得更好。开车时点单真的那么重要吗？”

Alice 回答：“我也挺希望有定位数据来验证这一点。但主要是我访谈了十来位朋友和熟人，甚至问了很多看似琐碎的点单细节。是的，通勤场景反复出现。Eliana 代表的是在疯狂早晨里忙乱、健忘的人。”

我们会在第 6 章讨论用户访谈。

揭示产品缺口的场景

场景也可以用来展示“缺了什么功能”。

“刚才那是我的改后故事，”Alice 说，“你要不要看改前版本？”

“呃，好。”

她把内容私信发了过来：

Eliana 是一位忙碌的职场人，每天通勤都会买一杯加豆奶的印度香料奶茶拿铁。某天早晨，她忘了提前下单。开车时，她在停车标志前停下，打开 Tea++ 应用并点进 Favorites。她在列表顶部找到自己的拿铁，点击“Order now”。后车按喇叭，她只好继续前进并专心驾驶。但她确实需要咖啡因，于是到高速匝道口时把车停到路肩。在购物车页，她选择“Order and Pay”。这个页面要求选择门店。地图加载后，她用手指猛戳 Main St. 的图钉并点 OK，然后进入支付页，使用 Apple Pay 完成交易。她放下手机，确认来车后重新并入匝道。

“我明白你为什么做收藏门店了，”Bob 说，“有人提过这个需求吗？”

“有个用户问过，为什么每次都得重选门店。而且当我自己代入、想象自己在车里时，我意识到心形按钮未必是最重要的。”

Bob 深吸一口气：“懂了。无论如何，心形按钮做成了，还是恭喜你。我当时也试着说服 Carlos 投入这块，但他要我做订阅。”

揭示摩擦体验的场景

你可以构造故事，来展示使用现有产品的痛点。这个例子里，Alice 设计了一个带一点反讽意味的小故事。

“这个我也有场景，”Alice 说，“它是从用户反馈间接提炼出来的。下面是改前故事。”

Eliana 是 Tea++ 的新用户，有乳糖不耐受，记得自己上次点的饮料不错。她本想复购，看到 Faves 菜单，但自己从没往里加过东西。她看到了 + 按钮，但想不起饮料名和定制项，于是点进 Recent Orders，发现那杯叫 Tiger Chai Latte，且自己改成了豆奶。她上次还点了点心，但这次不想要。恼人的是，Reorder 想把点心也一并塞给她，而她找不到只选拿铁的方法。她退出后进入常规点单流程。完成定制并下单后，她想在末尾找 Favorites 按钮，但没找到。好吧，至少拿铁已经在路上了，也许下次再说。

Bob 再次皱起眉头：“这就是我当时想做心形按钮的原因。”

Alice 笑了笑：“我坦白一件事。我最初其实是想让 Carlos 让你来做这个按钮。我把这个故事发给了他。三周后，他让我来调研，但先让我找别的低垂果实。于是我才发现了收藏门店和替换广告位这两个机会。”

我会在第 5 章讨论如何收集用户反馈，并把它转化成此类故事或用户原话。

验证拟建功能的场景

我最常见到的场景用途之一，是模拟用户将如何与你正在设计的产品交互。

例如，下面是 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 章讨论。

作为测试的场景

Alice 和 Bob 没聊到这一点，但她在编写自动化测试时也写了“场景测试”：它不只覆盖单个页面，还确保页面之间衔接正确，验证用户确实能走完整个常见流程。

场景测试会在第 4 章重点介绍。

寻找关键答案

看 Bob 的初版设计和那些原型时，你可能会觉得自己难以下判断，或者信息不足。也许你会基于过往经验提出一些改进建议；也许你会把注意力放在数据库模式上，质疑一些技术细节。

但 Alice 的故事把我们的注意力引向了更重要的问题：

• 他们能不能做语音助手？
• 通勤前或通勤中下单到底多常见？
• 收藏功能对用户是否真的好用？
• 点单流程里还有哪些摩擦点？

这些才是高产出的问题。它们能帮助团队缩小范围并给不同功能排优先级。她既让我们对当前应用感到不满足，也设定了一个“易用性高标”，而团队可以用“离这个标杆有多近”来衡量最终方案。

在这个过程中，她成功凸显了三个最关键的改进点。

所以，到底什么是场景？

现在 Alice 已经充分说明了场景的重要性，我们来拆解场景，并帮助你自己写出来。

一个场景是为激发产品批判性思考而设计的用户故事。它由两部分构成：一个角色，以及该角色在发现并穿行产品或功能以解决问题时的行为模拟。

先看角色。角色由以下要素组成：

• Persona（人物画像）：背景信息，包括其具备的技能与能力
• Motivation（动机）：他们在当前使用产品时想获得或需要获得的东西

下面是 Alice北极星场景的一段：

Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。她想复购，于是点进 Recent Orders，注意到 Tiger Chai Latte 旁边有个心形图标并点了它。系统随即把她带到 Favorites 菜单，这杯饮料在顶部，她点击条目旁边的“Order now”按钮。

你可以试着找找这里的“动机”和“人物画像”。下面我分别展开。

一个动机

思考用户的第一条规则，是先理解他们想要什么。

在小说中，角色欲望推动故事前进。我们会为主角实现目标而欢呼，也会在其受阻时共情。众所周知，音乐剧常在开场用一首“我想要（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。

写出动机

确保你的动机足够强，足以驱动角色去使用你的功能。

如果你的产品很粗糙，用户通常需要较强动机才会去用。下面是 Alice 可用于批评旧设计的一个改前故事：

Eliana 是一位乳糖不耐受的 Tea++ 新近用户，记得自己之前点过的饮料很好喝。她想复购，于是点进 Recent Orders，发现那杯叫 Tiger Chai Latte。她当时有一点空闲时间，也很了解自己“喜欢上某样东西就会反复点”的习惯，所以她进入 Favorites 菜单，点击 + 按钮，搜索 “tiger”，点击结果，重新配置定制项（豆奶、中等（medium）），然后点击 OK。接着她再点击 “Order now”。

这个版本强调：要使用当前收藏系统，用户必须足够勤勉、足够投入；而 Tea++ 的目标恰恰是降低下单所需的动机强度。

强迫自己以这种方式写出能贯穿动作链条的清晰用户动机，能够暴露糟糕的产品设计。

要小心：写动机时，很容易给用户强加“稻草人式”动机，例如“<某人>想用<我的酷功能>”，却没有解释其底层需求。比如“Eliana 想查看近期订单”。这不是她的目标，而只是达成目标的手段。那她真正的目标是什么？

如果你不熟悉这个概念，稻草人论证是指把对方并不持有的立场强加给对方，以服务论证者自身利益。政治讨论中常见：我们会很快替不喜欢的政策或政客脑补糟糕动机和糟糕论点。类似地，稻草人用户也是一种虚构角色，其行为不合理，往往只是因为我们需要他们这么做，才能让产品看起来成功。

如果你发现动机很弱，就深入挖掘角色。你可以把这称为根因分析（RCA）。根因就是用户采取某一动作背后的 why 或 so that：Eliana 记得自己喜欢之前点过的一款饮料。她之所以能这样做，是因为她是回头客。

如果你仍不确定，就去和一些用户聊聊，或与本地产品经理、技术负责人讨论，厘清真实动机。

在我的根因分析中，当我说 Eliana 是回头客时，已经从“即时动机”延伸到了人物画像。既然触到了角色背景，我们现在就来谈人物画像。

人物画像

如果理解用户的第一条规则是“知道他们想要什么”，第二条就是“用户并非铁板一块”。他们有不同背景与经历，而这会影响他们希望从产品中得到什么。

这种角色背景叫做 persona（人物画像）。人物画像是快速建立对目标用户同理心的关键工具。它可用于与团队沟通并达成对齐，也能有效凸显不同用户群的差异。

人物画像通常以某个群体特征为锚点。

在 Alice 的“车载语音下单”场景中，我们看到 Tea++ 的核心受众是通勤职场人。（顺着这个认知，门店多分布在道路沿线和火车站附近，且 Tea++ 主打高价位精品饮品。）

这样的画像意味着一组“能力条件”：这类人使用产品时会带来哪些技能、知识和行为倾向。它还可以被场景进一步收窄，比如强调“新用户”状态。

例如，在 Alice 的北极星场景中，Eliana 的画像是“刚开始形成复购、但尚未形成习惯的回头客”，据此我们推断她并不熟悉菜单和下单流程。

如果去掉人物画像：

Eliana 记得自己喜欢之前点过的饮料。她想复购，于是点进 Recent Orders，看到 Tiger Chai Latte 旁边有心形图标并点了它……

这个故事缺少“能力线索”，会让我们难以判断它是否与业务策略相关。Eliana 是 Tea++ 应该重点关注的人吗？只有当我们把她框定为“可能成为、也可能不会成为习惯用户的人”，这个场景的价值才清晰起来。

人物画像也有助于理解这个功能不为谁而做。对首次下单用户来说，“收藏”几乎没有价值，所以不应把它作为新用户增长策略的关键环节。若 Tea++ 门店主要服务一次性到访游客，它也不应被优先投入。

写人物画像

首先，团队最好先就一个或多个目标受众达成一致，即你的应用会服务哪些人物画像，也可能面向哪些人物画像进行营销。我会在第 6 章带你定义目标受众。

如果你还不清楚目标受众，就去和团队对齐。你的场景人物画像应当落在目标受众范围内。

你还常常需要让画像具备多个侧面，才能更完整呈现用户拥有的技能、知识和动机。

这里有一些常见维度：

• 用户处在“产品漏斗”的哪个阶段？是否已注册？你是否注意到，很多网站把注册入口做得很显眼，却把“已有账号登录”埋得很深？这反映了一个判断：老用户不需要像新用户那样被“手把手照顾”。
• 轻度用户 vs 重度用户。假设重度用户只占 10%，你上线了一个能解决普遍痛点但使用门槛较高的功能。如果其余 90% 的用户难以发现或懒得使用，那么你实际上只为 10% 的用户解决了问题。
• 市场两侧用户，例如司机与乘客，或免费用户与广告购买者。两侧诉求常常截然不同，不应把他们当作一个没有差异的用户团。
• 不同编程语言的开发者。如果你的 SDK 同时服务 Python 开发者（写机器学习数据管道）和 Go 开发者（写控制平面），你可能需要为 Python 与 Go 分别刻画不同侧面。

所以，Eliana 属于“通勤职场人 / 新用户”。

人物画像能凸显为多群体构建产品时的差异与复杂性，是更精确思考用户的优秀工具。我会在第 6 章更深入讨论人物画像，讲清如何在团队沟通、优先级制定与设计思考中使用它。接下来我也会频繁引用这一概念。

确定人物画像的“能力条件”

了解用户具备哪些条件，会帮助你帮助他们达成目标。

你的画像会有一些特定优势。比如忙碌职场人通常有一些可支配收入、数字素养较高，但时间匮乏；而固定收入的退休人群往往相反。

除了这类画像特有条件外，你还可以利用一些几乎普适的人类共性。事实上，我可以直接“指控”你也有这些特征：

首先，你会希望在使用产品时尽可能少耗费脑力：

• 你不懂实现细节，也无法读懂作者的心思。
• 能不看文档你就不看。你更愿意从产品本身直觉出“该怎么做”。
• 除了极少数你特别在意的产品外，你通常不会系统遍历一个应用或框架的全部功能。你更倾向快速定位并找到当前任务所需工具。

其次，你还有其他局限：

• 你会多任务并经常分心。你希望能在一个或几个小“工作步”里推进，并在中断后得到提醒再回来完成未尽事项。
• 你会走最短路径。你希望尽快完成任务，除非收益明显，否则不愿额外投入。
• 你倾向规避风险。你不想到了店里才发现茶没下成功，也不想因此误了火车。
• 你会遗忘。几个月后再回来时，你可能需要冗余线索或提醒。

下面是 Alice 的一个改前故事版本，它忽略了“人会忘”和“人很忙”这两点：

Eliana 是一位乳糖不耐受的 Tea++ 新近用户，记得自己喜欢 Tiger Chai Latte，并且知道自己还会再点几次。她点进 Favorites 菜单，点击 + 按钮，搜索 “tiger” 并选择这款饮料。然后她重放定制项（豆奶、中等（medium）），再点 OK。当它出现在列表里后，她点击“Order now”。

这种故事往往会导向一种产品：上线后采用率不及预期，而用户为何不买账看起来又“莫名其妙”。

记住这些共性的一个方法是换鞋思考（shoe-shifting）：把自己放到用户的位置，思考你在那个位置会知道什么、会怎么做。

关键之一是培养选择性失忆，主动忘掉你在开发过程中获得的内部知识。

可怎么做到呢？我们是否永远被“看过就回不去”的禁忌知识污染？是否只能依赖新用户反馈才可能共情他们？

好消息是，不必如此。虽然与新手用户做研究和测试不可忽视（我们也会做），但现实里并非每个决策都能等到完整数据。因此你必须在自己工位上、仅凭自己的思考完成“换鞋思考”。

做法是：每当我发现自己调用了开发过程中才知道的知识或记忆，就把它识别为“禁忌知识”，然后假设自己并不知道它，再继续推演。

就 Alice 而言，她在写用户故事时会“忘掉”系统里已有“收藏门店”这一概念。所以当系统检测到用户在同一门店复购时，她才通过弹窗引导设置收藏门店。

我在日常中一直用“换鞋思考”和“选择性失忆”来共情用户。本书后面会频繁回到这个方法，例如在第 4 章写“摩擦日志”时。

角色小结

一个场景中的角色，是“人物画像 + 动机”的组合：人物画像提供较宽泛的目标与能力条件，动机解释其当下为何使用你的产品。接下来我们把注意力转向情节。

模拟

模拟（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 章讨论这种“用户流程（user flows）”。

写出模拟

当我写模拟时，我希望它足够完整，以确保能想到潜在坑点。我通常会从正在构建的功能起笔，比如心形按钮：

Eliana 是 Tea++ 的一位较新用户，记得自己之前点过一杯很好喝的饮料。在 Recent Orders 标签页里，她发现那杯叫 Tiger Chai Latte。她点击旁边的心形图标。系统把她带到 Favorites 菜单，并把这款饮料列在列表里。

然后，我会强迫自己沿三个方向推进：

• 在这一刻之前发生了什么？是什么把用户带到这里？她是如何知道该这么做的？
• 接下来会发生什么？
• 这个步骤是否需要补足更细节？

如果我卡住了，或者发现自己完全在瞎编，就说明我可能需要去访谈用户、看指标、找 PM 聊，或请教其他团队，才能建立更稳固的判断基础。

有时我会得出结论：这功能不该做，达不到我希望的影响力。也有时我会意识到：不能只做这一项，还得多做一些，或者需要找另一个团队一起改进他们的那一段。无论哪种，我都学到了有价值的信息。

不关注完整流程的团队，最终做出的产品往往粗糙、割裂。你很可能遇到过这样的登录流程：你通过深链进入某网站，登录后却发现系统已经忘了原始深链目标。这类团队多半没有用场景来设计软件。

写场景时还有一个技巧：寻找“情节漏洞（plot holes）”。

一种情节漏洞是“跳步”。归根结底，你的产品就是用户旅程。用户不是静态地“使用”产品，而是在其中移动：发现它、想到它、学会它、使用它，并承受其后果。如果只盯界面本身（我们看得见的那部分），就会产生隧道视野。

经典失误之一是漏掉“发现机制”。比如 Tea++ 的门店从未提过有点单应用，导致本可发现该应用的用户里只有 10% 真正发现了它，只有那些愿意去应用商店主动搜索的人才会找到。

另一类情节漏洞是边界情况。你需要为不同情况写不同故事。比如用户在早晚会去两家不同门店怎么办？Alice 大概应该处理并排优先级，但要在另一个故事里完成。

如何使用场景？

场景应贯穿软件开发的每个方面：从最初发现（正如 Alice 在本章所做）直到实现规格文档。因此，本书很大部分内容都会依赖“故事”的力量。

• 在开发阶段，你会用场景来选择好名字（第 2 章），并设计错误层级和可执行的优质错误消息（第 3 章）；你还会把它们转化为场景测试（第 4 章）。
• 在发布后，你会从用户反馈中收集这些场景（第 5 章）；在起步阶段，你会通过“客户发现访谈”获取它们（第 6 章）。
• 在设计阶段，你会基于“按优先级整理的场景全集”制定产品路线图，并形成更细的用户流程（第 7 章）。
• 场景还会指导细粒度交互设计（第 8 章）和架构决策，例如用于生成负载模拟（第 9 章）。

使用场景需要练习，但我们并非从零开始。毕竟我们从很小就学习故事。我们天生能够阅读并理解故事。作为产品思维工程师，我们还必须学会生成故事并批判故事。

Alice 在解释她如何使用故事时，用了一个词：conviction（确信）。当她构建出正确场景时，她能感受到这种力量，并由此相信自己的产品会奏效。在需要取舍的讨论中，她可以通过推演不同故事出现的相对概率来决策。她能带着确信发布，因为她的测试覆盖了最关键的场景。她也能把这些场景一路串到所有需要实现的组件上，确保它们共同让故事成立。

章节小结

我梳理了工程师进行产品思维的基础，并给出以下建议。

• 场景是“行为模拟 + 人物画像”的组合。用完整场景理解用户及其处境，并指导产品决策。
• 模拟是把注意力聚焦到关键处的强大工具。不要只看界面，要看到用户旅程。
• 人物画像确保你与产品目标受众真正连接。
• 通过“换鞋思考”与“选择性失忆”在日常中持续共情用户。
• 在整个产品生命周期使用场景。随着设计走向实现，让故事逐步细化。

这些基础会贯穿全书。你当然可以从这里开始跳读，但我接下来会先讲产品如何与用户沟通，深入命名和信息架构等主题，因为它们是最常见的产品决策。练好这些，是让产品思维变成本能的好路径。

练习

在这些练习中，我们假设自己在 Wikipedia.org 工作。

1. 列出至少两类使用 Wikipedia 的人物画像，并分别描述。请确保你考虑到这些用户重视什么。（我的答案会覆盖两类宽泛画像。）
2. Wikipedia 想提升文章质量，尤其是低热度语言条目。当前用户必须点击“Edit”链接才能编辑内容。Wikipedia 是否应该提供顺滑的行内编辑体验来消除这层摩擦？
3. 假设你在设计 Wikipedia 页面顶部搜索框里的搜索功能。选用问题 1 中的一个画像，写一段场景，展示读者如何使用“typeahead”功能（即在输入时内联展示可能结果），从而不必加载单独搜索页。请用该场景凸显实现需要解决的问题。
4. 假设你在设计 Wikipedia 的“Watch this page”功能，让编辑者订阅页面变更。选用问题 1 中的一个画像，至少写两段场景，帮助团队思考人们会如何使用它。（即便你从未使用过该功能也没关系，请按你认为合理的方式设想。）

参考答案

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”。在设置页上，他看到几个以前没注意到的复选框：可以取消“接收未编辑区段的通知”和“接收小改动通知”。他意识到自己只愿意订阅与本人编辑区段相关的变更，于是取消勾选了前一个选项。