| name | scenario-boundary-design |
| description | 当用户需要判断某功能在什么场景成立、默认打开还是关闭、主入口还是隐藏、插件还是内置、做全功能还是只抓主场景时调用。
不适用于: 纯视觉稿美化、无需场景判断的简单文案修改。
|
| source_book | 《微信背后的产品观》 张小龙 |
| source_chapter | 需求篇、设计篇、UI篇 |
| tags | ["product","scenario","boundary"] |
| related_skills | ["demand-psychology-mining","product-structure-evolution"] |
面向场景的边界设计
R — 来源
原书依据见本节来源说明。
依据书中“只抓主场景”“面向场景来做设计”“让功能存在无形之中”“宁愿损失功能也不损失体验”等论述。
I — 方法论骨架
功能脱离场景没有意义。
同一个功能在一个场景里是体贴，在另一个场景里就是打扰。
产品设计要先定义主场景，再决定功能是否应被看见、是否默认、是否可选、是否插件化、是否只给少数人隐藏入口。
边界不是少做，而是保护主体验不被边缘情况拖垮。
当一个功能会增加管理负担、误操作、社交压力或系统复杂度时，应优先考虑隐藏、延后、抽象或不做。
A1 — 书中的应用
案例: 语音自动播放
- 问题: 会话中的新语音是否应该自动播放。
- 方法论的使用: 作者把自动播放拆到独处、驾驶、会议、公共场合等具体场景。
- 结论: 默认自动播放会伤害隐私和公共场合体验。
- 结果: 功能不能以“自动就是好”来判断，必须面向场景。
案例: 朋友圈纯文字入口
- 问题: 朋友圈是否应支持纯文字。
- 方法论的使用: 主场景是低成本照片表达，纯文字是少数需求。
- 结论: 可以支持但隐藏入口，避免改写主场景。
- 结果: 保持照片表达的产品方向。
A2 — 触发场景
- 用户纠结功能入口要不要放首页。
- 用户要决定功能默认开关、隐藏入口、插件化或卸载能力。
- 用户想减少打扰、误触、管理负担或说明文字。
- 用户在“完整功能”和“主体验克制”之间冲突。
语言信号
- “这个功能入口放哪里”
- “默认开还是关”
- “要不要做全”
- “会不会打扰用户”
- “主场景是什么”
- “能不能隐藏起来”
与相邻 skill 的区分
- 与
demand-psychology-mining 的区别: 后者判断需求是否真实，本 skill 判断怎么在场景中落地。
- 与
product-structure-evolution 的区别: 本 skill 处理功能级取舍，后者处理系统级结构和长期演化。
E — 可执行步骤
-
列出场景矩阵
- 完成标准: 至少列出主场景、边缘场景、风险场景和不该服务的场景。
-
判断默认行为
- 完成标准: 明确默认开/关、显性/隐性、主入口/二级入口/隐藏入口/插件化/不做。
-
检查副作用
- 完成标准: 逐项检查误触、社交压力、隐私、学习成本、说明文字、复杂度和主体验污染。
-
输出边界方案
- 完成标准: 给出一个保护主场景的方案，并说明牺牲了哪些边缘功能。
B — 边界
- 不适用于纯工程排期或视觉细节任务。
- 不应把“隐藏”当成偷懒；隐藏前要确认主场景不受损。
- 低频高风险产品可能需要显式确认和强提示，不能盲目追求无感。
- 无障碍、合规和安全提示不能因为“打扰”就取消。
失败模式
- 认为功能越全越好。
- 怕用户不知道，所以到处加 Tips。
- 用弹窗教育用户。
- 为少数边缘场景破坏所有用户的主路径。
相关 skills
- depends-on: {demand-psychology-mining}
- composes-with: {product-structure-evolution, product-spirit-expression}
- contrasts-with: {feature-completeness-design}
审计信息
- 源文件:
wechat-product-philosophy-skill/source/SOURCE.md
- 验证通过: V1 ✓ / V2 ✓ / V3 ✓
- 测试通过率: 待 darwin 运行
- 蒸馏时间: 2026-06-14
