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

产品体验,越来越重要

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

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

体验发展中心的玩法以上面三点为核心,公司成立了体验发展中心。团队早期有近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产品体验年,我们尝试了多种推动产品体验改进的方式;这些宝贵的经历,让我们能够有机会从术的层面走向道的层面。

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

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

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

作者:半兽人药剂师

相关推荐