新增组件要有进入规则
体系使用中里，如果组件进入仍是谁需要谁就加一个组件，结果往往是组件变多，体系变乱。
文章 · 设计体系 · 金融
设计体系要有维护人
体系发布之后里，如果体系维护仍是发布完就视为完成，结果往往是例外越积越多，没有人更新体系。更稳妥的做法是指定维护人，并写明什么情况必须更新，并用维护职责把这个选择固定下来。
核心要点
- 在体系发布之后里，体系维护不该继续停留为发布完就视为完成。
- 放着不管，就会反复出现同一件事：例外越积越多，没有人更新体系。
- 起点换成：指定维护人，并写明什么情况必须更新。
- 把选择写进维护职责，由设计负责人。
- 以后只按一个问题验收：出现一次例外后，是否有人负责决定改体系还是拒绝。
01体系维护要停止什么
体系维护先要停止的，是发布完就视为完成。在体系发布之后里，停不下来的说法会直接带来：例外越积越多，没有人更新体系。
继续做的部分可以很少。少，才守得住指定维护人，并写明什么情况必须更新。
指定维护人，并写明什么情况必须更新。做不到这一点，体系维护就还停在发布完就视为完成。
02体系维护的模糊从哪里漏出去
模糊通常从好意的补充里漏出去。人们为了照顾更多场合，把体系维护又写回发布完就视为完成。
每一次补充如果不回头看清问题，边界都会更难执行。问题就是：例外越积越多，没有人更新体系。
03先给体系维护写负面清单
负面清单比形容词有用。写上什么情况下不能使用体系维护，团队才知道指定维护人，并写明什么情况必须更新不是口号。
清单要短，短到发布时还能被完整看完。
04用工具拦住体系维护越界
维护职责用来拦住越界，而不是用来收集灵感。越界的想法可以存在，但不能冒充体系维护。
拦得住，是因为设计负责人，并且有权说不。
05体系维护越界之后怎么办
越界之后不要只改一条成品。要回到维护职责，补上这次被绕过的条件。
然后用同一个问题复查：出现一次例外后，是否有人负责决定改体系还是拒绝。
框架图
体系维护的四层结构
从不可让渡的部分到现场可用的工具，每一层只回答一个问题，避免把体系维护重新写成发布完就视为完成。
L1维护人
这一层写明体系维护里什么不能让渡。
L2必须更新
这一层把体系维护收成可检查的条件。
L3可以拒绝
这一层规定体系维护在不同场合可以变什么。
L4周期
这一层把体系维护交给使用的人，并写明例外。
注：本图为概念框架示意，用于说明思考结构，不代表任何统计数据。来源：清美未来洞察团队。
行动建议
行动 01
先看现场
在体系发布之后里标出体系维护真正被调用的时刻，不要从改写发布完就视为完成开始。
行动 02
收成一页
用维护职责代替更长的说明，只保留能支持「指定维护人，并写明什么情况必须更新」的内容。
行动 03
按一个问题验收
发布时，只问：出现一次例外后，是否有人负责决定改体系还是拒绝。答不上来，就还不是决策。
行动 04
写明维护人
设计负责人。没有维护人的体系维护，会在冲突里被悄悄改掉。
相关
全部洞察相关洞察
例外要被记录，否则体系会被悄悄改写
日常设计里，如果例外记录仍是口头同意一次例外，结果往往是同样的例外反复出现，变成事实上的新规则。
其他团队用得上，体系才算建立
体系推广里，如果体系采用仍是只在设计团队内部使用，结果往往是别的团队仍在用自己的做法。