今年年中我接手了一款BI产品，由于前期技术框架选型及产品框架设计的问题，导致产品的可扩展性出现问题，产品要优化体验必须先进行重构。
而原有产品虽然没有完全面向用户，但也已经有几千人的用户积累，对于To B 类型的产品，用户本身的学习成本高，用户教育需要耗费非常多的心血。
这就是说，要进行重构就必然影响到这些种子用户的利益，设计改变用户原有的使用习惯和心理设定，稍有不慎吐槽就能把你淹死。
大概是发自内心的对数据产品的热爱吧，我毅然决然接手了任务。
其实大家也能够预料到一些结局，产品改版成功，但是老用户吐槽不断，声音大抵是这样的：
- 产品用户体验不好，没有老产品好用
- 产品用户体验不好，不知道怎么用
而新用户也不甘示弱，声音大抵是这样的：体验不好，完全不知道怎么用
发现没有，用户没一句话都离不开体验不好。老板也来找我，“小坛，种子用户群都在反馈体验不好”。
众所周知，互联网产品的竞争就是用户体验和效率的竞争，而现在我似乎已经失去了用户体验这最最重要的一环，这让我很是焦虑——
用户说体验不好究竟是什么不好，是说交互体验不好？功能元素不好找？功能没有满足？产品设计流程不合理还是说样式不好看呢？我们又该从哪里下手去进行改进，提高用户体验呢？
01 对用户体验进行界定
在正式提出改进意见之前，我们先通过用户体验的5个层次对用户体验进行一个界定。
用户体验实际上包含5个层次，战略层、范围层、结构层、角色框架层和表现层。
战略层
我们在进行产品建设初期，通过战略层确定我们的产品目标用户、产品目标和产品使命、愿景，确定产品的调性。
范围层
而范围层是确定我们做什么不做什么，确定产品的边界。
一般情况下，除非产品界定混乱，搞不清楚自己到底要提供给用户的是什么，于是什么都给用户提供，复杂比较难出现这方面的吐槽。
比如，最近几年无论什么产品都希望能够跟社交挂钩，于是很多产品都会插一脚社交模块，这个操作至少能理解，但是有些数据分析类的产品提供新闻资讯模块希望通过提供新闻资讯来提高用户活跃和留存，这个操作就真的很迷了，原谅我没看懂。
产品结构就是产品的业务流程和信息架构， 框架层则是界面布局、内容元素以及交互流程。最后是表现层，是大家最熟悉吐槽最集中的区域，即页面的视觉样式。
实际上我们在产品进行改版时并没有涉及到产品战略定位的调整，产品定位依然是希望提供一款高性能的大数据可视化与自助分析产品为用户提供稳定高效的报表制作和数据分析服务。
从产品范围层上来说，产品依然围绕取数、制作报表和数据分析三大主体功能进行，同时包含常规管理模块，因此，范围层从根本上没有改变。
结构层
从产品结构层来看，产品则发生了较大的变化：
一是产品整体信息架构调整，将数据准备阶段的功能从原有架构中分离出来独立为一个模块，并将取数下载模块合并至这一模块。
而另一方面业务流程发生变化，由原有的高度耦合的一个连贯流程拆分为数据准备-制作报表/数据分析两个独立的流程。由于流程本身涉及到审批，因此独立的流程则涉及到两个单独的流程。
框架层
接着是框架层，信息架构的拆分，必然带来页面的部分重构，功能的部分分离同时，在产品设计中也会对前期体验不够的交互进行优化，因此，框架层改动也较大。
但因为数据分析/制作报表行业交互方式基本一致，即拖拽式的交互方式，以及较为统一的页面元素及功能操作流程，因此，虽有一定的改动，但更贴合行业使用习惯及用户多样化的分析需求。
表现层
最后是表现层，说实话，变现层改动很大，进行了视觉的重点优化，毕竟，作为一款有灵魂的BI产品，好看的皮囊也是用户最最关心的问题啊。
所以，从用户体验的5个层次来说，我们基本可以判断，用户所说的体验不好主要集中在产品结构层、框架层和表现层。那么我们的判断是否准确呢？
为了验证判断是否准确同时针对结论采取一定的措施进行干预，我们来针对用户进行了大范围的用户体验收集：邀请种子用户参与讨论，发表意见，究竟是哪里体验不好，大家的诉求究竟是怎样的，通过种子用户群体验反馈、吐槽大会、面谈等方式，我们获取到了用户更深层次的声音。
我们发现，用户所说的体验不好主要集中在这样几类：
- 新产品改版后将原有单流程改变为多个流程，太麻烦，需要重新熟悉
- 某些功能的意思不知道是什么
- 某些样式，比如配色不好看，又不能自定义配色
- 某些功能缺失，不能完成某些样式报表的制作
所以大家发现没有：
第一条是由于新新版改版带来的，即产品结构调整带来的用户心理上的反感以及改变用户原有心理适应而带来的负面情绪。
第二点正好是框架层的，交互指引不够让用户不能理解功能的意思。
第三点则是变现层的，配色不好看，但是实际上旧版配色真的才是不好看（哈哈）。第四个是功能的缺失，属于框架层没有满足用户功能的需求，但并不是改版带来的。
所以，用户吐槽主要体现在表现层、框架层以及结构层调整带来的用户学习成本上，知道了问题在哪里，就有了解决问题的入口，事情就比较好办了。
于是，接下来，我们针对用户吐槽进行分析，将问题进行归类，并转化为功能排期落地。经过一段时间的沉淀，用户吐槽声音开始趋于平静，取而代之的是用户的好评。
因此当用户说体验不好的时候，我们要做的并不是马上否认我们的新版产品，而是了解用户真实的诉求，弄清楚你的用户吐槽的点位于哪一个层次，明白你的用户所说的用户体验是什么，并尽快的满足用户，让用户在产品使用过程中获得愉悦的情绪。
02 从用户体验地图说说如何提高用户体验
我一直在思考和反思，在这个例子中有哪些点是做的好的哪些点做的不够好，要提高用户体验我们究竟要怎么去做，从用户体验地图的理论出发如何在产品设计的过程中即将用户体验做到更好呢？
用户体验地图关注5个方面：
- 用户是谁（用户画像）
- 用户的目标是什么
- 用户要达到目标在你的产品中有哪些触点
- 用户在你的产品中的路径是怎样的
- 用户在使用过程中的情绪是怎样的
弄清楚自己的用户是谁，他们使用你产品的目标是什么，并提供给他们清晰的触点，在用户的使用路径中围绕用户目标给予用户指引，最终让用户情绪得到满足和愉悦是获得好的用户体验的路径，才能谈得上给用户带来好的体验。
从我的产品来看，用户是一些有分析需求的分析师或者是业务人员，分析师懂技术，大部分对市面上的BI产品也不陌生，而业务人员则千差万别，但大部分人不懂技术，甚至不懂透视表是什么怎么做就更谈不上数据分析了。
他们的目标是通过BI工具快速制作出报表或者分析出一个结论供决策使用。
在这个过程用户的触点包括，连接数据源—制作数据集—进行分析/报表制作，至少这3个步骤，如何让用户快速的明白完成目标的触点是哪些，指引用户快速完成这些步骤，获取产品使用的主流程，而不是在产品中一直摸索是非常重要的。
接着是产品的使用路径，跟触点不一样的是，用户的使用路径是杂乱的，尤其是新用户，如果没有明确的让用户知道要达成目标的主路径，用户就会在产品里绕来绕去，最终甚至会因为实在找不到实现目标的方法而愤然离去，但同时，如果在用户路径中加入更多指引或者用户感兴趣的因素，用户依然能够获得好的体验。
用户体验地图的最后一点是用户情绪。用户在使用你的产品过程中是因为能够明确的快速实现自己的目标，体验良好而表现出愉悦还是会因为一直绕来绕去不知所云或者不会使用而愤然离去，这是用户在使用产品中的情绪，也是最终用户体验的内在情绪表现。
改版后产品明明路径更清晰更好用，但用户却吐槽体验不好，实际上有两种可能：
一是因为用户抗拒改变，无论是好的改变或者坏的改变，只要是改变用户都会觉得不好，这是因为打破了用户原有的信息系统，用户需要重组信息，这是一个痛苦的过程。
另一种可能则是因为产品设计上存在问题，将原有的流程拆分为多个独立的流程，但却并没有给用户更多的指引，告诉用户要完成一张报表或进行一次分析究竟应该走怎样的路径，有哪些重要的触点是必须完成的。
我认为，这两者是都包含的，而究其根本是触点和路径的引导做得不够好。
在实际产品前期的推广中，有非常多的用户反馈不知道如何操作，包括不知道如何连接数据源，不知道如何开始分析，发布报表的时候不知道为什么不能够选择发布的位置，申请了报表不知道流程节点在哪里看。
这些问题实际上就是没有帮助用户很好的引导目标完成的触点，用户路径上没有给予更多的指引，导致用户在产品使用中一头雾水。
一个To B的工具类且对内的产品可以被谅解，但是从一个产品经理本身的素养出发是不能够苟且的。
那么我们可以如何去做来避免用户在这样的调整中产生负面的情绪呢？
其实对老用户来说最重要的是降低替换成本，而对新用户来说则是引导用户快速完成目标。
在之前的“从用户价值公式出发，聊聊为什么聊天宝会失败”一文中我也曾提到过替换成本，在从一个产品到另一个产品到替换中，替换成本是我们绕不开的话题。他包括品牌认知、获取渠道、学习成本、用户体验等方面。
那么我们如何去尽最大努力减少替换成本，明确产品触点，帮助用户更好的达成目标呢？
首先从品牌认知来说，因为是内部产品的升级实际并不涉及。
获取渠道上，我们可以增加旧版本url自动跳转新版本，或者在旧版本上增加新版本入口的方式（新旧版本并行一段时间来降低用户过渡期的焦虑）。
在学习成本上，如果业务逻辑、功能逻辑不需要调整的，我们尽力不去做太多改动，以保证逻辑和操作的一致性，同时，如果改版太大，我们可以提供新手指引，或提前做好视频操作手册等指引，方便用户查看。
一般前期有做种子用户灰度，这个过程中我们可以去更多的收集用户问题，关注用户在体验新产品中主要提出的问题，思考这些问题是可以从产品设计上解决还是可以从用户指引上解决。
如果是产品设计上的问题，这个不用说，如果是指引上的问题，除了上面提到的完善手册、指引还可以增加FAQ来解答用户常见问题。
而用户体验上，由于迁移或升级带来的陌生和不确定性是在所难免的，给予用户更多的指导，积极响应用户的需求，让用户感觉到被尊重和被重视，是一定不会错的。
同时，响应了用户的需求，记得一定要告诉用户，版本更新日志弹窗是一种方式，而我们的BI产品我还做了另一个策略，即版本更新后将新功能加入到demo报表中，让用户真切的了解到新功能的展现效果是怎样的，第一时间吸引用户的目光。
谨记千万不要偷偷摸摸升级打怪，之前有用户就告诉我，你们迭代速度特别快，用户响应速度很赞，但是，很多时候我们都不知道你们又偷偷上线了什么好功能——
行吧，版本更新日志、demo报表还是不一定有效，下个版本版本更新弹窗就上了（摊手）。
后记
我所经历的几款产品，无论是用户分析平台，用户画像平台还是现在的BI产品，都大大小小经历过大的改版或改头换面式的升级。
每一次都是一次用户心智和原有世界规矩的打破，对于运营、用户乃至产品本身都是一次大的挑战。
因为涉及产品大的结构的改动是对用户确定性的侵犯，确定性是一种安全感，是最终形成对产品依赖的基础，是用户体验中最真实的情绪和心智，所以，这样的改版都是对用户确定性的伤害，不是万不得已就不要轻易改动了。