ORIGINALLY PUBLISHED IN ENGLISH: Accelerating User Research: How We Structure Insights for Speed At Spotify
一直以来，由于人们认为用户研究的有效性较低，用户研究所得的洞察都在产品开发中被边缘化。我在职业生涯的第一阶段致力于提倡组织为什么该积极地听取用户的意见和想法，为什么每一个人应该相信定性见解可用于指导他们的决策，以及为什么用户研究是需要专业技能的实践领域。
随着用户研究逐渐证明贡献价值的能力，对于其效度的质疑和争论也在日趋减少。从数据、证据和同理心的角度来考虑产品的设计已经成为一种既定的方式。 在像在Spotify这样的公司中，用户研究的需求在快速增长，我们不得不开始考虑如何将用户研究的实践规模化。新的、更实质性的问题开始出现，要求我们以更快速度来创造价值的能力能够与快速将产品推向市场的财务和竞争优势相匹配。用户研究，或者是更广义上的洞察，一直因为产出速度慢而备受诟病 ——这个观点的存在也是有价值的。
面对这样的负面评价，来自各行业的用户研究员们开始引进多种方法，以使得我们可以在几周甚至几天内完成研究。如果使用得当的话，这些方法策略可以很好地帮助我们在加速研究的同时不影响其完整性：
- 从2000年代出现的快速迭代测试和评估 (RITE) 到guerilla可用性测试以及谷歌的设计冲刺 (Design Sprint)，在两周内完成一些简单的评估研究已经成为常态。
- 公司组织内部的洞察部门也已经建立起了更有利于快速研究的团队架构。在大公司（例如Spotify、微软、谷歌）中，一种常见的方法是让一组研究人员按每周或每两周一次的频率进行定期的研究会议，将整个公司内范围狭小的研究问题合并为一项研究。其目的在于一方面更好地普及用户研究，另一方面又可共享资源而获得规模效益。
- 被试招募是聚焦于速度的创新的关键领域之一，包括在Spotify在内的很多公司都建立了被试社区或平台，这样可以快速并精确地从这些社区或平台中选择所需的资源。用户研究的第三方服务提供商也可以帮助快速获取所需的被试，这也成为了研究工具（例如调查或远程测试平台）的一项关键增值服务。
- 最后，新兴了许多将研究过程各个环节自动化的工具和流程。例如，问卷和卡片分类平台就提供了提前设置好的问题和可规模化的材料库，以及分析和报告的模块。从笔记记录、报告模板到写作分析以及最后陈述的模版，研究团队在不断地迭代和简化其工作的流程。
常规化的用户研究是一种优化的研究实践。但事实上，许多有影响力的用户研究不是常规的，而且它们确实需要时间。
乔·蒙科（Joe Munko）恰当地描述了这一点：“当时间限制迫使我们放弃能够融入客户反馈的严谨性和流程时，您进行的用户研究将失去效度，并最终失去其价值。”与其问我们如何能进一步加快研究本身，不如说我们能如何更好地将用户研究整合到产品开发实践中，并提高组织的整体学习和迭代的能力。究其终，我看到了用户反馈环路 (user feedback loop) 缓慢的两个根本原因：一个是我们将用户研究视为所有决策的关卡，另一个没有使用户研究和产品敏捷开发周期保持一致。
不要将研究当作一个关卡
当用户研究在产品开发过程中被普遍应用，我们也开始将其视为所有决定的必要前提。更有效率的做法是将用户研究当作帮助产品决策的输入之一，以及关注客户和人文的组织文化的催化剂。用户研究并不能回答所有问题。我赞同马特·加里文（Matt Gallivan）鼓励研究人员接受其工作固有的不确定性的观点。在产品团队中，将用户研究视为所有产品必须通过的关卡，这会导致不必要的风险规避文化。最终我们做的用户研究是低效度的，只对不可避免的问题进行了研究，或只专注于用户测试，却忽略了其它可能更合适或有助于快速获取的证据。
我们应该只开展有效的研究。用户研究人员通常认为承认定性研究无法可靠地回答某些问题是不符合实践准则的，或者是作为研究人员本身能力的失败。这正是我们最终进行低效度研究的原因。这些研究会减慢产品开发的速度，但最糟糕的结果是导致团队误入歧途。
为了验证战略方向或特定设计概念而进行研究，是甚至经验丰富的研究团队都会有的错误认识。我不赞成将用户研究视为验证的想法。这不仅表明你有很大可能倾向于去制定容易导致确认偏差的研究设计，也忽略了定性研究是一种非常差的假设检验工具。因此它是无法帮助确认这个产品方向是正确的。相反，定性研究非常适用于生成假设，并且有助于识别有待评估的产品概念中存在的风险。
评估不进行研究的风险。多年来，用户研究员的一大部分工作重心总是在于继续推动对用研的需求。作为用户研究员，我们常常在看到用研还处于刚需的时候觉得松了一口气。其结果是，我们最终进行的研究只是影响风险极低或在某些情况下是不可避免的决策。这导致功能团队为了等待研究完成而暂缓发布进度。即使最后研究表明有必要做产品迭代或修改时，他们也没有明确的信念进行大范围更改。
组织应在产品制造团队的各个部门中建立清晰的准则和一致性，以一致地评估与每个决策相关的风险：如果大规模测试发现问题，此决策是否容易改变？我们是否有过去的研究或其他信号可以降低与此决策相关的风险？如果发现风险，我们是否会推迟发布以做进一步迭代？这可以帮助你评估每个研究计划的投资回报率，使你可以将更多的时间花在战略研究上，并且可以让团队在决策风险较低的情况下迅速投入工作。
考虑不同类型的证据。一贯使用某种特定洞察方法获得成功的组织，即使在研究问题根本不同的情况下，也会很容易陷入继续采用之前被证明过有效的方法的模式。这种认知偏差被称为马斯洛的锤子，也就是说，当你拿着锤子时，每个问题都看起来像钉子一样。具有丰富用户研究实践的组织倾向于在任何地方都看到用户研究问题，即便实际上通过另一种手段（比如实验，竞争情报或市场研究）能找到更好的答案。
在Spotify，我们将用户研究和数据科学实践结合在一起，整合到产品洞察之下。你可以在此文了解我们是如何组织和开展实践的。我相信，在一个团队中掌握各种洞察方法能让我们对用户产生更全面的了解。这也使我们在选择最适合的策略或产品决策的方法时更加谨慎。这从不同的方面提高了产品发布的速度。首先，它有助于解决上述两个问题：通过采用大规模试验和深入的产品数据分析方法，我们可以避免低效度或不必要的研究。用户研究用于识别正确的假设以进行接下来大规模测试，或是进一步探究我们尚不理解的实验结果。其次，它可以帮助加快研究本身：例如定量区分出使用行为不同的产品用户群体，能帮助我们将研究对准感兴趣的细分市场。
研究与敏捷开发保持一致
跨部门的运营模式和现代产品开发的快速周期都要求研究时机更谨慎准确，否则洞察将不可避免地成为障碍。我十分赞同敏捷开发的两种基本信念：多样化的团队可以创造更好的产品，将问题分解开来则可以提高我们按照预期快速交付产品的能力。但这些原则可能与研究本身的时间和范围产生冲突。
投资可“拿来即用”的洞察。在敏捷团队中工作的研究人员经常发现，他们的大部分工作都是在设计冲刺前或结束时进行的为期一天的研究。对于研究者而言，这不仅是一项不尽人意的工作，还给研究本身带来了巨大的风险。聚焦在产品某个功能的小范围研究给用户进行了人为的设置和限定，而用户的实际需求并非只集中在单个页面或流程的某个部分上。这会增加结果出现偏差的风险；打个比方，只研究弹出通知而不考虑整个信息系统的设计。Leisa Reichelt在她最近的博客文章中恰当地描述了这种筒仓效应（Silo Effect）。范围局限还缩短了洞察的有效寿命，因为最终的调研结果与更大的用户需求或旅程严重脱钩。我认为乔·蒙科（Joe Munko）对浪费的“一次性研究”的描述是准确的。孤立的研究会降低组织积累知识的能力。这与速度有什么关系呢？当组织没有可“拿来即用”的现成知识来制定策略或对用户进行合理的假设时，大多数不管大小的项目提议都需要新的基础研究。
工作领先于跨部门产品组。成为跨部门产品开发团队的重要成员对于获得洞察是极其有利的。我清楚地记得之前”研究即服务”的时代：工作是应利益相关者的要求进行的，或者是在研究团队内部发起的，却从未真正进入产品的制造过程。这样的研究通常会遭受“非我所创的问题”的质疑，或者是由于研究人员过于远离产品团队而没有正确的阐述问题。不过，用户研究工作若想与scrum团队保持同步，会很容易成为其阻碍，因为往往在定义产品范围和计划的阶段就需要洞察的支持。
为了进一步投资可“拿来即用”的洞察和工作领先于产品组之前，我们在Spotify采取的解决方案包括改变工作方式、规划结构和团队结构。
- 双轨洞察过程。我要求我的团队在任何季度都从两个方向去考虑他们的工作：一是为整个组织持续的知识积累而推动的基础研究，另一个是为跨部门团队产品决策所需见解而进行按需输出研究。
- 学习OKRs。为了确保组织对持续学习进行投资，并且提前三个月或六个月计划所需的证据、洞察系统或方法，我引入了“学习目标”的概念，将其作为季度OKR流程的一部分。通过这种机制，团队会慢慢将学习视为一种经过深思熟虑的投资，与类似于在技术平台上进行的投资一样重要。当学习OKRs的优先级由跨部门领导团队一起协商，而不仅仅只是作为用研洞察的“激情项目” (passion project) 时，就意味着得到了团队对于基础研究的更多投入和支持。
- 结合嵌入式和中心化洞察结构。我们介绍了战略性洞察团队的概念，该团队由来自用户研究和数据科学背景的从业人员组成。我们负责探索组织中对于短期和中期产品路线图之外的知识缺口。为了避免传统的中央研究团队面临的与组织其余部分脱节的挑战，中心化结构正在尝试一种时基模型(Timebank Model），其中嵌入到产品组的研究人员会贡献时间与中央团队一起合作。
结论
如何加快研究速度是致力于洞察的组织面临的主要挑战。有几种优化常规研究过程的方法，这些方法不会损害其完整性，但能有效缩短周期。但从根本上讲，组织应该认可研究需要一定的严谨性和时间投入才能保证其价值。组织可以尝试采用以下策略来提高学习速度，而不是企图进一步加快研究本身：
- 不要将研究视为关卡：改变将研究视为验证的观点，将研究资源集中在会让组织承担最高风险的决策上，并考虑可能比定性研究更快或更合适的数据形式。
- 将研究与敏捷开发保持一致：将对于小范围研究的投资转移到可“拿来即用”的现成洞察上，将洞察视为由快速研究和基础研究组成的双轨流程，将基础研究整合到公司范围内的计划结构中，以及建立灵活的团队结构来进行基础研究，就可避免与产品开发脱节的问题。
参考文献
Belt, Sara and Gilks, Peter. 2018. Cross-disciplinary Insights Teams: Integrating Data Scientists and User Researchers at Spotify. EPIC Perspectives.
DeCapua, Melissa. 2018. Life in the FAST Lane The successes, challenges, and influence of Microsoft’s quick-turnaround user research team. Medium, August 7.
Gallivan, Matt. Embracing Uncertainty in UX Research. Accessed Sept 29, 2019.
Munko, Joe. 2018. Skip User Research Unless You Are Doing it Right.
Reichelt, Leisa. 2019. Five Dysfunctions of ‘Democratised’ Research. Part 2 – Researching in Our Silos Leads to False Positives.
Toussaint, Heidi S. 2018. Rapid UX Research at Google.
翻译简介：
Linzi Xu , 好奇心无穷的用户体验研究员, 现任职于微软, 曾就职于SAP。希望通过用户研究助力包容性设计。
校对简介：
Yulin Wang, 现任脸书用户体验研究员。曾就职于亚马逊Kindle和戴尔设计体验部。致力于通过用户调研为产品团队挖掘洞悉和创新方向。
0 Comments