作者@可风 。
我不是用研，但是和我们公司的用研同学讨论过这个问题，当时他说“这就好比是要质量还是要速度的问题嘛，太难平衡了”。但是后来我们想想那也就是一时的吐槽，其实用研和快速迭代本身是没有矛盾的，只不过是现在的一些用研方法已经不适合流行的快速迭代环境了，用研思路需要更新！
我们团队（或者整个猎豹移动）都是以快速迭代闻名的，重要产品几乎一周一个版本，很多周一发出的迭代计划，周四之前就要测试好上线，周末之前就要看到反馈并且准备到下周的汇报中。这样的速度别说是用研了，连设计师作图都很难跟上。
但是我们发现没有用研不行，没有用研就好比我们在做一个低头不看方向盲头奔跑的人，没有用研我们就没办法了解除了数据直观反馈以外的其他改进是否有效果，所以我们经过长期的摸索就学会了把用研“互联网化”：
1，最重要的就是把用研变成一个常态的事情
团队每一个成员都要接触用户，经常接触。泡论坛和QQ群是家常便饭了，每周都要邀请一位用户做用户访谈。原本为了某个用研计划开展的那种集中几百人的访谈被分到了平时每个人互相帮忙做，至于质量当然无法完全保证，但是一个问题能把握到大概也是可以的。
这种氛围下仍然需要一位懂用研的同学带领大家，主要目的是协调大家一同参与，作为咨询者和领导者发起和把控整件事情，而不需要他万事都亲自去办。因为他的经验和帮助，我们可以把用研结果保持在可用的层面上，至少主要目标能够解决，至于那些精细的用研报告或者更详细的分支问题一般都省去了。另外这样还能训练大家的用户感觉，在一些普遍或者不那么重要的问题上因为长期的训练大家都心中都自有谱子，而不是专业的人更专业，不专业的人只能干等着。
2，更前置的开展用研活动
产品的快速迭代其实更多是指加快产品的开发节奏，不要因为走错路而浪费了耗时最长的开发资源。但是研究的工作一直不会停，而且说实话如果研究能够提前发现结果也比产品开发出来要划算的多。
我们UE团队有的时候会看到很多很长远的问题，比如一些用户痛点在当前并不是最紧急的，但是随着产品逐渐完善我们一定会遇到的问题，我们就会提前开展用研工作。因为对浏览器的经验，我们会把整个产品的发展当做一颗大树，在开发搭建主干的时候我们就已经在探索分支了，等开发分支的时候我们再来探索主干如何升级，始终保持比产品团队还要快一个步调。
然后我们还会维护用户体验地图，就是对产品的某一方面保持长期的观察和评估，虽然不会做那么高大上的展示，但是大家心中都会对某个流程的体验问题是非常有谱的。当这些准备都完成之后，我们就会把重要且有解决方案的问题用快速迭代的方法尽快丢在线上实践，其他相对重要但是还有疑问的问题就要做用研。
这种情况下用研的方法很多，一种就是和传统一样，访谈和问卷照样做，虽然时间长但是我们一时半会也不会着急开发到这一块，只要保证合适的时间能够拿出合适的解决方案就可以了。还有一种就是告诉大家最近要注意这方面的问题，比如收集用户反馈和与用户聊得时候多深入挖掘一下。另外我们的用户反馈在平时就都有收集，所以我们会把以前相关的反馈都拿出来认为分析原文和挖掘场景。
问题池--->方案池(重要问题)--->迭代计划
最后重申一下我不是用研，只是小交互，可能说到的和专业的用研方法还是有区别。但是我想提出的是我们在快速迭代下把用户体验设计变成更简单，更普遍，更前置的思路，希望能帮到大家。
作者可风原创并投稿早读课，转载请注明出处
作者专栏：http://zhuanlan.zhihu.com/kefeng/19818179
作者@可风 。
我不是用研，但是和我们公司的用研同学讨论过这个问题，当时他说“这就好比是要质量还是要速度的问题嘛，太难平衡了”。但是后来我们想想那也就是一时的吐槽，其实用研和快速迭代本身是没有矛盾的，只不过是现在的一些用研方法已经不适合流行的快速迭代环境了，用研思路需要更新！
我们团队（或者整个猎豹移动）都是以快速迭代闻名的，重要产品几乎一周一个版本，很多周一发出的迭代计划，周四之前就要测试好上线，周末之前就要看到反馈并且准备到下周的汇报中。这样的速度别说是用研了，连设计师作图都很难跟上。
但是我们发现没有用研不行，没有用研就好比我们在做一个低头不看方向盲头奔跑的人，没有用研我们就没办法了解除了数据直观反馈以外的其他改进是否有效果，所以我们经过长期的摸索就学会了把用研“互联网化”：
1，最重要的就是把用研变成一个常态的事情
团队每一个成员都要接触用户，经常接触。泡论坛和QQ群是家常便饭了，每周都要邀请一位用户做用户访谈。原本为了某个用研计划开展的那种集中几百人的访谈被分到了平时每个人互相帮忙做，至于质量当然无法完全保证，但是一个问题能把握到大概也是可以的。
这种氛围下仍然需要一位懂用研的同学带领大家，主要目的是协调大家一同参与，作为咨询者和领导者发起和把控整件事情，而不需要他万事都亲自去办。因为他的经验和帮助，我们可以把用研结果保持在可用的层面上，至少主要目标能够解决，至于那些精细的用研报告或者更详细的分支问题一般都省去了。另外这样还能训练大家的用户感觉，在一些普遍或者不那么重要的问题上因为长期的训练大家都心中都自有谱子，而不是专业的人更专业，不专业的人只能干等着。
2，更前置的开展用研活动
产品的快速迭代其实更多是指加快产品的开发节奏，不要因为走错路而浪费了耗时最长的开发资源。但是研究的工作一直不会停，而且说实话如果研究能够提前发现结果也比产品开发出来要划算的多。
我们UE团队有的时候会看到很多很长远的问题，比如一些用户痛点在当前并不是最紧急的，但是随着产品逐渐完善我们一定会遇到的问题，我们就会提前开展用研工作。因为对浏览器的经验，我们会把整个产品的发展当做一颗大树，在开发搭建主干的时候我们就已经在探索分支了，等开发分支的时候我们再来探索主干如何升级，始终保持比产品团队还要快一个步调。
然后我们还会维护用户体验地图，就是对产品的某一方面保持长期的观察和评估，虽然不会做那么高大上的展示，但是大家心中都会对某个流程的体验问题是非常有谱的。当这些准备都完成之后，我们就会把重要且有解决方案的问题用快速迭代的方法尽快丢在线上实践，其他相对重要但是还有疑问的问题就要做用研。
这种情况下用研的方法很多，一种就是和传统一样，访谈和问卷照样做，虽然时间长但是我们一时半会也不会着急开发到这一块，只要保证合适的时间能够拿出合适的解决方案就可以了。还有一种就是告诉大家最近要注意这方面的问题，比如收集用户反馈和与用户聊得时候多深入挖掘一下。另外我们的用户反馈在平时就都有收集，所以我们会把以前相关的反馈都拿出来认为分析原文和挖掘场景。
问题池--->方案池(重要问题)--->迭代计划
最后重申一下我不是用研，只是小交互，可能说到的和专业的用研方法还是有区别。但是我想提出的是我们在快速迭代下把用户体验设计变成更简单，更普遍，更前置的思路，希望能帮到大家。
作者可风原创并投稿早读课，转载请注明出处
作者专栏：http://zhuanlan.zhihu.com/kefeng/19818179