xueminglang@google.com
本来做了一些笔记，但郎老师后来发了相关教材。内容比现场PPT详细的多。由于，本人在网上也没有搜索到相关文章，还是决定做一回码字工，稍作精简后分享给大家。
后面有案例，希望大家看完后能有所启迪。
注：没有检查错别字，如果发现，请在评论中指出。
摘要
用户研究在实际研发过程中，被认同度和影响力往往不如预期。本文尝试探讨如何通过做“有用”的用户研究来更好得体现用户研究在产品研发中的价值。
关键词
用户研究、有用、建议、用户体验
引言
笔者的困惑：用户体验团队的价值在哪里？对公司的真正贡献有多大？被产品团队的其他成员（如、项目经理，工程师）认可吗？
用户研究团队通常由研究员和设计师2种角色组成。研究员负责了解用户需求，而设计师负责创造符合用户需求的设计。与设计师想比，研究员在这方面的工作得不到认可，成果没有影响力，并且自身体会不到成就感。
与设计师相比，设计师的成果比较“硬”，是可见可触的设计方案和图稿。产品经理和工程师常常追着设计师要方案才能进入下一步开发。而研究员的成果，相对较“软”，是用户研究，洞察和建议。虽然这些成果对产品设计和商业策略往往具有重大作用，但并不是每个研发团队都能对此认可。即使在用户研究缺失的情况下，团队也可以做出决策，即使是一个很糟糕错误的决策。
如何解决这个困惑？诚然，从大环境来说，用户研究需要在各个行业进一步普及，以便让研发团队能更正确地理解其角色，也更容易地认可其价值。但更重要的是，作为一个个体，如何通过调整自己的工作方式，做出“有用”的用户研究，让你的工作成果更好地被接受和产生影响力。
注：此处的“有用”特指用户研究的成果能够被产品团队认可，并且直接影响产品设计和商业决策。
用户研究必须为产品团队服务
一个好的研究必须有明确地目的，而这个目的必须与产品团队的需求一致。在制定研究计划时，你必须了解当前产品团队需要哪些方面的用户数据来做决策。有了正确的研究目的，才能选择合适的方法，才能获取团队需要的用户数据，才能让研究对团队有价值。
比如，有些研究计划会写“本次研究的目的是了解用户对A产品的反馈”。这样的目的太广泛，太缺乏针对性。研究必须根据产品团队的实际情况来制定有针对性的目的。
- 如果团队的目标是在年底把A产品做成市场上同类产品中的最好，并且特别感兴趣A产品与其他竞争对手产品在用户满意度的比较，那么也许大样本的满意度调查比较恰当，能够帮助团队知道A产品目前在市场上得地位，以确定其后续的研发资源投入。
- 如果团队在考虑对A产品的交互体验进行重新设计，也许可用性测试是比较恰当的，可以帮助团队确认当前设计中存在的可用性问题，有针对性地加以改进。
- 如果团队在A产品上刚发布了某些新功能，想了解其用户反馈，那么也许日志研究比较恰当，以便帮助团队了解用户的日常使用情况。
任何脱离了团队需求的用户研究，将只是研究员的自娱自乐，其价值和影响力是最小化的。
不求完美，但求有用
研究员通常具有一定的学术背景（如，心理学，社会学），接受过良好的学术研究教育，并且可能习惯性地把这种学术研究的方式带到产品研发中。在时间和资源无限的情况下，一个完美的研究等于有用的研究。但是，产品研发的过程非常迅速，资源也通常有限，在很多时候你必须在完美的研究和做有用的研究之间权衡。
例如：某个产品设计必须在一个月内定稿，你被要求在这个月中提供用户反馈来帮助设计。你有2个选择，选择一是做相对完美的可用性研究，征募完全符合要求的目标用户，做10个用户测试，完成后才开始好好分析数据，最后做个漂亮的团队给团队。选择二是尽快找一些基本符合要求的用户（甚至是公司同事）来测试设计，一有比较明确地问题被发现时就立刻与设计团队即时分享。
选择一的结果是，你做了一个漂亮的研究，但很有可能当完成研究时，设计早已过了改动的窗口期。很遗憾，你的研究对团队的价值和影响基本为0。选择二的结果是，你的研究看似七零八落，甚至没有像样的报告，但是你的研究已经实实在在地影响了最终设计。你选择完美，还是有用？
从“脏活累活”做起
用户研究通过对对用户需求的深刻了解，可以对产品设计和商业决策带来巨大的帮助。研究员也非常渴望通过自己的工作能够在产品策略甚至公司决策层面造成影响。抱歉的是，现实中很多公司还是倾向于把用户研究等同于可用性测试，而用户研究专员等同于用户体验的质检员，说到底，就是个做测试挑刺的人。这种自我认知和他人认知之间的差距使有些研究员感到受挫。一方面，不满意周而复始地做看似重复的可用性测试。另一方面，渴望做更有决策性的用户研究，但是无人响应和认可。
笔者认为，研究员应该积极的看待目前的现状。可用性测试虽然看起来被认为是“脏活累活”，不如做决策层面的研究来的光鲜亮丽，但目前来说它更能够实实在在地产生影响产品设计的成果，也更容易得到团队成员的认可。没有人能够一口气吃成个胖子。通过可用性测试这块基石，你的工作成果和能力能够逐渐被团队接受，团队对你的信任度也会逐渐提高，慢慢地团队会支持你尝试不同类型的用户研究，在更高层面上做出影响。
传递有效的研究结果
每次用户研究都会获得大量的用户数据。有些研究员看着自己的辛苦所得，恨不得把每句用户说的话都分享给团队成员。可惜的是，团队成员通常没有时间也没有耐心来听这些细节，他们只关心和自己工作直接相关的部分。如“我的设计有什么问题？怎么改？” 我之前的一个经理也曾说过，用户研究数据有80%是“无用”的，只剩下的20%是别人会关心的。
好的研究员懂得最大程度地剥离出团队最关心的用户数据，明确指出主要问题和相应地解决方案建议。少就是多，简洁而有力的数据更有力。
做“我们”的用户研究
俗话说“母不嫌儿丑”，同理，想比“我”的研究，“我们”的研究是不是更容易得到团队的认可呢？让团队成员感觉他们是研究的一份子很重要。那么，怎么做“我们”的用户研究呢？
第一，让团队尽量多地参与研究的整个过程，从最初的计划，中期的执行，到后期的分析和报告。比如前文提到的根据团队需求制定研究目的，也包含这个道理。
第二，真诚的倾听团队的建议来调整你的研究。不要认为自己是专业的研究员，而其他团队成员（如工程师）对研究一窍不通，就把收集建议当成走过场。根据笔者的经验，在于团队的交流中，往往也会对自己给过建议的研究更加关注。
第三，在最终研究报告中给其他主要参与成员署名，或至少留一页特别感谢团队。不要吝啬，这样做会让团队更认可你的工作。
不做门外汉
一个成功的产品需要兼顾用户、商业和技术三者。如果一味强求用户需求，而忽视商业和技术的可行性，是不理智的。研究员作为用户的代言人，提出基于用户需求的设计建议无可厚非，但是如果这些建议完全脱离实际，那么对团队的用户就不大了。同时，研究员作为团队的一份子，不应该只对用户研究精通，也应该对产品的商业和技术方面有基本了解，这样才能和团队有共同语言，才能提出更合理的建议，更容易被团队所接受。
拿笔者自己以前的经历为例，当时我对所研发的产品的背景和技术都不大了解，在完成了一些用户访谈后自我感觉良好，觉得其他团队成员都对用户需求一窍不通，只有我最了解用户，然后就自以为是的提出很多产品建议。殊不知，这些建议不论在商业价值和技术可实现性上都有很大问题，完全不被团队认可，现在想想都挺好笑的。
赢得高层支持
不管是层级相对分明的国内公司，还是更扁平化的国外公司。“上面有人”都是很有用的。如果你的研究能够被公司高层看到甚至认可，将极大地帮助你的工作。这种自上而下的支持能够让你事半功倍，获得更多资源，也更容易得到其他团队的重视。笔者之前的一位经理依靠自身卓越的沟通力和影响力“搞定”了当时事业部的高层，从此做起研究起来就更加如鱼得水。
如何赢得高层的支持呢？基本说来这是一个可遇不可求的事情。不过其中也有几个基本要素。首先是高层自身对研究的态度。比如，如果高层本身就是做研究出身的，那这事就好办了。其次是你如何向高层“推销”自己的研究。高层通常更注重商业结果而不是过程，响应的你应该多强调研究所带来的商业价值而非研究本身。
比如某网站地注册系统要重新设计，你的研究发现了多少交互问题，重新设计后注册过程快了多少，注册成功率增加了多少，相当于每月增加多少用户量，增加多少公司收入？这样的数据更有说服力，也更容易让高层相信研究的威力。
最后，要请高层也参与部分研究，比如出席一次焦点小组访谈或做一次用户实地随访。其实高层往往对了解最终用户的想法很感兴趣，但平时跟最终用户接触的机会又非常少，如果你能够要请他们参与研究来获得与最终用户面对面的接触，他们会感谢你提供这种机会，也能够更切身地了解到你的工作有价值而不简单。
如何对待敌对分子
毫无疑问，不论你做的再好，你的产品中总会有些人不重视你的工作，无视研究结果，质疑研究价值。对这些“敌对”分子怎么办?你可以先采取本文上面提到的做“我们”的研究中得方法，尝试让“敌对”分子，变为研究团队的一员，也许瞬间他就从“敌对”分子变成“亲密战友”了。
但是，也有一些人人刀枪不入，那怎么办？那就先别管他了，接受无法让所有人满意这一现实。既然你没法让所有人认同你的工作，那就把精力放在团队可以团结的成员身上。也许，当你的研究被越来越多人认可的时候，那些“敌对”分子会改变主意的。
结论
笔者认为，必须做“有用”的研究。只有当研究能够实实在在地影响产品设计和策略时，研究员及其工作价值才能达到最大化。本文中，笔者基于自身的经历和其他同行的经验，总结了如何做“有用”的用户研究的若干建议。希望对相关同行有所帮助和启迪。
工作坊
Patti：老板你不懂设计
Patti在一家50人左右的移动应用初创公司担任用户体验设计师。她在该公司工作2年多。公司目前还没有专设的研究员，所以Patti在做产品设计的同时也需要做一些用户测试和研究。
这家公司的创始人Brian具有非常敏锐地商业直觉，他通常能够迅速抓住市场机会然后及时推出相应产品。Brian也自认为非常懂得产品设计，只要有时间就会亲自参与产品设计会议，并提出自己的意见。
大多数时候Brian给的意见都是基于自己的主观直觉，并且有时候跟Patti基于用户需求的想法直接冲突。比如上次会议中，Brian坚持要求界面菜单采用“扇形展开式”，认为这样的设计更炫，具有时代感，会受到年轻人的喜欢。但是Patti觉得这样做会造成较大的可用性问题，并且用户对其新颖性的新鲜感会迅速消失。Patti列举了这些理由来反驳，但是Brian并仍然坚持自己的主张。会议最后还是采用了Brian的方案，毕竟Brian是创始人。
Patti觉得目前Brian对设计的“微管理”已经严重影响了自己的工作和产品的用户体验。她必须想办法来改变这种情况。
思考
- Patti在他的工作和团队中是否很好的被认同？团队是否觉得他的工作很有价值？
- Patti将采取怎样的决策来解决这个挑战？请尽量多想一些注意和方案。制定一个计划，包括具体行动和时间点。