其他团队用得上，体系才算建立
体系推广里，如果体系采用仍是只在设计团队内部使用，结果往往是别的团队仍在用自己的做法。
文章 · 设计体系 · 地产与文旅
例外要被记录，否则体系会被悄悄改写
日常设计里，如果例外记录仍是口头同意一次例外，结果往往是同样的例外反复出现，变成事实上的新规则。更稳妥的做法是每次例外留下记录，并定期决定是否改规则，并用例外记录把这个选择固定下来。
核心要点
- 在日常设计里，例外记录不该继续停留为口头同意一次例外。
- 放着不管，就会反复出现同一件事：同样的例外反复出现，变成事实上的新规则。
- 起点换成：每次例外留下记录，并定期决定是否改规则。
- 把选择写进例外记录，由体系维护人。
- 以后只按一个问题验收：这个例外是否已经被写下来，而不是只在对话里。
01例外记录停在了哪里
在日常设计里，例外记录通常被写成口头同意一次例外。大家愿意点头，是因为还没碰到真正的问题：同样的例外反复出现，变成事实上的新规则。
会议结束得很快。真正使用例外记录的人一离开房间，手里只剩这件事：同样的例外反复出现，变成事实上的新规则。
每次例外留下记录，并定期决定是否改规则。做不到这一点，例外记录就还停在口头同意一次例外。
02例外记录真正卡住的地方
卡点不在文采。口头同意一次例外可以解释很多场合，也就挡不住：同样的例外反复出现，变成事实上的新规则。
当更多的人同时向例外记录要答案，它只会变得更抽象，旧问题回到桌上：同样的例外反复出现，变成事实上的新规则。
03重新定义例外记录
更有用的起点是每次例外留下记录，并定期决定是否改规则。先把拒绝写清楚，例外记录才开始承担选择。
若继续保留口头同意一次例外，表达会更顺，这件事却还在：同样的例外反复出现，变成事实上的新规则。
04把例外记录收成工具
把这个起点写成例外记录。对例外记录来说，这一页比另一版较长的说明更有用。
同意例外时，只对照例外记录。不要在每次讨论里重新发明一句例外记录。
05谁来维护例外记录
维护责任要落在具体的人：体系维护人。没有维护人的例外记录，会在第一次冲突里被改写。
验收只留一个问题：这个例外是否已经被写下来，而不是只在对话里。答不上来，例外记录就还不是决策。
框架图
例外记录的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把例外记录重新写成口头同意一次例外。
L1例外
这一层写明例外记录里什么不能让渡。
L2原因
这一层把例外记录收成可检查的条件。
L3是否改规则
这一层规定例外记录在不同场合可以变什么。
L4期限
这一层把例外记录交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在日常设计里标出例外记录真正被调用的时刻，不要从改写口头同意一次例外开始。
行动 02
收成一页
用例外记录代替更长的说明，只保留能支持「每次例外留下记录，并定期决定是否改规则」的内容。
行动 03
按一个问题验收
同意例外时，只问：这个例外是否已经被写下来，而不是只在对话里。答不上来，就还不是决策。
行动 04
写明维护人
体系维护人。没有维护人的例外记录，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
包装是媒介，不只是容器
包装简报里，如果包装仍是只要求装得下、运得动，结果往往是包装在货架上什么都没说。
包装上的信息要有主次
包装文案里，如果包装信息仍是所有卖点同样大小，结果往往是人在货架前读不到第一句。