scenario-boundary-design

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 — 触发场景

1. 用户纠结功能入口要不要放首页。
2. 用户要决定功能默认开关、隐藏入口、插件化或卸载能力。
3. 用户想减少打扰、误触、管理负担或说明文字。
4. 用户在“完整功能”和“主体验克制”之间冲突。

语言信号

• “这个功能入口放哪里”
• “默认开还是关”
• “要不要做全”
• “会不会打扰用户”
• “主场景是什么”
• “能不能隐藏起来”

与相邻 skill 的区分

• 与 demand-psychology-mining 的区别: 后者判断需求是否真实，本 skill 判断怎么在场景中落地。
• 与 product-structure-evolution 的区别: 本 skill 处理功能级取舍，后者处理系统级结构和长期演化。

E — 可执行步骤

1. 列出场景矩阵

   • 完成标准: 至少列出主场景、边缘场景、风险场景和不该服务的场景。

2. 判断默认行为

   • 完成标准: 明确默认开/关、显性/隐性、主入口/二级入口/隐藏入口/插件化/不做。

3. 检查副作用

   • 完成标准: 逐项检查误触、社交压力、隐私、学习成本、说明文字、复杂度和主体验污染。

4. 输出边界方案

   • 完成标准: 给出一个保护主场景的方案，并说明牺牲了哪些边缘功能。

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