新产品的改进不要太寄希望于用户反馈
很多时候,都可以听到产品要“小步快跑”的说法,产品要先上线再迭代,先让用户使用上产品然后才是让用户使用上更好用的产品。这些说法本身没有错,当然基本上关于产品的说法大部分都没有错,错的是在执行上。
产品上线后的迭代,除去计划中尚未设计开发的功能外,还有很重要的一部分是收集线上的意见建议快速的修复及更正,但是线上意见建议的反馈从哪里来呢?
第一反应,理所当然的是反馈信息来自于用户;第二反应是还有自己人的反馈信息(自己人在上线前就已经测试反馈过的前提下)。
收集自己人的反馈信息并不难,相对来说可以说是极其容易的,发现问题立即就可以修正。但是来自于用户的反馈,渠道有很多,网站本身、QQ群、微博、邮件等,当然最为重要的是网站本身要提供反馈入口,入口不能过于显眼,但也不能隐蔽到需要用户整个页面去寻找,那样的话基本也就没有用户来提反馈信息了。
当Wopus问答上线时我们以为除去自己人的反馈外,可以从用户那里得到很多关于产品的改进意见时,毕竟这是一个只能满足基础需求的不完善的产品,但是从上线的这6个月来,有个数据及案例狠狠的浇了一盆冷水下来:
除去一开始网站上“意见反馈”的入口略显隐蔽外,后面修正了这个问题将反馈的入口提到相对显眼处,6个月来除去发广告的总共收到13条由用户产生的反馈内容,其中真正的反馈只有2条,其余全是不沾边的内容;
因为一个很不应该的测试疏忽,导致使用纯数字注册的用户名在验证成功后无法正常使用,而这个巨大的Bug竟然是在发布5个月之后才从QQ群里偶然得知,不是因为没有用户使用纯数字的用户名,数据显示当使用纯数字用户名时不能正常时,用户会选择在数字前面或是后面加一个字母上去,却从来没有用户反馈过这个信息;
很多时候,我们的以为都是错的,我们以为用户会以热情来回馈我们的热情,我们以为用户会很乐意帮助我们成长,我们以为用户对存有问题的产品会批评甚至是咒骂,但最悲哀的是用户对存有问题的产品选择了沉默!
对于用户来说,他们的忍受力比我们想像的要强,存有缺陷的地方他们会选择绕过,寻找一条可以前行的道路,如果实在没有办法,那么他们就会放弃。
对于新产品的改进来说,不要太寄希望于用户反馈,要另外从数据中去发现问题。
扫一扫订阅我的微信号:IT技术博客大学习
- 作者:摄氏度 来源: Prower - 记录成长过程
- 标签: 用户反馈
- 发布时间:2011-11-12 21:34:05
- [67] Oracle MTS模式下 进程地址与会话信
- [65] 如何拿下简短的域名
- [65] Go Reflect 性能
- [59] 图书馆的世界纪录
- [59] 【社会化设计】自我(self)部分――欢迎区
- [59] android 开发入门
- [58] IOS安全–浅谈关于IOS加固的几种方法
- [53] 视觉调整-设计师 vs. 逻辑
- [47] 读书笔记-壹百度:百度十年千倍的29条法则
- [47] 界面设计速成