再谈产品体验生态|半兽人药剂师

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了再谈产品体验生态|半兽人药剂师，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含12694字，纯文字阅读大概需要19分钟。

内容图文

再谈产品体验生态|半兽人药剂师

半兽人药剂师 中生代技术

产品体验，越来越重要

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

体验发展中心的玩法

以上面三点为核心，公司成立了体验发展中心。团队早期有近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产品体验年，我们尝试了多种推动产品体验改进的方式；这些宝贵的经历，让我们能够有机会从术的层面走向道的层面。
    
    我们现阶段开始建设“衡量价值”相关的区域，他在架构完整型上合理吗？它如果建设完工，我们距离整个体验生态的建成还有多远？分析工作作为一个局部最优解的单点存在，是否能和之前所做的改进串成面呢？在复杂环境里解决一个复杂问题，这一切都不得而知。这不是一件容易的事情，能拿指标定义成功的事情都容易，我们这个成功无法定义，它是一件改变全公司产品基因的事情，它是一件需要守住客户第一的事情。
    不忘初心，方得始终；再谈产品体验时，已经逐渐能从“推动产品解决问题”的阶段，开始进入到“通过数据和计算的力量，帮助用户发声”的阶段。未来还会有哪些有趣的东西出现尚不得而知；能够知道的是，在不断完善和架构产品体验生态的路上，会是一场难忘的修炼。

内容总结

以上是互联网集市为您收集整理的再谈产品体验生态|半兽人药剂师全部内容，希望文章能够帮你解决再谈产品体验生态|半兽人药剂师所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

---