时间: 2021-07-30 09:25:51 人气: 5 评论: 0
此文笔者从多种不同类型的团队角度出发，分析了用研在不同团队中所发挥的作用，以及一些力不能及之处，相信可为读者们提供了解用研在公司实际工作中的工作场景的机**。
我在一个新组建的部门中，一个模糊的团队里，作为一名有点无处不在的角色来开始我的用户体验研究（以下简称用研）生涯。这么说吧，我试图轻描淡写地、以模棱两可的方式来进行工作管理。
几年后，我经历了不同的组织变革，这些变革将我们的用研部门置于不同的组织层次结构之下。
这些经历都有种种不同的优点来助力我们团队的成功，同时也阐明了一些可以改善我们未来工作流程的机**点。
在做了一些初步的行业研究后，我决定退后一步，开放性地探索”用户体验研究“每一个可能去往的归宿。
根据公司结构和职能角色的需求不同，用研中部分是行为观察，部分是商业战略，部分是心理学，部分是数据分析，部分是设计，部分是团队促进。用研可以有不同的风格，因此可以在行业范围内四处移换位置。
根据公司规模和类型的不同，我见过很多用研团队变成设计部门的一部分，有些则变成营销部门的一部分，还有一些则在产品管理部门——最终在哪都根据公司的规模和类型来决定。
在我任职期间的某个时候，我自己的团队已经集结到了之前提到的各个部门。
所以，有没有一个部门可以更加适合配备用研部门，让用研更加成功且具有影响力呢？这是我想找到的答案。
研究与设计交织在一起：
用研已经成为许多用户体验设计师工作职位描述中的一部分，而用研的核心就是指导设计。研究结果可以指导交互行为，并且它从一开始就已经嵌入了设计过程里。
如果一个设计团队有专门设立研究部门，**让这个团队变成一个强大的联盟。让更大的设计团队统一研究整体用户策略，**让之后的调研和设计过程更加整体和完善。
同样，设计师也有想改善用户体验的众多想法，并且通常很高兴能看到用户和他们的想法进行交流。这直接与这些创造用户体验改善的设计师们，促成了一个强有力的文化测试、迭代、再测试的过程。
由于设计与用研的过程是结合在一起的，因此可以立刻将这些用户洞察应用到设计中去
类似的工作流程：
用研的工作流程与传统的设计流程十分相似。设计领导者可以无缝地理解研究的各个阶段：复查现有的数据，引导生产性研究，汇编各种信息从而寻找新的模式，创建一份报告，陈述研究结果，在上线后测试等等。
同时，从设计概念开始，征求意见、进行测试比较设计方案的好坏、迭代设计、产出最终的版本、呈现并且在上线之后进行迭代。设计和用研通常希望携手合作，共同努力改善数字化体验。
设计≠用研：
不是所有的设计师都**进行研究，要么是因为他们没有时间，要么是因为他们没有接受过理解研究方法的训练（相反，也不是所有的研究人员都是设计师）。
通常，公司**安排设计师同时做研究员的工作，反之亦然。这对最终实现的产品来说可能是灾难性的，尤其是在较小的公司中，设计师需要扮演很多职能。这意味着他们“有时候“有时间能亲自调研。
不幸的是，在设计和用研没有明确定义的前提下，这意味着雇佣部门和领导团队认为这两者是可以互换的。
注意：这并不意味着某些设计师没有资格，只是“视觉设计师 / 平面设计师”、“UI设计师”和“UX设计师”的技能组合是有区别的，但我不**在这里讨论这些。
用户需求可能**被遗忘:
有时候，一个设计规划图**被过分热烈的创造性驱动从而创建，而不是来自于数据或研究。很多时候，创意人员**对他们喜欢的新想法产生依恋，即使它并非源于用户需要的东西(有时候我们都**为此感到内疚)。
不幸的是，这意味着研究可能是事后的想法，更经常地被作为验证工具而使用，而不是在产品生命周期中预先定义需求。这对于用研来说，可能成为难以克服的一个障碍，特别是如果设计概念与利益攸关方或决策者领导人一起审查，他们喜欢并认为这是一个“可以去做的设计”，这意味着研究的机**很有可能丧失。
相似的技能组合:
市场研究和ux/产品的研究在他们特定的核心研究中，共享相似的过程和研究方法。
在社**心理学、市场营销学、人类学、人的因素、运作和设计等许多领域进行“人的研究”所使用的工具包非常相似：定量方法，如大样本调查和分析；定性方法，如面对面的观察，焦点小组，适度的访谈，日记研究以及其他。每个领域的方法都需要研究设计、用户招募和研究分析。
对于市场团队来说，这是一个非常熟悉的世界，作为用研流动到这个部门，意味着领导者可能**对你的角色需求有一个彻底的了解。
共同的目标是了解用户:
市场团队也将是你的拥护者。无论如何，源自于产品和设计的用户研究的洞察力，为市场部门关注的许多举措增添了直接价值。
透过略微不同的角度来看，市场营销和用户体验有着相似的目标（理解客户）。尽管如此，当团队协作并共享信息，在以业务或用户为中心的举措之间建立平衡时，用研结果还是能够帮助我们进行决策。
商业需求可能与用户需求相反:
如果组成“聚焦点”的事物变化太大，那么这个“聚焦点”既可以将市场营销与用户体验结合起来，也可以将它们分开。当业务需求与用户需求相矛盾时，可能**产生摩擦。
如果市场部门的领导层将眼前的业务优先级置于用户研究之上，那么获取工具和客户的途径就可能受到限制。在一天结束的时候，市场团队关注创收，即使这对用户来说不是最好的体验（比如在某个地方放置广告，可能**干扰网页，以确保用户看到它）。
而用研团队关注什么是对用户体验最好的(比如在页面上放置一个广告，使其不**干扰用户的任务，冒着用户看不到并参与其中的风险)。
用研 ≠市场研究:
有时候，流动到市场部门意味着其他人将用研视作为市场研究的延伸。由于这一点，一些项目有可能被认为应该由市场专家处理，而不是用户体验专家。
例如，营销活动的目标可能是“我们如何让用户使用这次促销活动”？另一方面，用研可能**强调用户的需求，比如“用户希望如何获得有关促销活动的通知”？这种情况（关注点的转移）并不可能经常出现在市场部的议程表上。
为产品使用路径图研究分配时间:
通过将用研嵌入到产品管理团队中，研究有机**通过在产品路径图中划出其应有的空间和时间来充分发挥其潜力。通过让用研和产品经理向同一个领导层汇报，这意味着目标和优先级可以被共享，并且在同一时间被一起审查。这可能是一个有效的工作方式，特别是当你与产品经理一起工作的项目，他们知道如何使他们的产品更直观地呈现给用户。
用研的产品管理为定义实际产品需求创建了一种更加无缝的方法。这意味着路线规划图中留出了时间，在积压成定局之前走出去，获得用户见解。这告知了大家需要开发的功能的优先级，并在完成设计之前，就形成产品了本身的特性。
当用研与产品经理的目标紧密相连时，每个注入了用户见解的产品阶段都变得更加容易（因为它应该是在一个理想的世界中）。
更容易地与决策者进行知识交换:
将产品经理的内部结构与用研的内部结构相结合，也意味着他们可以获得更多用户关于他们的体验的言论，从而形成定期更新，并且可以更容易地进入用户途径。
用研经常关注复查定性趋势的反馈（比如Qualtrics或者Medallia系统）（在线调查或客户体验管理系统），这意味着产品经理听到这些趋势的机**变得更加频繁。
产品经理一般来说应该对他们的用户群有深刻的理解，但是他们通常很难在倾听用户的基础上来保持冲刺、业务分析、 KPI 和产品路线图规划。因为团队**议中现在有一个指定的用户代言人一直在场，这就是为什么与用研如此紧密地联系在一起对产品经理来说是有益的。
参加这些**议，使得用研有机**直接与那些最需要了解用户需求的人进行自发的对话。加入同一个团队可以使这些沟通渠道更加开放，并且可以更加频繁地了解用户对产品经理的需求。
研究的优先级可能**降低:
不幸的是，转到产品管理团队意味着有时研究的优先级**降低。
当利益相关者对产品交付施加压力时，这通常意味着产品需要尽快推出。然后，产品经理必须专注于发布他们产品路线图规划上的项目，并在时间表和开发周期内实现业务目标。
为了满足这些时间要求，尽快交付某些东西成为更紧迫的目标，而不是交付一个经过研究和磨练的产品（这需要更多的时间）。
更多的评估而不是生产性研究:
把用研流动这个部门可能意味着这项研究变得更加可评估（或者验证、可用性和迭代测试），而不是生产性（或者理解需求、价值和概念发现或开发的测试），就像在设计团队下可以做的那样。
这不是一件坏事，而只是需要牢记在心，以便作为一个用户倡导者。用研的工作可以更直言不讳地说，需要留出时间来做更深入、生产性的工作，从长远来看而不是短期内为产品提供信息。提前了解这个可能的障碍意味着用研可以更好地装备自己的ROI（投资回报率）影响，以便为更深入的研究腾出时间。
注意: 我还没有在一个独立的，指定的UX研究部门作为一个UX研究员的工作经验。我只能推测将一个独立的用研团队集合起来**是什么样子，或者当用研成为一个大型组织中自己的分支时，领导力的优缺点是什么。
拥有自己带领的用研部门，可以为更深入地研究需求提供机**，它将有能力根据合作伙伴的规划路线图从而制定自己的规划路线图。
它可以让部门领导层能够深入地支持研究人员的需求，因为需求经常遇到障碍（如招聘、用户日程安排、预算、批准、 研究运营管理的行政工作等），能够拥有一个研究路线规划图，并为发现和生成性研究腾出时间。
从长远来看，可能**大大有助于产品和客户体验的信息共享，拥有一个独立的团队可以使这些研究成为奢侈品。当一个领导者致力于使研究成功，这意味着他们希望研究可以带来更多战略上的影响。
正如我之前提到的，一些被称为“ResearchOps（研究运营管理）”或者研究操作的东西，是一个趋势短语，类似于“designnops①”或者“DevOps②”等。
抛开时髦不说，设立一个独立的部门和领导层可能意味着在决策层有一个更大的席位，这反过来又意味着在使体验研究产生影响方面有更多的投资。当投入更多资金进行研究时，业务侧就有机**进行战略思考并得到支持。
一个独立的用研部门反过来将能够雇佣人来支持行政管理，为研究人员能够专注于他们眼前的工作和分析而负责。在小型组织中，甚至在大型组织中的小型用研团队中（比如我的团队），研究人员往往负责所有的职能，这也是可以的。
但是，如果有一个专门关注于这些研究人员需求的部门，并扩大他们工作的影响（不管团队规模有多大），我相信将有更大的机**去收集更好、更深入的见解，研究过程也能充分发挥其影响力和潜力。
① Design Systems Ops 是设计团队的一部分，他需要足够了解设计，并且要了解他们试图概念化什么。同时，Design Systems Ops 需要理解工程师的需求和定义方法，这将有助于设计系统的装运和规模化。在某些程度上，一个 Design Systems Ops 是两个世界的翻译。
② DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
相反，单独作为一个独立的用研部门，也可能使得决策层难以接受。
如果不流入一个直接产生收入影响的部门内（至少在短期内，比如在销售或营销方面），那么用研的工作就很难得到认可。利益相关者之间的伙伴关系和一致性，对于用研人员能够成功地完成他们的工作来说至关重要。
如果没有它，如果用研的需求被认为不是直接以产品为中心，同样的职位可以帮助用研，也可能**阻碍他们。开展生产性研究的时间可能被视为“有风险” ，而且当团队的领导层与其他更为成熟的角色（即风险较低的角色）分离时，可能很难获得合作伙伴和利益相关者的支持。
同样，投资一个独立的用研团队总的来说可能是有风险的。可能很难预测到有形的ROI（投资回报率）预测，以便业务合作伙伴能够理解，并在第一时间投入资金。
这意味着，决策者们可能认为给用研分配预算或增加人数是有风险的，其他研究需求也是如此。一般来说，R&D（产品研发）在组织中是一个棘手的领域，而用研肯定**在这个预算范围内。
尽管有证据表明，对研发的投资有能力改变企业经营的底线，并且可以通过创新保持企业价值，所以相对于独立的用研部门，紧迫的商业需求可能话语权更大。
请随时留下你的想法，意见和任何答案，以下这些开放的问题。
我很想了解更多关于 UX Research 在其他组织中的位置，以及你们在这个过程中都学到了什么。
原文作者：Danae Paparis
原文地址：https://uxdesign.cc/where-should-ux-research-live-7d0e7f86e2db
本文由 @三分设 翻译发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
