跟进用户反馈: 问现象, 不问想法

上周跟进了一个用户反馈，从联系用户到最终搞清楚问题一共花了三天。由于时差的原因，只有在下午才能联系用户，再加上过于信任用户，导致走了很多弯路。给我最大的启发就是在处理用户反馈是，一定要问现象，不问想法。

时刻记住，用户反馈的任何内容，都是他自己的想法，他的想法基于他对我们产品的认知，他做任何操作，都对产品有一个预期，这个预期一般是从我们产品上学习+用户自己推导得到的，当产品表现得和他的预期不符时，他就会认为产品出现了bug。

所以我们在询问用户时，务必要分辨他说的到底是自己的想法，还是自己看到的东西，如果无法明确分辨，要求用户给出屏幕截图。

比如用户反馈“关闭A功能后自动打开”，就存在很多问题。

首先“A功能”定义不明确，他说的A功能和我们内部说的A功能很可能就不是同一件事情。我们是对自己的产品最了解的人，但用户不一定了解，无论他声称自己有多了解，都存在认知错误的可能性。

其次“关闭”这个动作是什么，也不知道。用户说他“关闭”了某个功能，其实是说他执行了一些动作，他把这一系列动作统称为“关闭”，但这一系列动作真的能达到“关闭”的效果吗？我们不得而知。

接下来，这个“自动打开”如何定义？问题的关键在于用户如何认知A功能的“打开”状态。就好比用户关闭了消息推送功能，但是产品设计上，用户依然可以查看收到的消息，只是不提醒而已，那么当用户发现自己关闭消息推送之后，还能查看收到的新消息，就会认为消息推送还开着。

所以我们就应该问清楚，用户如何操作，操作之后看到了什么现象，因此得出结论“关闭A功能后自动打开”。

我上周恰好就遇到了这样的用户，反馈“关闭A功能后自动打开”，我每次问他看到了什么，他回答的都是觉得是什么，要他给截图，他总是觉得我低估他的智商，觉得我的问题太弱智，每次都说不用截图，导致我判断失误，写了一堆调试代码，打了测试包给他安装，结果任何异常都没有发现，因为根本就没有异常，所有的bug都是用户认为的bug。

尽管用户反馈很有可能是误报bug，但我们依旧需要反思为什么会导致用户认知错误，我们的产品一定是解决用户的需求，符合用户的预期，如果与用户的预期不一致，在用户看来就是bug，如果我们的产品就是这么设计的，那么我们就要反思为什么要这么设计，有没有更好的不容易引起误会的方式。