RULE
用户视角优先
[RULE] 用户视角优先
- 类型: 原则
- 强度: 9/10
- 验证: ✓2 / ✗0
定义
IF: 设计产品功能、系统行为或交互流程
THEN: 从用户的第一人称视角出发，而非技术/系统视角
- 问感受：用户会怎么感受这个结果？
- 问理解：用户会怎么理解这个行为？
- 问心智：用户的心智模型是什么？
原理
用户不关心系统怎么运作，只关心世界发生了什么。
用户在使用产品时，心智模型是"真实世界"——邮件是别人发的，日历是事件发生的时间，消息是朋友说的话。用户不会、也不应该关心"数据库更新了"、"同步完成了"、"标签变更了"。
第一人称 vs 第三人称：
| 视角 | 关注点 | 语言 |
|---|---|---|
| 第一人称（用户） | 世界发生了什么 | "我收到了邮件"、"会议改时间了" |
| 第三人称（系统） | 系统做了什么 | "数据同步完成"、"标签已更新" |
好的产品设计，是让用户始终停留在第一人称视角。
三问检验
设计任何功能时，问自己：
| 问题 | 目的 |
|---|---|
| 用户会怎么感受？ | 避免打扰、困惑、不信任 |
| 用户会怎么理解？ | 确保行为符合心智模型 |
| 用户的心智模型是什么？ | 对齐真实世界的因果 |
下位规则
本规则是以下具体规则的上位原则：
| 下位规则 | 关注点 |
|---|---|
| RULE-不对称风险原则 | 用户对打扰的感知 > 对价值的感知 |
| RULE-真实世界语义保持 | 系统行为 = 真实世界因果 |
示例
| 场景 | 系统视角（错） | 用户视角（对） |
|---|---|---|
| 邮件标签变更 | "数据有更新，通知用户" | "没有新邮件，不打扰" |
| 历史数据补录 | "同步完成，推送通知" | "这是过去的事，静默处理" |
| 会议时间变更 | "日历事件已修改" | "会议改到下午3点了" |
| 错误提示 | "Error 500: Internal Server Error" | "出了点问题，请稍后再试" |
与其他规则的关系
- 是 RULE-不对称风险原则 的上位原则
- 是 RULE-真实世界语义保持 的上位原则
- 和 RULE-人机分工原则 互补——人负责理解用户，AI 负责执行
- 和 RULE-一句话检验 呼应——能用用户语言解释的设计才是对的
反模式
- 技术驱动："这样实现更方便"
- 内部视角："系统需要通知用户这个变更"
- 功能堆砌："多一个功能总比少一个好"
- 假设用户懂技术："用户应该理解这是同步延迟"
证据
支持
- INFO-117：用户认知图谱（第一人称心智模型 vs 第三人称世界模型）
- INFO-097：虚拟EA工作法（先理解用户，再行动）
反例
- 专业工具：面向技术用户的产品可以暴露更多系统细节
- 调试模式：排查问题时需要系统视角
- 透明度要求：某些场景用户需要知道系统在做什么（如数据处理进度）
触发检查
设计产品功能时，强制问自己：
- 如果我是用户，我会期望什么？
- 这个行为用日常语言怎么解释？
- 用户需要知道这个吗？还是系统应该默默处理？
关联
- INFO: INFO-117、INFO-097
- RULE: RULE-不对称风险原则、RULE-真实世界语义保持、RULE-人机分工原则
- NODE: NODE-用户视角优先、NODE-AI-Agent