体验旅程源于未知，始于设计(2)

一、旅程关键点与内部业务
很多刚开始做体验类工作的人，都会遇到这样的问题——找到的体验旅程关键点，怎么对应了那么多的业务块呢？到底该归属哪一块业务呢？
提炼出的关键点如果不能让有所涉及的业务块信服的话，问题是推不动、解决不了的。
所以，要想实现这一点的清晰化，就要明确所确定的关键点是否是准确的、可解析的。
准确，无需精准，只需要确定的范围和方向是正确的，即可。这些都可以从反馈的问题点来确定，出现频率多的就可定义为一个关键点，后期循环的工作中可持续优化。
可解析，比较重要，直接关系到是否能够把关键点关联到内部。
如果关键点是具备可解析性的，那就要具备某些条件，怎么判断呢？
首先是问题点出现的频率高，这是基本条件。
其次是识别是否伴有相应的需求点，也就是说，不是单纯的问题。比如“在银行办业务取号等待时间太长，要是能够多开几个办事窗口就好了”这个关键点是带有需求的，那么在等待时长这个问题点上，银行内部同时需要考虑人员的排班问题和提升业务办理的时效能力。
确定了具备可解析性的关键点，接下来我们就可以逐步拆分出问题细节和归属。
拆分的方法推荐采用金字塔原理，越拆越细，越细就越准确。
最后，一个关键点所拆分出的每一个细节，所对应的业务块，也就明确了。
1. 痛点的真实性
在体验旅程中呈现出的各种痛点，其实也是可以分类、区别对待的。
首先，痛点是人为定义的，问题反映的量级大、频率高、投诉多，那它就是产品的痛点、服务的痛点。
其实不然，不完全是这样的。
起初我们可以用这样的思路来确定哪些问题是痛点。
但是确定完之后，痛点也是要被再次分类，并且深入分析的，才能确定是否这个痛点是真的客观的且普遍存在的。
有些痛点呈现的表象是假的，或许只是产品或服务本身的设计初衷，但不能改，改了可能会出现更多无解的问题。那这个痛点，对于企业内部来说，就不需要重点关注。
比如：某品牌手机的设置功能UI界面复杂，不如某品牌做得好、使用简单。
这个产品使用的痛点确实被反映的量级大，甚至投诉多，那需要改吗？答案是不需要的，这就是品牌的逼格。
而有些痛点是花了大成本设计出来的，即使它影响到了客户的体验感，企业也是可以用其他的爽点来弥补和冲抵的，使其产生更多的反向价值。