今天（上周日），送小孩去“英孚”上课，地点在花园城三楼。一切如常，要上电梯。从电梯出来，突然发现，在走道中间，有个妈妈在帮小孩擦拭嘴巴的血，当然路过的时候也认真的偷听了一下， 说是滑倒了，磕到了嘴巴。我再往前走，看到了小心地滑的标志，而且不仅仅是一个。不禁让我开始思考四个字"用户体验"，趁着小朋友上课，写下了此文记录之。
早上9:00，是第一场英孚课程开始的时间，3楼的过道几乎是小朋友的必经之路，而上课的小朋友3岁～6岁不等，正正是不听话的年纪。恰好，这个时候也是阿姨拖地的时间，很容易滑倒。这其实是一个对于当事人来说是再正常不过的用户场景了。与其怪小孩不小心，为什么不通过3楼过道的被拖地的时间再提前或者退后来改善用户体验呢？
想不到
对，想不到。想到拖地的时候，挂上牌子说小心地滑，更加多是免责的法律常识，而要想到一个用户场景下用户可能的遭遇，如"小孩因上课与拖地时间重合，提升了孩子受伤几率"，然后改善用户体验，想想，也就只能有两条路：1、是亲身的体验。2、让别人亲身体验然后用户反馈。
亲身体验
首先是亲身体验，首先想起的是比BAT加起来赚钱还多的迪士尼。他们要假设一个个用户故事，然后在建设后的迪士尼中亲身演练，然后改善用户体验。
而在互联网，也有类似的做法，叫show case。说明一下，show case不是功能展示，case应该是用户故事，用户故事应该是一个体验闭环，而产品经理和开发一起做用户故事与app结合展示，听的人根据用户故事来亲身体验，提问题，思考，更正。有人可能会有疑惑，真的有用么，比直接提问高效？有！不要以为自己真的很聪明，不体验真的发现不了问题。那次体验我们做的newmonkey（随机测试工具）的黑名单闭环体验时发现，居然没有提供返回按钮屏蔽的入口，我去，没有这个，黑名单想实现停留在某个界面运行的场景，就完全就是废了。另外，根据经验，作为show case的参与者，请把自己的智商调整到最低，这时，任何的杂音都会影响你的判断，任何的错误路径都可能是你的选择。
用户反馈
负责这个产品的同学们，自己就是用户，那就是上面说的亲身体验。当然，这也会存在反馈，这叫内部反馈，像我们内置到应用里面的摇一摇提bug, 遇到用户体验的不爽的可以方便地带上日志，图片，描述，一点就提交到我们的bug系统。如果是别人呢？
那就是我们的外部用户反馈，现在有一些系统可以收集不同市场，微博等等的用户反馈到一个平台，再用分词技术，对这些用户反馈进行归纳整理。例如关于性能的用户反馈，通过滑动卡，内存，耗电，启动慢这些关键词，就可以归纳起来，甚至根据反馈数量，做移动平均，自动发现峰值，进行告警等等。这些都是技术，这里确实不想多说了。因为工作这么多年，体会到有比实现这些更难的事情。什么呢？"CARE", 时刻关心，关注用户反馈。这很难吗？所谓系统再多，敌不过人心。我个人的真实体验是，当保持活跃，保持收入成为岌岌可危的问题的时候，疯狂做需求会比默默去关注用户反馈找用户痛点再做需求，更容易填充内心的恐惧。不论是体验的细节，还是用户真实的痛点，都不是拍拍脑袋出来的，能拍出来的大部分是痒点，真正的痛点都应该是从用户场景，用户故事中来的。我始终相信，这才是真正长远地成功的关键，并且不断告诫自己。正如，当年的qq邮箱，为了与网易大战，做了一堆无用的需求后，反省，反省，通过用户反馈挖掘用户真正的需求，发现用户的使用场景，需要的并非超大邮箱而是超大附件的时候， 这就意味着她们找到了真正的成功的钥匙，事实也证明，他们找到了。
另外一种用户反馈，我个人称为被动反馈。如果说给你反馈的，无论是骂，还是赞，那真心是爱呀。可惜，这部分的人并不多，更多的要靠我们的数据上报，也就是被动反馈。这种反馈性能会用，apm就是一个典型；另外，也是ab test作为用户体验调研的数据来源。例如facebook， 她们会利用ab test来判断， exoplayer是否真的比系统的media player性能要好。而手Q则会利用被动反馈中的传图失败和慢，作为案例来研究，改进方案。
说这么多，我始终认为用户反馈，太重要，太重要了。那是比刚刚说的被动反馈更真实的声音，因为数据上报是数字和日志，这些客观，但有时会隐藏问题。所以请我与大家都务必记住:
给用户一个方便找到的反馈的入口，
给用户方便反馈的方式，
给用户的反馈一个赞或者温暖的回复
