再谈产品体验生态：产品体验越来越重要，我们该如何做体验生态

产品体验，越来越重要

今天是一个体验为王的时代，这话一点都不过分。特别是对于互联网产品来说，消费者的话语权越来越强，如果你的产品做得好，不久就会口口相传；如果你的产品做得烂，不久就会骂声一片。所有这一切在过去是不可想象的。但今天，每个人都可以发布信息，每个人的声音即使弱小，也总能被别人听到。在我所工作的地方，会接触各种类型的体验问题：有产品上的体验问题，有客户服务上的体验问题，有营销活动上的体验问题。这些问题，都在一次次的降低客户心中对我们的评价。我们认为需要有一个平台，以中台形式为上层赋能：我们需要为业务产品输出改进建议，并推动产品做优化，恢复和提升产品在客户心中的评价这件事情可以被抽象得很简单：发现问题，推动问题改进，衡量改进价值。

体验发展中心的玩法以上面三点为核心，公司成立了体验发展中心。团队早期有近30号的体验分析师，分散在公司的各大产品中，和产品、技术团队同吃同住同劳动。以人肉的方式，从用户的投诉原声、微博舆情等渠道收集问题。结合收集到的用户问题，以自己在某个产品中的长时间沉淀为基础，向产品经理(PD)提出改进建议。

而这些改进建议往往都不会被采纳，大致的原因有以下几种：

- 你知道的问题，我早就知道了。

- 由于你在技术、产品、运营上并不专业，所以你的改进方案并不好。

- 你说的是个案，不能代表某一类用户的利益。

- 我们还有更重要的需求要做。

在这个阶段，体验分析师的职能特别像是一个不专业的测试人员，提出的问题大部分都被否定了。采纳率和采纳数量都很低。在这个阶段，团队的首要目标是先具备提出有价值问题的能力。“你说我们不能代表用户，那我们就直接让用户和你聊聊”。带着这种思路，体验发展中心找到我们寻求技术合作。直接建立用户和PD的桥梁体验发展中心和技术团队合作了一个项目叫VOC，客户之声。我们做了一个网页让用户来提意见，并且让对应的PD出来给出答案。

我们想建立这样一个系统，让用户和PD产生链接，把用户的问题和PD的解法撮合起来，并通过一定的技术手段提升信息的撮合效率。

这个系统的建立初衷是有情怀的，但它在上线运行一段时间后，它的特性发生了一些演变：

- 内容量大。质量低：大量的业务咨询、账单查询等问题涌入，PD化身为客服人员，每天需要处理大量的用户服务。并且信息绝大多数对产品的优化和改进是无意义或者意义很小的。PD每天也有自己的很多事情需要处理，用户长时间得不到回应反而降低了服务体验。

- 和服务渠道同质化：虽然初衷是想开一个入口就能流入高品质的改进建议了，但大量的客户服务诉求也涌入了进来。而且这个渠道并没有在客户中心的人力调控下，对公司整体而言在成本和口碑上都有负作用。

经过总结，我们意识到了两个问题：

- 用户的反馈，对产品有效或无效的信息，最终都会进入到人工服务、自助服务等服务渠道中，我们不需要单独开辟一个渠道去分流用户的反馈。所以我们想要了解用户的声音是什么，可以考虑从人工服务、自助服务等服务渠道获取。

- 每天的数据是海量的，单看每一条用户原声都是感性的、能让人感同身受的。但单个信息难以折射出在十几亿的用户群里，影响程度是怎样的。

于是我们开始尝试对用户原声进行NLP处理，尝试以技术的手段聚类出用户在说什么。数据技术，自动聚类问题的尝试每天公司有接近20W的人工服务，几百万的自助服务，几百万的舆情数据，以及其他很多渠道的和支付宝相关的信息我们全部接了进来。从数量上看，属于大数据。按照大数据时代的典型玩法，把每天这么多的数据丢到一个系统里面进行建模、训练，我们就有希望让机器自动识别用户遇到的时什么类型的问题。机器如果有能力对问题进行分类，那么我们就能为产品的问题找出对于的成本数据（服务量、投诉量）。结合数据，我们的内容应该更好，PD和技术团队应该就能接受了。这个阶段，技术团队投入了近15人，一半做系统建设，一半做NLP技术。

而在这个阶段，我们遇到了新的问题：

- NLP技术瓶颈：我们没能很好的把大量用户的观点聚类成较小的问题。无效信息太多，技术上没能帮助体验分析师获得有价值的问题。这里面有很多的瓶颈，错别字的辩证修复、上下文的语境联想、句法依存关系分析、中心思想提取、多语言处理等，都成为了我们当时不可逾越的技术鸿沟。

- 人肉分类替代NLP：客服人员在进行人工服务的时候，会有一个“服务引导”系统对用户的问题进行分类。分类所用的类目树也是人工维护的。

- 服务数据的价值被质疑：通过人肉分类，可以得出产品在服务上的表现。例如“余额宝-转出”问题，每天的服务量会和服务时长一起折算成服务成本，向产品提出改进要求。但这种属于非常高层的战略决策，不同产品在不同的发展阶段，对服务成本有不一样的容忍程度。而且以“服务量”作为指标，一直是在从“服务”向“产品”做数据论证和舆论压力输出，产品方并不买账。

在这个阶段，我们开始尝试数据技术，期望从海量数据中发现“用户想要什么”。现在回想，即使我们当时在NLP上突破了技术瓶颈，我们仍然不会成功。我们在成功定义上出现了偏差，仅仅是站在“代表用户”的制高点上，去要求“产品”降低一些“服务”压力。产品团队看得很透彻，在业绩和服务成本的权衡上，无法不能打动他们。引专家入场，影响有影响力的人上一阶段的高开低走，让很多人开始对“产品体验”谈虎色变。技术团队经过一段时间的调整，只留下了一名技术人员进行系统维护。在这段时间里，体验分析师不再押宝到数据技术上，开始回归到自身业务本质。在能力达不到的情况下，引入了一些资深的数据分析师、不同领域的产品专家、成立了X小组专门面向产品做分析报告。这些专家输出了一些有影响力的案例，他们的文章里有分析数据、有竞品分析、有段子、有感性的用户原声、有靠谱的改进建议。反馈问题的内容，从单纯的文字变成了一篇多媒体的文章，文章具备了一定的文学性，并且带有专家自己独特的看问题视角，能在一定程度上弥补产品团队的不足。专家的引入，让问题的接受程度有了一定的提升，但和我们的预期还有很大的距离（我们自认为专家的分析应该100%被采纳）。经过我们的分析，主要在于这些改进建议的提出，都会对产品的迭代排期产生冲突。从分析师个人的推动力上，很难去影响产品的迭代优先级。在这个阶段，技术团队开始为体验发展中心打造了一个体验社区。专家的分析文章以帖子的形式发送到社区中，社区具备回复、转发、点赞、at谁来看等功能。运营团队每周主推一个产品主题，引入了很多总监、副总裁关注社区，并对分析师的改进方案发表自己的看法。具备影响力的高管发挥着自己的关系链，能够帮助分析师找到解决该问题的关键人物，并提供了从上而下的强大推动力。

在PC端和无线端共同建设的同时，开办了“用户精品原声”、“业界资讯”、“一周热点”、“专家说体验”等栏目，在运营团队的发力下，很大程度的改善了公司内部的体验氛围，大家在通过社区模式重视体验这件事情的同时，也引入了更多专家的专业投稿、更多领导的决策互动。这个阶段属于“众筹模式”的一种玩法，体验设计比较好的撮合了“专家”、“关注产品的粉丝”、“高层”、“PD”。在运营推广的那段时间里，问题推动力空前的高，全集团近一半的人关注产品体验，每天有100多份问题投稿，每周有几十个问题通过平台得到推进，每周有几十位高管关注平台的内容。和第一个阶段相比，我们开始使用一些“分析资源”处理海量的用户信息，将经过高度抽象和提炼后的内容展现给PD、高管等。和第二个阶段相比，在“分析资源”的选型上，我们从“智能万能”的思想里走出来，开始相信“专家的力量”。这一阶段还基于众筹模式，向草根专家敞开了入口；以社区的力量形成内部舆论，从而左右产品需求优先级的设定。以辩证的思维来看待这个阶段，在看似成功的表象上，也深埋了一颗即将爆炸的炸弹。向专家学习，做报告界的专家系统从上个阶段走来，我们基本上认为问题的推动力是足够的了，我们能够推动产品改进了。我们通过体验社区，能够每天众筹备到很多的投稿，体验分析师从投稿里面选择素材进行加工生成问题，再通过运营进行推动。一份好的报告需要经过故事架构、素材准备、文章排版、后期美化等一系列操作。对于专业人士来说，都要消耗近2到3天的时间，且需要多人协同。我们为此做了一个提升效率的专家系统，让时间缩短到2小时：它提供可视化的组件、拖拽式的编排、专家的模板。我们希望该平台能够让体验分析师共享专家的思维模式，我们希望体验分析师和专家能够将精力用在内容生产上，而不是内容美化上。你们负责内容，我们负责美。

这个阶段在表面上看着也是很成功的。但后来我们分析，该产品在技术上有所突破，在对人员赋能提效上有突破，但在“解决用户问题”的初心上，价值是不大的。所以它的成功基本上是在延续着上一阶段运营积攒的人口红利。专家的分析思路可以通过文章架构以word形式共享，不一定需要一个线上系统；专家的文章美化可以线下通过PS模板形式共享。从短期上看，专家系统的建设仅仅做到了“技术炫耀”；从长期看，很多信息线上化之后，才会有深度分析、多份报告观点提取、改进策略自动跟踪等应用场景出现。

全民服务两小时

效率提升后，在“发现问题”阶段产出了更多的改进建议，而在“推动力”的不断输出下，前期埋下的坑逐渐爆发了。在“众筹模式”撮合下的各方，在运营的推动和造势下，部分的PD会认为即使该问题有领导认同，但自己并不认同。这类PD的思维模式是较难改变的，他们对外部建议的接受门槛很高。当重运营的模式停滞一段时间后，热点消失了。我们所期望的“PD”、“专家”、“高管”在社区内的自运营模式并没有出现。这让我们开始思考如何能够有效的改善PD的接受度。

一味的增加推动力并不是一个很好的方法，这时我们尝试降低PD的接受门槛。我们做了一个系统，能够让用户在线报名参加“全民小二”的活动。参加该活动，能够让用户直接具备“客服小二”的权限，能够在工作台里面接收到“用户的求助”。

花呗团队每月迭代发布后，均会自发组织一场全民小二活动，了解用户情况并进行圆桌讨论。从群众中来，到群众中去，给其他重点产品起到了一定的榜样作用。

运营人员组织了“产品团队服务”、“双11千人服务”、“全民服务两小时”等活动，让产品的PD、技术人员等逐步走到服务一线，开始感知自身产品的问题，吃自己的狗粮。和前面几个阶段类似，辩证看到一定成功的背后，仍然会有严重的问题存在。由于我们善于对复杂问题进行分解，我们给出的解法都是局部最优解、而不是全局最优解。在推动力这件事情上，通过社区模式增加推动力、通过全民小二降低接受门槛，这是一个很好的点，甚至是一个很好的线、面。但当升维到“客户价值”时，却发现我们仍然在代表自己，用一切努力和技术手段，售卖自己的story。

普惠金融，回归初心

回顾了一下之前所做的事情，发现我们在这个链路上的“发现问题”和“推动改进”上做了一些事情，也取得了一些成果。在发现问题阶段，为问题发现的深度、广度、效率提供了一定的技术赋能；在推动改进阶段，以社区与内部舆论方式提供了推动力、以服务主动体验的方式让产品团队感同身受。在衡量价值上，我们貌似没有做任何东西。而在最近一期的季度总结上，我们尝试阐述了一下我们的价值：“我们需要为业务产品输出改进建议，并推动产品做优化，恢复和提升产品在客户心中的评价”。而我们的答复却是：“帮助7大重点产品，推动了1000+问题，并落地解决了500+”从价值阐述上，我们还是站在自己做了什么上去的。解决了1000个问题和10000个问题，和用户的关系在哪儿呢？解决了成都跳广场舞大妈的问题了吗？解决了聋哑人使用花呗的问题了吗？在这之后的很长一段时间里，我曾多次想放弃在“产品体验”这条路上的修炼和探索。它在业界没有成功案例可以借鉴，它需要我们一次次的摸着石头过河。顺着事物发展最正常的逻辑，它自然而然的引导我们进行了一次次的试错，我们打了很多的点，但在“点线面局势上， 何时能够完成量变到质变，我和我的团队不得而知。“客户第一”，公司内的价值观在这个时候仿佛在指引着我们。我们需要想办法阐述我们让PD、高管买单的每一次迭代对客户的意义是什么？一年推动了几千个问题改进，一年做了几十次功能迭代，这些都是没有意义的。而“业务量”、“服务量”、“满意度”这些我们现在所创造的指标，仅仅能描述“我们有多强”，并都不能描述“我们对用户的意义”。这是一个很艰难的起步，我们开始对用户做数据分析了，为每一个事件（异常、线上故障、运营活动等）找到影响的用户，并对每个事件所圈出来的用户做特征分析。我们坚信，分析过程之一种“多维归因”的过程。而我们以用户为元数据，迭代式组合筛选维度的过程，能够让我们把一个High Level的指标解构。未来我们希望，我们的描述不再是这样：“花呗每天8000通热线服务，产品你改了这个问题，我们就变成每天7000通了”，我们希望他是这样：“花呗每天8000通热线服务，产品你改了这个问题，20到30岁的50%的女性用户，在对花呗的信任度上将提升一倍”，也可能是这样：“这项功能让20万下岗职工再就业”、“这项功能让10万癌症患者重获希望”。有机会做上述的分析、用户价值的定位，归功于公司数据团队在会员特征、用户画像建设上的努力。让我们的体验分析师能够直接使用和会员相关的近百个维度、产品相关的几百个维度，做多维的组合分析，具备了通过多维组合精准探索“为某一类用户提供了价值”的能力。价值的挖掘，是一个连续型的分析过程。而现状是，分析师输出分析思路，需要BI帮助清洗数据、输出结果，平均每次完成一次交付的时间是一周。分析师一周之后拿到结果，基本上已经忘记了之前的思路了，分析思路不连贯，导致分析无法继续进行。有人说，增加BI资源能够帮助解决该问题吗？经过我们的实验，一项会员信息的多表分析，在ODPS上的运行时间大约是9~12分钟。而分析师需要进行迭代式的“多维归因”分析，每增加一项维度进行重新运算的可容忍时长大约在20~30秒。业务上为此也对我们提出了技术上的需求。

我们做了一个分析工具，在ODPS上对数据进行预处理，将待分析领域的多张表聚合成一张宽表，并对宽表中的每一列维护模型含义，预处理时长大约10~20分钟，可在多个用户之间复用。预处理以业务领域事件为驱动（缺陷影响人群、服务人群、某产品人群、NPS调研人群等），对20亿的全量用户进行降维。降维之后，我们也需要对分析师提供百亿级数据、4096列维度的ad-hoc组合查询，并让相应时延保持在5秒内。在数据分析加速引擎层面，我们PK了kylin、hbase、ADS、搜索引擎等方案后，最终选型了公司内部的HiStore列式存储方案作为我们这个OLAP系统的加速引擎（由InfoBright蜕变而来，现已商用）。分析师负责寻找用户价值，我们负责准备数据。基于分析工具，我们能够开始引导分析师的价值衡量是围绕用户的，我们开始有机会衡量产品团队每个迭代对用户带来的价值是什么。

写在最后

2015~2016产品体验年，我们尝试了多种推动产品体验改进的方式；这些宝贵的经历，让我们能够有机会从术的层面走向道的层面。

我们现阶段开始建设“衡量价值”相关的区域，他在架构完整型上合理吗？它如果建设完工，我们距离整个体验生态的建成还有多远？分析工作作为一个局部最优解的单点存在，是否能和之前所做的改进串成面呢？在复杂环境里解决一个复杂问题，这一切都不得而知。这不是一件容易的事情，能拿指标定义成功的事情都容易，我们这个成功无法定义，它是一件改变全公司产品基因的事情，它是一件需要守住客户第一的事情。

不忘初心，方得始终；再谈产品体验时，已经逐渐能从“推动产品解决问题”的阶段，开始进入到“通过数据和计算的力量，帮助用户发声”的阶段。未来还会有哪些有趣的东西出现尚不得而知；能够知道的是，在不断完善和架构产品体验生态的路上，会是一场难忘的修炼。

作者：半兽人药剂师