笔者从2019.9年开始从事toB做产品体验优化的工作,现在是2024.5回顾这快四年的经历,总体感觉还是非常充满挑战且有意义的一段经历。 时间回到2019年因组织架构调整,我也在思考我的未来职业规划,因之前从事多年运维工作,还是希望能结合之前的工作经历,当时也和很多同学有探讨了关于toB业务的运维方向未来发展,发现会逐步往深往精发展,但个人兴趣更多希望去解决一些复杂的问题从面入手,正好内部有机会做产品体验优化工作,了解了一下大概工作内容还是与自己的职业规划比较契合,从此开始入行做这里。 说这段经历比较有挑战的点是,譬如运维工作行业内是有很多标杆的如Google,但做产品体验优化小的公司没这职位,大的公司都在做但都基于自己的应用场景,所以没有太多前车之鉴,还有一个比较有意思的是,当时我们组织在扩张时面试很多候选人是比较难在短时间说清我们是做什么的,不像市场招聘运维岗位负责XX产品,候选人很快能够了解具体的工作内容,所以整理了这篇文章是想回顾总结一下,希望能说清我们如何做产品体验优化的过程。
我们从什么是“体验” 说起 ,在不同的行业不同的人对体验的看法都是不一样的,后来笔者在一本书《客户体验至上》中找到这样一段描述 “客户整体体验来自他的五个感官(视、听、触、闻、味),通过大脑加工后,产生 “逻辑”与 “情感” ,最终留在脑海中的印象”,其实体验就是能给那些人留下深刻印象的事儿。
譬如,加拿大某地的路灯,除了通过颜色还通过形状来告知当前道路通行的状态,他照顾了各种人群如色弱的人,考虑的很细节,其实笔者从书上看到这个案例,是给我留下深刻印象的。
回到以笔者所在的云服务行业竞争还是非常的激烈,同质产品做的都非常不错,产品都已经超过给人留下深刻印象的阶段,所以想把这里做好还是非常难的,我们要找到突破口,做深再做广。
很多时候我们喜欢用“痛点”来形容这个突破口,痛点的意思是“它通常指的是尚未被满足的、广泛渴望的需求,有时也直接指需求本身。”
之前在我们维护的用户微信群中,相同的产品控制台,有的用户说界面太臃肿,有的用户说界面很实用,这里用户都站在自己的角度来看同一个问题时就会有这样的冲突,所以在找到用户痛点前,我们还要知道用户是谁,这里有几种分析方式:
这几种方式通常可以辨别,用户买产品的用途是学习、是工作、还是为一些商业活动,再根据用户的画像对产品体验做细节的优化。
一个成熟的产品从用户切入是一个突破点,从产品可以从这三点切入:
商业的本质是交换,而且是基于人们对价值的认识的等价交换,所以我们卖云产品是需要能帮助客户解决他们在商业上所遇到的问题,以下两句来自《李想产品实战16讲》中,笔者非常认可:
本文主要介绍的是如何做客户至上的产品体验,其实与李想产品实战16讲中第一点的观点是一致的。 这里也介绍了近几年我们的思考和一些方法。
因为云服务后端有百款产品,每个产品有相应的技术团队负责,如何让他们整齐划一,这里从管理角度就需要用到度量指标和目标,让大家在相同的时间点内力往一处用。
度量指标 首先,我们要找到一个衡量体验的度量指标,引用彼得德鲁克的一句名言(如果无法度量他就无法管理他,If you can’t measure it, you can’t manage it),业界也很多类似的度量指标,可以供自己业务参考,譬如:
我们在初期主要用的是工单作为度量指标(用户在使用云产品时遇到问题,反馈的Case单),因为工单如果减少站在用户角度就意味着产品使用更加顺滑,工单的减少还会降低一线人员的服务压力,将更多的经历服务于有价值的事情上,还会为公司节约很多工单产生的费用带来的成本,一举多得的事。
目标 有了度量指标后要看如何落实,即目标。这里有两种设置目标的方式:
举个具体的例子,我们按产品取工单反馈量最多的头部产品前17名,譬如叫TOP17工单折半项目,以当前是2024年1月,我们取2023.9-12月4个月工单的均值作为基准值(这里可以排除10月,因为放假的原因通常是全年工单的低点) 在此基础上下降50%,作为我们项目的目标,这样一来每个产品的基准值不一样,但下降指标是相同的也就拉平了各个产品的目标,让大家往一个方向走。
我们希望能从各种维度来提升产品体验,就好比花长的好和精心照顾有关当然和花土壤也有一定的关系。
我们负责的产品涉及的部门也比较多,更多希望能从文化角度来让大家更重视产品体验,所以我们也以游戏的方式,设置了很多产品体验奖项,奖项从发现问题、采纳问题、解决问题、响应耗时长、解决后整理成优秀案例的方式,让做体验从被动变为主动,从推动到自愿参与再到积极分享解决问题后的案例等方式来提升我们的产品体验。
我们的核心度量指标是工单,但工单的视角还是有局限,所以我们需要更多的渠道立体化的视角来发现我们体验的不足,会通过以下两种方式:
被动反馈渠道(提供渠道,等待用户来反馈使用中的体验问题)
主动挖掘问题
讲了很多提升体验的方式与方法,这里再介绍一下如何实践:
借助BI分析 不同渠道来的体验问题,我们还是需要人工分析的。这里我们借助了公司的BI报表,所有的问题进来后会进行归档,举一个具体的例子一个用户反馈:
1 | 我登录不了云服务器,现象是22端口连接失败,之前没问题,也使用了腾讯云提供的工具进行排查是没问题的。 |
---|
类似这种问题就会归档到云服务器产品,我的归档标签为(产品-问题分类-子问题分类) 这样我们就可以根据TOP的问题来依次分析问题是什么,问题引发的根因是什么。
画像分析 系统会根据用户的消耗进行标识用户级别,可以用过用户的级别问的问题能看到,消费越高的都是一些头部公司相对来说技术能力更强,问题偏重于对产品的性能或功能方面需求;而消耗比较低的用户更多是新手、学生等用户偏多,更多是学习目的。
用户核心路径挖掘 一方面我们会看工单中用户反馈的问题,针对用户反馈产品问题中的高频模块,我们还会以用户视角来体验用户使用产品的过程,并重点关注那些使用产品必经路径,容易出问题的模块。
产品协作类问题
问题的定义 产品协作类问题,譬如A产品为用户入口,A产品又集成了B、C、D产品,但用户是不清楚后面的组织架构的,通常会以产品入口为准来反馈问题,这种我们称为产品协作类问题。
问题的解决 解决这类问题,首先要描述问题、汇总用户的问题数据、用户的期望解决方案、同等功能友商的体验,再拉各产品进行讨论,分清解决问题不同产品的边界和预期时间。
腾讯云涉及的产品比较多,所以要分析的工单量还是非常大的。通常经过一段时间的分析会发现增量工单中存量已知问题占比最多,但还是会有少量的增量问题,所以也会通过一些方式做自动化分析,譬如我们会导出前一周的工单(部分工单还在处理中,未结单)状态为己结单,通过对文本进行分词、去停用词、专注一些核心关键或用户描述的实例ID,进行聚类再进行分析,理论某一个问题的关键字,问题不解决的情况下,每日关键字出现的数量是有一个大概范围的,如果同比或环比关键字出现大幅增长或减少肯定是有原因的,我们再做具体的分析,这样会解决我们大量的时间与人力,同时相应的关键字数据也会关联到需求中,当问题解决我们也可以观察解决后关键字的在工单中的走势,来评估问题修复的效果。
用户通过工单渠道反馈问题,常规的工单渠道包括电话、售后客服、群、站内消息(MC)等渠道,我们会将一些已知问题或可能因为用户环境导致的问题通过智能客服和工具来解决。
智能客户 & 工具 可以用比较低的成本,帮助用户解决那些我们已知的问题,效果还是非常不错的。
我们可以从各个渠道发现问题,但问题多了如何跟进解决又变成了新的问题,所以我们也改造了我们的需求管理系统。
以下为需求管理流程(图片有点模糊,因为我本身表达从轮廓上介绍一下着系统,如需要清晰图片可以联系笔者获取)。 我个人比较喜欢这张图,从最开始的基础功能慢慢迭代到目前样子,谈及过程还是非常有意义的。
从使用系统的角色上可以分为三种:
不同的角色在流程上主要的工作,如下:
提需求人 提需求人更多是一线和架构师,他们直接对接客户,这里我们更加鼓励他们提需求,但人多了难免需求质量,譬如偶提需求人会直接截取用户群中的需求,并很简单的方式描述用户要做什么,类似这样的需求是不行的,因为信息通过流程传递过程时,让后端同学很难抓住需求本质要解决的问题,即便能明白大概意思,但实现上一些用户对结果的要求比较个性,需求实现后发现并没有完全解决用户的问题,所以这里我们也设置需求反馈模版、需求标签:
需求经理 负责需求的审核、需求合并、共性问题聚类、需求分类、需求的整个生命周期管理和相关数据运营等。
产研 需求的采纳与否、排期、实现与反馈等。
度量指标 需求流程有两个重点指标:
目标 落地率这里我们还会对需求做分类,并对不同分类的需求落地率区分对待,并定期晾晒这里不同产品的落地率情况。与落地率相比响应sla是一致的譬如7个工作日内要达到90%以上的响应率。
关于需求管理如何聚焦价值,这里有三个重点:
不断优化流程,识别重点问题 根据目标不断地优化流程。最开始我们的流程是不区分客户群、不区分问题类型的,而我们解决的是体验问题,所以也会把用户群进行打标、问题进行打标,并通过各个维度汇总为一些需求积分,根据积分从高到低排序进行与后端定期沟通,并持续关注重点需求的进展同步反馈一线(以下为当时做的一个在线表格demo)
推荐需求 一般产品以年为单位会有一个大概的Roadmap,但很多时候计划赶不上变化快。我们在需求中也会挖掘相对实时的数据,譬如把需求按行业进行分类,如游戏行业、教育、金融等等,以游戏行业为例,我们看到A、B两家公司对产品提的需求,了解需求背后的问题,并将汇总后的数据以报表形势推动给内部架构师,因为我们觉得同是游戏行业中多家公司有类似的需求,在当前的时间点应该是一个重点的需求,售价架构师在对客户时也会把类似的问题,需求价值推荐给用户,增加我们产品的购买力。这种相对于产品roadmap更加实时准确。
梳理需求规范 其实通过过往的数据我们发现一线人员会有不稳定或岗的情况,因为公司的产品太多,所以一线在反馈需求和需求上线同步用户,这里应该都有要响应的规范。如客情用户怎么上升、需求系统的释放用法,需求上下游接口人、需求进度等等。
为什么要做体验前置,因为这里有上百款产品,随着产品功能的迭代,新老产品的交替,一些不好的体验问题总是会重复的出现,所以我们思考这些问题在设计产品时就能提前的规避,大概的思路是挖掘问题-》分析共性 -》整理原则 -》赋能产品经理。
分类是让人容易记忆,分类后还可以提升解决问题的效率,最后更好的分析到修复后的效果。 但分类要根据自己产品的实际情况。我们每天还是会有大量的问题进入到需求流程中,这里我们会将问题分类两个大类和分类原则如下:
交互体验
问题分类 | 解释说明 |
---|---|
引导/提示不到位 | 文案提示、操作引导不到位 |
多端体验不一致 | 控制台、云助手、API等多端之间的体验不一致 |
产品间体验不一致 | 相似的功能(比如控制台的地域组件)不同产品体验不一致 |
不同区域体验不一致 | 比如国际站和国内站体验不一致 |
缺少模糊搜索/筛选能力 | 缺少模糊搜索或筛选功能 |
文案表达不够准确 | 文案表达不准确,误导或缺少文案说明 |
操作流程割裂 | 操作流程之间衔接不顺畅、割裂 |
缺少智能校验 | 缺少提前校验、自动校验 |
其它 | 定期再分类 |
场景体验
问题分类 | 解释说明 |
---|---|
文档问题 | 文档相关的所有问题 |
功能缺失 | 产品功能缺失 |
缺陷 | bug类问题 |
产品间协同问题 | 两个以上产品之间搭配使用的问题(比如各产品与云监控搭配) |
性能问题 | 性能相关问题 |
其它 | 定期再分类 |
感知体验
问题分类 | 解释说明 |
---|---|
未给用户选择权 | 替用户选择或未给用户多种选择 |
产品能力迭代慢于业界 | 与业界竞品或上游供应商之间的迭代相比较慢 |
复杂功能简易化 | 复杂功能需要简易化 |
功能层级过深 | 功能层级或入口较深,用户找不到 |
缺少终止/取消操作 | 流程开始后没法取消或终止 |
未给客户知情权 | 未及时告知客户进展或状态,导致信息不透明 |
其它 | 定期再分类 |
原则其实就是指导个人或集体行为和决策的基本准则。我们会通过日常发现在不同产品重复出现的问题进行分类整理:
案例。
如何做产品体验用一句话总结,我回想一下工作的过程更多是把无序变为有序的一个过程,以产品体验为例,让用户使用产品时更加顺滑、让产品在业界更有影响力,这里我们需要不断挖掘每个问题背后产生的原因,并定期把问题原因进行分类汇总,看会出现哪一类的问题,从产品规划上未来是否可以解决,短期存量问题如何处理,不同产品间问题如何对齐,让用户体验更加一致。
参考资料
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。