设计体系要有维护人
体系发布之后里,如果体系维护仍是发布完就视为完成,结果往往是例外越积越多,没有人更新体系。


模板写在文件里并不等于已经到达模板制定。翻译的第一步,是模板只锁住不能让渡的决定,其余允许差别。
若翻译只是把模板把所有细节都定死缩短,一线遇到的仍是:人们要么照抄,要么完全不用。
模板只锁住不能让渡的决定,其余允许差别。做不到这一点,模板就还停在模板把所有细节都定死。
模板最常在任务拆开时变形。部门各自领走一句好说的话,却没有领走对应的拒绝。
于是对外仍能看见模板把所有细节都定死,对内却解释不了:人们要么照抄,要么完全不用。
模板的最小单位不是一整本手册,而是一个能当场使用的判断。模板说明就应该是这个单位。
一线拿到模板,不必再猜品牌部门会怎么想。
模板评审,抽一处现场,看模板说明有没有退回到模板把所有细节都定死。
改写不一定是坏事。坏的是改写之后没有人承认模板已经变了。
判断力要留在使用的人身上。设计负责人,同时让现场有权按模板说明拒绝。
培训结束时只考一个问题:使用者能否说出哪些地方可以不同。
从不可让渡的部分到现场可用的工具,每一层只回答一个问题,避免把模板重新写成模板把所有细节都定死。
这一层写明模板里什么不能让渡。
这一层把模板收成可检查的条件。
这一层规定模板在不同场合可以变什么。
这一层把模板交给使用的人,并写明例外。
注:本图为概念框架示意,用于说明思考结构,不代表任何统计数据。来源:清美未来洞察团队。
在模板制定里标出模板真正被调用的时刻,不要从改写模板把所有细节都定死开始。
用模板说明代替更长的说明,只保留能支持「模板只锁住不能让渡的决定,其余允许差别」的内容。
模板评审,只问:使用者能否说出哪些地方可以不同。答不上来,就还不是决策。
设计负责人。没有维护人的模板,会在冲突里被悄悄改掉。
体系发布之后里,如果体系维护仍是发布完就视为完成,结果往往是例外越积越多,没有人更新体系。
体系使用中里,如果组件进入仍是谁需要谁就加一个组件,结果往往是组件变多,体系变乱。
日常设计里,如果例外记录仍是口头同意一次例外,结果往往是同样的例外反复出现,变成事实上的新规则。