2.4.2 产品即故事：用叙事结构思考需求
一个常见的错误
还记得小李吗？他在学会了「任务视角」和「减法思维」后，再次打开 AI 工具，输入了这样的需求：
"做一个待办清单，核心功能是：添加任务、完成任务、查看任务。"
这比他最初列 14 个功能好多了。但结果呢？
AI 给出的设计中规中矩：一个输入框、一个列表、一个勾选按钮。能用，但没有任何亮点。
小李总觉得少了点什么，却说不清楚问题在哪。
问题出在哪？
小李的需求描述虽然简洁，但缺少一样关键的东西：故事。
他只告诉 AI「要做什么功能」，却没有告诉 AI「为谁做」「在什么场景下用」「用户真正想要的感受是什么」。
没有故事的需求，就像没有灵魂的躯壳。
故事的基本结构
从亚里士多德的《诗学》到好莱坞的剧本写作，所有好故事都遵循一个基本结构：
开端 → 冲突 → 解决 → 结局- 开端：主角的日常生活，建立背景
- 冲突：主角遇到了问题，打破平衡
- 解决：主角找到方法，克服困难
- 结局：问题解决，主角获得成长或满足
这个结构之所以有效，是因为它符合人类理解世界的方式：我们通过「某人遇到问题并解决它」的叙事来理解事物。
产品版本的故事结构
把这个结构应用到产品设计中，就变成了：
| 故事阶段 | 产品视角 | 用户视角 |
|---|---|---|
| 开端 | 用户的现状 | 我是谁，我的日常是什么样的 |
| 冲突 | 用户的痛点 | 我遇到了什么问题，为什么难受 |
| 解决 | 用户发现并使用产品 | 我发现了这个工具，它帮我解决了问题 |
| 结局 | 用户获得价值 | 我的生活/工作变好了，我感到满足 |
案例对比：功能视角 vs 故事视角
待办清单（贯穿案例）
功能视角的描述：
做一个待办清单，有添加、完成、查看功能。
故事视角的描述：
小李是一个互联网公司的运营，每天要处理 10 件以上的事情。他试过用便签纸，但经常丢；试过几个待办 App，录入比做事还累。他最大的焦虑是「怕漏掉重要的事」。
他需要一个工具：打开就能记，记完就能忘，做完一件划掉一件，晚上看着清空的列表安心下班。
感受到区别了吗？故事版本让你能「看到」这个用户，理解他的处境和期望。
更多场景的故事化描述
| 场景 | 功能视角 | 故事视角 |
|---|---|---|
| 读书笔记 | 做一个读书笔记工具，能划线、能收集、能导出 | 小王每天通勤时在手机上看书，看到好句子想划线保存。但现在的阅读 App 划完线就找不到了，想回顾时要翻半天。她希望有个地方能把所有书的划线自动收集起来，闲暇时翻翻就能重温。 |
| Excel 汇总 | 写一个脚本，自动汇总 5 个 Excel 表格 | 老张是财务主管，每周五要汇总 5 个部门的周报。每次都是同样的操作：打开 5 个文件，复制粘贴到汇总表，调整格式。这个流程要花 2 小时，而且容易出错。他希望点一下就能搞定，把时间花在分析数据上。 |
| 吃药提醒 | 做一个提醒 App，定时推送通知 | 我 60 岁的妈妈有高血压，每天要吃 2 次药。她经常忘记吃没吃过，有时候会重复吃。她不太会用复杂的 App，密密麻麻的字看不清。她只需要一个东西：到点提醒，吃完点一下「吃了」，这样她和我都知道今天吃过了。 |
为什么故事视角更有效
当你用故事描述需求时，会自然获得这些好处：
| 好处 | 说明 |
|---|---|
| 约束更清晰 | 「60 岁妈妈」自动排除了复杂功能，「每天 10 件事」暗示了简洁的重要性 |
| 优先级更明确 | 「怕漏掉重要的事」告诉你核心是「不遗漏」，不是「好看的界面」 |
| AI 理解更准确 | AI 能基于故事推断出你没明说的需求，比如「大字体」「少步骤」 |
| 自己也更清楚 | 写故事的过程会逼你想清楚「到底为谁做」 |
练习：把你的想法变成故事
试着用这个结构，为你自己的想法写一个简短的故事：
markdown
## 我的用户故事
### 开端：用户的日常
[描述用户是谁，他的日常是什么样的]
### 冲突：用户的痛点
[描述用户遇到了什么问题，为什么感到困扰]
### 解决：用户发现产品
[描述用户如何使用你的产品解决问题]
### 结局：用户获得价值
[描述问题解决后，用户的生活/工作有什么改变]不需要很长，3-5 句话就够。关键是让你（和 AI）能「看到」这个用户。
本节要点
故事不是可选的修饰，而是需求描述的核心：
- 功能视角只告诉 AI「做什么」，故事视角还告诉 AI「为谁做」「为什么做」
- 好故事遵循「开端→冲突→解决→结局」的结构
- 写故事的过程会帮你自己想清楚需求
接下来，我们深入故事的主角——用户。如何构建一个真正立体的用户形象？