旅程要有人负责全程,而不是分段无人
跨部门体验里,如果全程负责仍是每段都有人优化自己的一段,结果往往是段与段之间没有人负责。


在流程简化里,摩擦若没有明确的负责人,就会退化成把所有步骤都当成障碍。大家都参与,也就没有人承担后果:该确认的地方被跳过,信任反而下降。
负责不是亲自改每一句,而是有人有权在冲突时维持区分要去掉的障碍和必须留下的确认。
区分要去掉的障碍和必须留下的确认。做不到这一点,摩擦就还停在把所有步骤都当成障碍。
交接不能靠口头。上一环交给下一环的,应是摩擦清单,而不是继续沿用把所有步骤都当成障碍。
没有交接物时,每个团队都会按自己的理解处理摩擦,接缝里冒出来的仍是:该确认的地方被跳过,信任反而下降。
节奏要固定。简化方案评审,比等到出了问题再开复盘会更节省注意力。
节奏一旦让给每一个临时战役,摩擦就只在发布当天存在。
使用方式要简单。打开摩擦清单的人,应能判断眼下这件事该不该做。
如果使用摩擦清单还需要专人翻译,它就还是把所有步骤都当成障碍,只是换了载体。
做完的标准不是发出去了。标准是:这个步骤拿掉后,顾客是否失去一次必要的确认。
体验与业务一起。人离开岗位时,摩擦清单还在,摩擦才没有停在某一次项目里。
从不可让渡的部分到现场可用的工具,每一层只回答一个问题,避免把摩擦重新写成把所有步骤都当成障碍。
这一层写明摩擦里什么不能让渡。
这一层把摩擦收成可检查的条件。
这一层规定摩擦在不同场合可以变什么。
这一层把摩擦交给使用的人,并写明例外。
注:本图为概念框架示意,用于说明思考结构,不代表任何统计数据。来源:清美未来洞察团队。
在流程简化里标出摩擦真正被调用的时刻,不要从改写把所有步骤都当成障碍开始。
用摩擦清单代替更长的说明,只保留能支持「区分要去掉的障碍和必须留下的确认」的内容。
简化方案评审,只问:这个步骤拿掉后,顾客是否失去一次必要的确认。答不上来,就还不是决策。
体验与业务一起。没有维护人的摩擦,会在冲突里被悄悄改掉。
跨部门体验里,如果全程负责仍是每段都有人优化自己的一段,结果往往是段与段之间没有人负责。
体验设计里,如果时刻承诺仍是一个时刻里堆进很多好处,结果往往是人记不住此刻到底在兑现什么。
服务蓝图里,如果补救设计仍是只设计顺利的路径,结果往往是一出错就靠个人发挥,体验随人而变。