B3.07.3Flexibility and Efficiency of Use设计
灵活性不应以牺牲默认路径为代价
别名: 默认路径 · 灵活配置 · 主流程 · 恢复默认
概念解释
灵活配置、专家旁路和个性化工作区必须建立在清晰默认路径之上。默认路径（default path）是新用户、临时角色、恢复场景和跨团队交接可以依赖的公共流程；灵活性不能让功能只存在于某人配置之后。这一条是前两条（加速器、自定义）共同的约束条件——它不描述灵活性该怎么给，而是划出灵活性不能碰的底线，三张卡合起来才是完整的规则。
机制
默认路径承担的不只是"新手第一次用"这一个场景，还包括教学、协作、故障恢复和测试基准这四个更容易被忽略的作用：客服描述操作步骤时依赖的是默认路径而不是某个客户的私人配置；自动化测试和验收标准通常也是针对默认路径编写的；系统出故障需要排查时，工程师第一反应是确认默认路径是否受影响，而不是逐个还原每个用户的个性化状态。如果所有入口都可移除、术语可任意替换、布局可无限重组，这四类依赖会同时失效：系统对新手变成黑箱，支持团队无法用统一的语言描述步骤，文档和自动化也失去了稳定的引用对象。灵活性因此应该表现为在公共对象和动作上叠加视图、快捷方式和规则，而不是替换底层语义——叠加可以随时剥离回到默认，替换则做不到。
边界
默认也不是永久不可变。产品应随任务变化更新默认，但需要版本记录、迁移路径和变更通知，否则"更新默认"本身也会变成一次隐蔽的破坏性变更。安全场景可能出于合规需要为特定角色锁定默认、禁止个性化，这种限制必须向用户解释原因，否则会被当成产品缺陷投诉。对已经形成高度成熟内部流程的团队，强行把所有人拉回统一默认可能反而降低效率——这种情况下更合适的做法是提供团队级模板作为该团队的"新默认"，而不是在个人和全局默认之间二选一。
怎么落地
- 明确定义哪些是不可移除的公共对象、核心动作、权限模型和最低限度的信息结构，写成团队内部可以对照检查的清单，而不是留给每个人凭感觉判断。
- 允许隐藏、重排或加速，但不允许让主流程失去入口；"恢复默认"必须是一键可得的操作，不能要求用户手动逐项撤销自定义。
- 文档、培训、测试用例和客服话术都以默认路径为基准编写，自定义带来的差异单独列出补充说明，避免主文档随着每种个性化配置分叉。
- 验证办法：用一个全新账户、关闭全部自定义配置，独立跑一遍核心任务清单，确认公共路径本身完整可用；再对比启用高度自定义的账户，检查两者能否得到同一个正确结果。