场景锚点
用一个具体的人在具体时刻的处境，代替一句用户觉得不方便。
用一个具体的人在具体时刻的处境，代替一句「用户觉得不方便」。抽象的需求推不出设计，具体的处境可以。这也是「待完成的任务」思路的核心：用户买的不是产品，是产品帮他在某个时刻完成的那件事。hbr-jtbd
你会遇到的现象：
- 团队每个人对同一句需求的理解都不一样
- 讨论方案时全靠「我觉得」，没有判断依据
- 让 AI 生成界面，它给的是一个放之四海皆可的通用页面
抽象描述的问题不是不准确，是它同时兼容太多种做法。「更快地录入」既可以是语音输入，也可以是快捷模板，还可以是自动识别，每一种都符合这句话。等你做完，才发现用户要的是第四种。
锚点的五个要素
| 要素 | 例子 | 注意 |
|---|---|---|
| 谁 | 摆摊的老王，五十岁，用一部老安卓机 | 不是「小微商家」这种词 |
| 什么时候 | 晚上九点收摊，路灯下，一手数钱 | 环境决定字号、按钮大小、单手操作 |
| 想达成什么 | 今天收了多少钱，心里有数 | 不是「记账」，记账是手段 |
| 卡在哪 | 记到一半来客人，回头忘了记到哪 | 这一条是产品的主任务 |
| 现在怎么办 | 在烟盒上划正字，回家再抄一遍 | 替代方案，也是你的竞争对手 |
五条里最容易写错的是第三条。用户想达成的从来不是「使用你的产品」，记账、导出、筛选都是手段，背后那个状态才是目的。写的时候先动笔「卡在哪」和「现在怎么办」这两条：它们最难编，也最能检验你是不是真的了解用户——编不出来的锚点，多半是个假的。
怎么用它做决定
锚点写完之后，它就变成了一把尺子。每个方案拿过来量一遍：
| 候选方案 | 拿锚点量一量 | 结论 |
|---|---|---|
| 语音输入 | 收摊时周围吵，而且他不好意思对着手机说金额 | 否 |
| 拍照自动识别 | 他手里是零钱不是小票，没东西可拍 | 否 |
| 大按钮快捷金额 | 单手能按，被打断也不丢，符合他的常见面额 | 是 |
| 自动保存草稿 | 直接解决「回头忘了记到哪」这个主卡点 | 是 |
没有锚点的时候，这四个方案都「有道理」，只能靠嗓门或者职级来定。有锚点之后，前两个自己就淘汰了。
给 AI 的话
把锚点放进提示词里，生成的东西会立刻从通用模板变成有取舍的方案。
先记住这个使用场景，后面所有设计决定都要以它为准：
谁：[具体的人，含年龄、设备、熟练度]
什么时候：[时间、地点、环境，以及手上还在忙什么]
想达成：[他要的那个状态，不是他要用的功能]
卡在哪：[具体哪一步出问题，出问题的后果是什么]
现在怎么办：[他目前的替代方案]
基于这个场景，请先告诉我：
1. 这个场景对界面提出了哪些硬约束（字号、点击区域、
单手操作、能否被打断等）
2. 你打算做的主任务是什么，为什么不是别的
3. 有哪些常见做法在这个场景下反而不适用
我确认之后你再写代码。
第三问最有用。它会逼 AI 说出「语音输入在这个场景下不合适」这类判断，而不是把所有能想到的功能都堆上去。