摘要：设计和用户研究通常会报告给集中化用户体验团队、产品团队或这些团队的混合体。每个模型都有明显的优缺点。
设计用户体验团队的结构很困难
建立一个能够进行有效协作和伙伴关系（用于用户体验设计或任何其他学科）的组织模型并不容易。团队结构总是在不断发展：新增加的团队成员，新开发的产品和功能以及随着时间的推移而获得的有关团队如何更好地进行沟通的经验教训都会导致团队结构断裂。
确定有效的用户体验团队结构特别困难，因为用户体验通常是在组织已经建立了其他学科（例如开发和产品管理）之后才添加的。此外，开发过程并不总是在模型中包含用户体验活动。
用户体验团队是按照三种常见的模型进行结构设计的，这些模型可以很大程度上适应这些组织的压力。在本文中，我们将讨论每种方法的优缺点，以便组织可以对其进行评估和比较，以确定最合适的模型为其用户体验员工们创建统一性和监督性。
用户体验专业人士通常会报告给:
- 集中化用户体验团队（centralized UX team）
- 产品团队（product team）
- 以上两者的混合（hybrid of these）
以上每种模型都有明显的优点和缺点。即使团队的结构可以遵循这些常见模型之一，我们也不应该期望它是一成不变的、僵化的或完美的。进行修订是必要的：在组织的某个时间点起作用的模型可能会在新的和不同的压力下被淘汰。相反，这些模型是通用方法，应在组织了解最适合其不断发展的环境的方法时加以应用和调整。
集中化用户体验团队（Centralized UX Team）
在一个集中化团队中，所有用户体验团队成员都向用户体验经理报告。用户体验团队成员根据需要从事各种产品和业务工作，基本上充当组织其他部门的顾问。
集中式用户体验小组都有一个用户体验经理，小组员工均向其汇报。用户体验工作人员根据需要研究各种产品和工作，并充当组织其他部门的顾问。用户体验专业人员可以与一个或多个团队合作（或等待分配）。
在用户体验方面投入较大的公司将有一个更精细的组织结构图，具有多个级别的用户体验管理，但如果它遵循严格集中化模型，则公司的所有用户体验专业人员都将向用户体验VP、用户体验主管、用户体验高职等具有任何高级头衔的人进行单层级报告。
该模型有时也称为“内部代理模型”（因为代理机构通常以这种方式构造设计和研究资源），或称为“用户体验即服务”（UXaaS）或“用户体验卓越中心”。
团队典型的工作方式
当产品或项目团队需要用户体验支持时，用户体验经理与产品团队负责人会进行反复沟通，以充分了解需求。然后，用户体验经理会根据项目需求以及用户体验团队成员的技能和可支配时间的一致性，在特定时间内为该项目分配用户体验团队成员。项目完成后，已分配的用户体验团队成员将返回到资源池以等待下一次分配。
用户体验团队成员可以根据每个需求的工作量来从事一个或多个项目。一个项目可能会持续很长一段时间。
集中化用户体验团队的好处
- 高级别的用户体验：拥有用户体验员工核心组意味着有一个用户体验经理或主管监督该团队的绩效和贡献；因此，需要对用户体验进行高级别的投资。用户体验经理可以描述、支持和捍卫组织的其余部分的用户体验，并且可以成为预算和资源的保管人。
- 广泛的用户体验技能：集中化团队通常包括从IA到研究的各种用户体验技能。因此，集中化的团队具有更高的广度和灵活性，并可以利用团队之间共享的大量用户体验技能集，为产品团队提供所需的内容。此外，集中化团队成员经常在各种专业知识领域进行指导和互相帮助，从而随着时间的推移，团队的集体技能将不断得到进步。
- 用户体验团队成员的广阔机会：作为顾问，用户体验团队成员通过从事各种项目获得了广泛的产品和组织知识。工作的多样性通常可以帮助用户体验员工保持挑战性，减少工作的“乏味”。此外，集中化团队可以传授这些广泛的知识，在需要时相互协商，并连接那些不会协同工作的产品团队。
- 已知的职业道路：集中化团队通常规模庞大，并且已经建立了工作阶梯、描述和职业道路。这种环境可以为用户体验员工提供要努力实现的目标。愿意保留个人贡献者的人仍然可以成长和升职，而想要成为管理者的人可以瞄准这些职位。同时拥有高管级用户体验职位和高级个人贡献者职位的团队可提供用户体验员工模范和导师，他们可以培养职业级和思想先进的专业人员。
- 用户体验团队之间共享资源：集中化用户体验团队可能会共享设计和研究资源以及知识，以培养个人成长并提高团队整体专业知识。DesignOps或ResearchOps的流程和角色可以帮助最大化团队之间的知识共享：共享的用户体验工具箱（例如，可交付成果的模板、用户研究见解数据库、研讨会议程）可帮助团队避免在每次使用工具或流程时都浪费精力。共享的研究参与者数据库可帮助团队克服进行用户研究时招募参与者的常见障碍。
集中化用户体验团队面临的挑战
- 用户体验团队通常是收费中心：通常，其他团队将不得不与用户体验团队合作，将其作为预算的项目。因此，用户体验团队必须（1）说服团队在他们的项目中加入用户体验（通常是足够困难的战斗），并且（2）用自己的预算支付。为了避免此问题，一些组织要求每个产品团队为用户体验工作分配一定的资金。这种方法可以减少集中化用户体验团队说服产品团队参与用户体验活动的需要。但是，即使出于最佳意图，用户体验成熟度较低的组织也可能会要求产品团队使用特定的用户研究方法，而这些方法实际上可能并不是最适合其需求和环境的方法。
- 被忽视：由于用户体验员工并未始终如一地纳入项目或产品团队，因此这些团队可能会忘记将用户体验积极地纳入其工作流。用户体验团队成员可能不会被邀请参加战略性对话、活动或会议，并非出于故意无视，而仅仅是因为他们不在意。
- 缺乏共识：在某些情况下，产品团队或用户体验专业人员可能缺乏共识。各个产品团队可能对用户体验知之甚少。当由于参与项目的内在性质而导致集中化用户体验员工无法获得深入的产品知识，因而效率降低时，这种看法可能会变得更加强烈。
- 难以预测的人员配备：如果用户体验经理对即将到来的项目不了解，可能是由于与组织领导层缺乏一致性，用户体验员工可能人手不足，无法帮助他们开展技能型项目或人员超编和闲置。
去中心化用户体验团队（Decentralized UX Team）
使用这种模型，没有核心的集中化用户体验员工组向用户体验经理报告，而是各个用户体验团队成员嵌入整个组织的多个团队中，与特定功能、产品或业务线保持一致。
在去中心化用户体验团队中，用户体验人员直接向产品团队报告。产品团队有预算，而用户体验工作就来自该预算。
这种模型通常是用户体验团队在传统的内部产品组织和初创公司（而不是设计机构和用户体验咨询公司）中起步的方式。去中心化通常被描述为“分布式”或“嵌入式”团队，有时也称为“Pods”。
团队典型的工作方式
用户体验员工分布在许多团队中。每个产品团队都有预算，而用户体验工作直接来自该预算。各个用户体验专业人员会全程与相同的开发人员，产品经理和其他团队成员合作，并向该团队中的个人报告。
去中心化用户体验团队的好处
去中心化用户体验团队的许多优点直接抵消了集中化团队的缺点：
- 增加信任和机会：由于各个用户体验人员用户是产品团队的一部分，所以这些用户体验专业人员可以与他们的产品团队成员建立信任。用户体验员工们能够成为他们工作的产品或业务领域的专家（由于长期的接触和关注范围有限），因此他们的价值可以很容易地被其他团队成员（他们也是该产品的专家）所认可。
- 用户体验人员参与的可能性很高：在去中心化模型中，用户体验团队成员与团队其他成员一样参与相同的计划会议、活动和对话。在实体办公室中，与产品团队成员坐在一起时，用户体验员工实际上会更加明显。因此，用户体验成员可能会参与工作流，从而提供贡献和证明价值的机会。
- 经理的责任感：负责用户体验团队的直属经理可能会比用户体验员工向其他区域报告时做出更大的努力，以确保用户体验成功。
去中心化用户体验团队的挑战
- 用户体验成员的数量可能会超额：特别是如果组织（或团队）的用户体验成熟度很低，出现分歧时，去中心化用户体验专业人士可能难以与许多开发人员和其他团队成员抗衡。一个或两个用户体验团队成员提出的异议很容易被忽略。
- 设计和研究时间很少：当用户体验员工人数过多时，他们可能会花费大量时间来推销、说服和教育其他团队成员用户体验的价值。特别是当用户体验未完全集成到开发流程中时，尝试将用户体验插入流程中的工作可能会花费用户体验团队的大部分时间，而用在研究和设计上的时间却很少！
- 冗余的用户体验工作：与集中化模型正好相反，去中心化的用户体验人员很难定期交流和共享资源。尤其是在缺少集中化设计系统、UX框架或研究见解存储库的情况下，由于缺乏一致性和协作性，工作可能会被浪费和重复。不知不觉中，用户体验专业人员将从头开始创建可交付成果、研究计划或设计元素，而不是从过去的努力中利用现有资源。
- 没有流程改进：由于没有指定的用户管理人员负责公司的整体用户体验工作，因此没有人负责不断改善用户体验工作的质量和生产力。
矩阵式用户体验团队（Matrix UX Team）
矩阵式用户体验团队模型是集中化模型和去中心化模型的混合体。在这里，用户体验人员要向集中化用户体验组经理和产品团队报告。（其中一个管理者具有优先权，因此比另一个管理者具有更高的权重。）因此，用户体验团队成员受用户体验特定领导和单个团队领导的监督。
集中化和去中心化用户体验模型的混合形式是矩阵式用户体验团队，其中用户体验人员向集中化用户体验经理报告（实线）和向产品团队报告（虚线）。 其中一位经理比另一位更有份量。
像去中心化模型一样，混合模型可以在使用Agile或Scrum方法的组织中很好地工作。组织如何创建合并管理方法的细节可能会有很多差异，该方法利用了集中化和去中心化模型中对他们来讲最重要的优势。
团队典型的工作方式
在混合模型的常见实例中，用户体验员工分布在许多团队中，他们在其中充当长期资源和团队成员。根据组织结构的不同，他们的团队可能要与特定的功能、产品、领域或业务范围保持一致。 日常指导由团队负责人（例如产品经理或Scrum主管）提供并监督；但是，用户体验经理或执行人员也提供监督（通常从职业发展和个人成长的角度）。通常，用户体验范围内的各个会议（例如设计评审或实践社区）会保留各个用户体验团队成员之间的协调和协作。
此外，用户体验经理可以监督少数额外的员工，这些员工不是被分配到产品团队，而是负责全公司范围内的计划，例如创建设计标准或运行可用性实验室（用于处理每个产品的用户体验员工执行产品设计测试）。
矩阵式用户体验团队的优势
- 将重点放在用户体验上：在矩阵模型中，用户体验经理和产品团队负责人对用户体验进行监督；因此，两名经理可能会对用户体验专业人士的成功负责，从而对用户体验总体负责。
- 建立真正合作伙伴关系的可能性很高：由于用户体验专业人士与单个产品团队长期合作，因此其他产品团队成员可能会将用户体验员工视为他们团队的真正组成部分，使他们参与关键的对话、会议和活动。
- 增强的灵活性：矩阵团队不像集中化或去中心化团队那样严格，因此可以轻松适应不断变化的组织压力或短期的即时需求。
矩阵式用户体验团队的挑战
- 用户体验从业人员的困惑：因为用户体验工作人员需要以某种方式向两位经理汇报，所以他们可能会感到朝着两个不同的方向前进，不确定哪个经理在设计方向上拥有最终的权威，该由谁来处理人员或团队问题，或哪个是来处理职业目标的人。
- 难以实施：在具有许多层级的大型组织中，矩阵模型可能难以实施。但是，在拥有多个产品团队的组织中，只要用户体验团队负责人和产品团队负责人与他们的用户体验目标保持同步，矩阵式用户体验模型就可以同时提供集中化和去中心化的优势。
哪种模式适合我的组织？
这些常见结构中没有最佳模型。应由总体组织环境（例如，组织规模、产品复杂性、用户体验团队的能力与组织需求相比）来决定采用哪一种模型。话虽如此，还是观察到了两种常见的模式：
通常，设计机构中的新生团队始于集中化模型。在团队成立之初，通常没有足够的设计和研究人员来支持去中心化模型。随着用户体验员工人数的增加（通常与对技能的需求增加相关），团队可能会演化为去中心化模式，因为现在有足够的用户体验人员和用户体验专业知识以固定的方式分布在各个团队之间。
相反，内部产品组织通常从去中心化的团队开始。由于认识到对用户体验的需求，因此各个团队都可以聘请用户体验员工。随着个人价值的实现，其他团队开始寻求用户体验角色的支持。最终，可能会批准员工编制和预算担任其他角色。随着用户体验员工人数的增加，用户体验团队成员通常开始领导并建议一个集中化团队，以提高效率和知识共享的优势。
经过一番时间和经验教训，许多组织（机构和内部产品组织）最终都采用了矩阵模型。通过这种灵活的混合方法，组织可以平衡用户体验和产品团队之间的长期合作关系，以及核心用户体验团队之间保持协作一致性。
在确定哪种模型最适合你的团队时，请考虑以下内容：
- 现有流程：团队当前使用的流程是否包括用户体验活动和检查点？如果不是这样，那么对于任何人来说，用户体验都会很困难，但是在去中心化模型中，对于产品团队中的一个用户体验人员而言，用户体验尤其困难。缺乏支持和资源意味着此人将花费大量时间只是试图说服团队进行用户体验工作。
- 用户体验团队的规模与产品和产品团队数量相比：是否有足够的用户体验人员致力于单个产品团队中去？或者，是否需要按项目进行优先级排序？如果一个去中心化的模型是合适的，但是产品或Scrum团队比用户体验人员更多，那么哪个团队将具有用户体验人员，而哪个团队则没有？可以客观一致地做出该决定吗？如果需要按项目进行优先级排序，则集中化模型或矩阵可以充当用户体验分配的保管人。
- 工作量：各个产品团队对用户体验专业知识的需求是否足以证明专用用户体验资源的合理性？或者，去中心化的用户体验团队成员会发现自己坐在那里扭动手指，希望他们可以为需要技能的工作流做出贡献吗？
- 用户体验的成熟度和文化：分散用户体验员工的专业知识和见识是否会像单个产品团队的其他成员一样有价值？
- 合作机会：如果用户体验团队以去中心化分布，那么如何在用户体验团队之间实现协作和资源共享？可以安排哪些会议、空间或仪式来确保保持一致？
（编译完）
英文原文：https://www.nngroup.com/articles/ux-team-models/
原文作者：Kate Kaplan
编译作者：@iris0327
以上译文仅代表原作者观点。如需转载请遵循CC版权协议正确标明出处。
