产品连载第二辑 | 你们避而不谈的用户反馈和用户行为路径分析，我
文 / 卿宗伟
▼
“
这是产品连载第二辑。内容包括两个小部分。
第一是产品需求与产品测试，第二是用户反馈与用户行为路径分析。
那么，让我们一起聊聊今天的主题吧。
产品需求与产品测试
产品同学都知道，提需求砍需求是产品经理的日常工作。那么需求哪里来？
第一是老板需求；第二是用户反馈与调查访谈；第三是用户行为路径分析；第四是产品经理与助理沟（意）通（淫），然后经理拍板。第五是...其他。
关于老板需求，我常常想，要是老板懂产品的就还好，要是不懂产品的，呵呵那就操蛋了。今天说这个功能好，给我上这个；明天说那个功能好，给我上那个。那你就等着被蹂躏吧躏吧吧...
至于产品经理自己在心里yy需求，其实这是很多产品经理在从事产品工作中会做的事情，而且常常是大多数产品经理的大多数需求的来源（我也会干这样的事儿啊，说出来不丢脸的）。对于这点，我想一句话就能表达我的想法，需求可以来源于产品经理，但并不是唯一来源，也不是主要来源，应当仅仅作为附属。
更多的需求应当来源于用户反馈、调查问卷、用户访谈、用户行为路径分析...等等（当然很多方法并不是每家公司都能做到，一个是资源问题，一个则是成本考量，你懂得n(*≧▽≦*)n）
需求当中我感触最深的就是，一定要有需求评审。作者所在公司是没有需求评审的，这是非常蛋疼的。那我们平时是怎么提需求推进产品迭代的呢？
做产品要多体验产品，所以我有时候会参考其他产品（包括竞品）的优点，提出一个需求，首先跟UI简单沟通探讨这个功能怎么样，探讨如何实现，效果会是怎样，双方觉得可行我就将这个需求提交给A，征求他的意见。
需求确认主要关注三点：
第一，这个功能还可以，可以参考一下，说明该功能对于产品/用户的某一方面是有价值的，比如可以提高留存or促进用户创造内容；
第二，你看看要不要做，技术上能不能实现；
第三，如果要做，难度大不大，开发周期预计多久。这样心里有一个预期。
如果需求被pass掉了，那基本就over了，不过可能过段时间我又会重新提起。那如果通过了，我就直接跟UI说，上！因为之前已经跟UI探讨过了，他基本知道我要什么样的效果，当然后面会持续跟进。
我觉得这种做法还是勉强可以接受的。可怕的是上面或A直接下发需求，说给我做这个！这是xx要求的。这他妈就蛋疼了。又会出现问题：
第一，这个功能是基于什么提出的，用户是否需要这个功能，是不是刚需，频度如何，做了对产品有什么价值吗 or 对用户有价值吗；
第二，你都不跟我们商量一下，直接就说上，怎么上，你想要的效果是什么我不知道，如何实现我也不知道，我连原型图都没法输出。U CAN U UP啊！
第三，这个功能放在哪里，总得有个入口吧，你不说我就按自己的想法执行咯，到时候不行又要返工，我返工也就算了，如果UI也要改改改那就真操蛋了。
我在团队内部提过多次，要改善工作流程，且不说像大厂那样制定规范有条理的流程，那最基本最重要的环节总不能省吧，敏捷开发也不是这么个敏捷法啊。可是没办法，我又不是经理，人微言轻，建议听不进去阿西吧～
所以，人哪，有时候你还就得忍。毕竟你一个人改变不了什么，工作有时候也像强奸，既然无法反抗，那就只能享受了。没关系，卧薪尝胆，三千越甲还可吞吴呢。
下面我想简单聊聊产品测试。首先作者所在公司是没有测试人员的，测试工作主要由我负责。不过这个测试没有涉及技术层面，只是简单的关于产品核心功能能不能用，比如能不能顺利登录，提问有没有问题，充值流程是否顺畅这些可见的非技术性问题。虽然不涉及技术问题，但是有一个东西也是必不可少的--测试用例。
一定要写测试用例。
一定要写测试用例。
一定要写测试用例。
测试用例文档的基本元素大致包括但不限于以下几点：即测试时间，测试人，机型，测试环境，问题页面，问题详情，处理情况，复测时间，备注...等
测试用例文档用excel写就ok了，但是光写测试用例还是不够的。还要做好「回归测试」，跟踪后续问题处理进展，bug是否修复，修复人，修复时间，复测时间...等，方便追溯干系人。另外，如果产品分Android和IOS版本，在制作UC时，建议分开记录，避免问题混在一起，不好处理。
下面提供一个简单的模板供大家参考，这是作者自己输出的简易测试用例（UC）
用户反馈与用户行为路径分析
尊敬的周鸿祎先生说过，「用户至上，体验为王」。这句话我是奉为圭皋的，也持之以恒以此指导我的产品工作。
之前由客服同学负责官方qq，前阵子转由我负责。其实这种职责转移我一开始是拒绝的，因为这样会加重我的工作。但是我后来转念一想，现在官方qq由客服负责，每次用户反馈问题都要先反馈到我这里，然后再由我反馈给开发同学，这样子时间成本和沟通成本很高，而且我不能跟一线用户混在一起，无法及时听取用户的意见。你现在转移给我负责，官方qq是听取用户声音的一道重要窗口。一方面用户反馈问题，我直接跟开发沟通解决，减少中间环节，提高效率；另一方面我可以通过qq群，了解用户真实想法，不管夸奖还是责备。
平时工作中我会很在乎用户反馈这块。第一、用户愿意反馈，说明他还在用我们的产品，说明他对产品还有兴趣，还报有希望；第二、用户反馈的问题，我从来都是第一时间反馈给开发同学（需要技术协助处理时）处理，用户是没有耐心的，不要让用户等太久；第三、用户反馈的某一个问题，也许就是你工作的下一个突破口。
关于用户反馈，首先它应当固化为产品功能，就我体验过的产品以及凭着我的一个推测，我相信绝大部分的产品上都会有“用户反馈”这个入口，虽然这个入口常常变成了一个鸡肋功能。但是即使如此，我认为还是不可缺少的。
因为我们不能一开始就假定没什么用户会来反馈的，万一有呢，哪怕有一个用户反馈也是好事儿。所以它必须存在。既然有用户反馈，那就必然需要用户输入一定内容和信息，包括反馈内容详情和用户联系方式。
这里除了文案暗提示有一定讲究之外，我认为有一点是很重要的，涉及到问题处理后如何联系到用户以及今后针对用户的持续运营与流失挽回，那就是用户的联系方式。关于这个，愚以为，让用户留下qq号码或者邮箱是相对合理的，且不要让用户填写手机号码和微信。理由如下：
1、qq和邮箱相对于手机号码和微信而言，获取成本要低很多，因为qq和邮箱要开放一些，而手机号码和微信相对私密多了；
2、不选择手机号码和微信还有一个原因，就是往后你联系用户成本太高，总不至于每次处理一个反馈问题还要打电话或发短信告诉用户吧，至于微信，我也至今没有看到哪款产品是在用户反馈环节让用户留下微信的；
3、选择qq和邮箱，一是基于成本考量，二是基于便利性。qq用户体量巨大，几乎每个网民人手一个。但是考虑到部分年龄较大和较小的用户，用邮箱的机会并不会很多，因为提供qq or 邮箱两种方式供用户选择是比较明智的做法；
4、后台的对接，用户从客户端反馈问题过来，你后台要能实时收到用户的反馈。显示用户账号和昵称，反馈时间，反馈内容和联系方式等，在这里你就可以添加用户的qq。或者也可以在这里提供一个入口，方便自己将问题处理情况通知到用户。还有一个需要注意的地方，如果你的产品有“举报”功能，我建议将用户反馈和用户举报分离开，因为用户反馈可能只涉及到用户单方使用软件方面的疑问；而用户举报则可能涉及到举报人、被举报人、被举报内容等多方关系，则在后台设计时最好分开，不然很容易搞混淆。作者所在公司的后台关于用户反馈就是这样的，用户反馈和用户举报是混在一起的，用户ID一会儿是反馈人的，一会儿又是被举报人的，经常分不清谁是谁，我他妈也是醉了。
总的原则，你在设计这个功能点时，你要让用户愿意写下他的反馈问题和联系方式，方便今后能有效联系到他，并考虑到持续地精准运营层面；又要方便自己在后台高效处理问题。
另外，针对用户反馈这块，我也总结了几个小点供大家参考：
S1、非功能性小问题马上立刻解决，不要让用户等待；
S2、功能性问题，暂时不可解决的，要向用户做好说明与解释，并表示抱歉，委婉承诺我们会尽快解决；
S3、跟软件本身无关的问题，比如网络不好登录不上app，要告诉用户我们这边排查了，问题确实与软件无关，提醒用户刷新网络多试几次，因为你不说明清楚用户是不会认为网络有问题的，用户坚信自己没错；
S4、有条件的话，还要做好回访，跟踪用户软件使用情况，看bug有否复现。
S5、若你在用户反馈的入口做了相关承诺，比如用户反馈意见被采纳或者举报属实则能获得小礼品，类似这样的说明，如果你真能做到那完全ok，如果你不能做到或根据没想过要兑现，那建议你最好别这么写，或者如果你的产品有虚拟货币，你可以承诺赠送一定数额虚拟货币。重要的是，千万别欺骗用户。
恩，上面说了这么多用户反馈相关的，那用户反馈必然跟业务需求相关。我们知道，很多需求是来自于用户的，那么是用户提什么需求就上什么需求吗？当然不是，对于用户需求，这里不多说，就一句话表达我的思想：听用户的，但不要照着做，我们可千万不能被用户牵着鼻子走。
还有一个是用户行为路径分析。要做用户行为路径分析，首先就要做好数据埋点。第三方数据分析跟踪平台有百度指数、Talking Data、腾讯智酷、友盟、GA等等...我司用的是友盟，但是我个人是认为不好用的，也有可能是之前数据埋点没做好，数据并不全面，进行数据分析比较困难。之前接触过一点GA，觉得GA才最强大。但是不管用哪个平台，数据埋点是关键。各个页面之间的停留时间、跳出率、离开次数、流失率和转化率等都是做好用户行为路径分析的关键。
注意一点，那种只有几大主界面的跳转数据是没用的。举个栗子，用户从A界面跳转至B界面，跳出率是30%，那你能告诉我哪里需要优化吗？这么模糊的数据是不可能进行准确的用户行为数据分析的。一个界面那么多按钮，光一个页面跳出率，我们不可能知道用户是在哪个环节离开的，进行细节优化时会很抓不到点。
正确的姿势应当是，做好每个关键节点的数据埋点。我再举个栗子，以电商中的购物环节为例，一个完整顺畅的用户购物环节大致是：登录--浏览商品--点击查看商品详情--选中商品并放入购物车--结算--支付，在这每一个环节中又有很多小的关键节点，比如用户在”结算“环节跳出来了，你不可以就告诉我说结算页面跳出率30%，这样我只知道结算页面有问题，但是具体哪个点有问题我是不知道的。你要告诉我是用户是在选择支付方式时跳出的还是选择or修改收货地址时跳出的，还是选择配送方式时跳出的。这样我才能准确地知道哪里出了问题，然后对这个点进行改进优化。
以上。
也许我说的，都是错的。
本文完。
Copyright © 2016 卿宗伟. All rights reserved.
走過的路，聽過的故事
讀過的書，寫過的文字
都只是為了將來有一天可以講給你聽啊
爱分享的人长得都挺美
▼
关于作者
卿宗伟（点击链接查看原文，可关注微信公众号）
一只野蛮生长的产品狗。
持续研究产品设计、用户体验和用户心理分析。
民谣重度爱好者。喜欢一切民谣，喜欢民谣一切。
