例外要被记录，否则体系会被悄悄改写
日常设计里，如果例外记录仍是口头同意一次例外，结果往往是同样的例外反复出现，变成事实上的新规则。
文章 · 设计体系 · 教育
新增组件要有进入规则
体系使用中里，如果组件进入仍是谁需要谁就加一个组件，结果往往是组件变多，体系变乱。更稳妥的做法是新增前要说明已有组件为什么不够，并用进入规则把这个选择固定下来。
核心要点
- 在体系使用中里，组件进入不该继续停留为谁需要谁就加一个组件。
- 放着不管，就会反复出现同一件事：组件变多，体系变乱。
- 起点换成：新增前要说明已有组件为什么不够。
- 把选择写进进入规则，由体系维护人。
- 以后只按一个问题验收：申请是否写明了已有组件的不足。
01组件进入如何被翻译
组件进入写在文件里并不等于已经到达体系使用中。翻译的第一步，是新增前要说明已有组件为什么不够。
若翻译只是把谁需要谁就加一个组件缩短，一线遇到的仍是：组件变多，体系变乱。
新增前要说明已有组件为什么不够。做不到这一点，组件进入就还停在谁需要谁就加一个组件。
02组件进入在哪一步变形
组件进入最常在任务拆开时变形。部门各自领走一句好说的话，却没有领走对应的拒绝。
于是对外仍能看见谁需要谁就加一个组件，对内却解释不了：组件变多，体系变乱。
03组件进入的最小翻译单位
组件进入的最小单位不是一整本手册，而是一个能当场使用的判断。进入规则就应该是这个单位。
一线拿到组件进入，不必再猜品牌部门会怎么想。
04一线拿到的组件进入
每次申请，抽一处现场，看进入规则有没有退回到谁需要谁就加一个组件。
改写不一定是坏事。坏的是改写之后没有人承认组件进入已经变了。
05组件进入的判断力放在哪里
判断力要留在使用的人身上。体系维护人，同时让现场有权按进入规则拒绝。
培训结束时只考一个问题：申请是否写明了已有组件的不足。
框架图
组件进入的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把组件进入重新写成谁需要谁就加一个组件。
L1不足
这一层写明组件进入里什么不能让渡。
L2新组件
这一层把组件进入收成可检查的条件。
L3不通过
这一层规定组件进入在不同场合可以变什么。
L4合并
这一层把组件进入交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在体系使用中里标出组件进入真正被调用的时刻，不要从改写谁需要谁就加一个组件开始。
行动 02
收成一页
用进入规则代替更长的说明，只保留能支持「新增前要说明已有组件为什么不够」的内容。
行动 03
按一个问题验收
每次申请，只问：申请是否写明了已有组件的不足。答不上来，就还不是决策。
行动 04
写明维护人
体系维护人。没有维护人的组件进入，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
其他团队用得上，体系才算建立
体系推广里，如果体系采用仍是只在设计团队内部使用，结果往往是别的团队仍在用自己的做法。
包装是媒介，不只是容器
包装简报里，如果包装仍是只要求装得下、运得动，结果往往是包装在货架上什么都没说。