诊断要同时看覆盖和深度
诊断项目里,如果触点诊断仍是只看有没有这个触点,结果往往是有触点,但深到不足以影响决定。


触点删减先要停止的,是只加不减。在体验优化里,停不下来的说法会直接带来:人被更多信息打扰,关键时刻却被冲淡。
继续做的部分可以很少。少,才守得住列出可以拿掉且不影响承诺的触点。
列出可以拿掉且不影响承诺的触点。做不到这一点,触点删减就还停在只加不减。
模糊通常从好意的补充里漏出去。人们为了照顾更多场合,把触点删减又写回只加不减。
每一次补充如果不回头看清问题,边界都会更难执行。问题就是:人被更多信息打扰,关键时刻却被冲淡。
负面清单比形容词有用。写上什么情况下不能使用触点删减,团队才知道列出可以拿掉且不影响承诺的触点不是口号。
清单要短,短到优化方案里还能被完整看完。
删减清单用来拦住越界,而不是用来收集灵感。越界的想法可以存在,但不能冒充触点删减。
拦得住,是因为体验负责人,并且有权说不。
越界之后不要只改一条成品。要回到删减清单,补上这次被绕过的条件。
然后用同一个问题复查:拿掉之后,承诺是否仍然完整。
从不可让渡的部分到现场可用的工具,每一层只回答一个问题,避免把触点删减重新写成只加不减。
这一层写明触点删减里什么不能让渡。
这一层把触点删减收成可检查的条件。
这一层规定触点删减在不同场合可以变什么。
这一层把触点删减交给使用的人,并写明例外。
注:本图为概念框架示意,用于说明思考结构,不代表任何统计数据。来源:清美未来洞察团队。
在体验优化里标出触点删减真正被调用的时刻,不要从改写只加不减开始。
用删减清单代替更长的说明,只保留能支持「列出可以拿掉且不影响承诺的触点」的内容。
优化方案里,只问:拿掉之后,承诺是否仍然完整。答不上来,就还不是决策。
体验负责人。没有维护人的触点删减,会在冲突里被悄悄改掉。
诊断项目里,如果触点诊断仍是只看有没有这个触点,结果往往是有触点,但深到不足以影响决定。
多渠道服务里,如果答案一致仍是每个渠道按自己的习惯回答,结果往往是人换一个渠道就得到另一个答案。
体验方案里,如果员工可行性仍是只从顾客一侧设计,结果往往是方案很好,现场的人做不到。