如何建立UX团队:UX团队的3种常见模型

简介:设计和用户研究工作通常会存在于集中式UX团队、分散式UX团队或矩阵UX团队中,这三种类型的团队模型,每一种都有明显的优缺点。

一、建立UX团队组织架构很难

为UX设计或任何其他学科建立一个能够实现有效协作和伙伴关系的组织模型并不容易。

团队结构总是在不断演变:新加入的团队成员、新开发的产品和特性,以及随着时间的推移所学到的关于团队如何进行最佳沟通的经验教训,都会导致团队结构的破裂。

定义一个有效的用户体验团队结构特别困难,因为用户体验通常是在组织结构中已经建立了其他学科(如开发和产品经理)之后添加的。此外,开发时并不总是在其模型流程中中包含UX。

UX团队是根据三种常见的团队模型构建的,这些模型在很大程度上适应了上面所提到的组织压力。在本文中,我们将讨论每种模型的优势和弊端,可以对其进行评估和比较,以确定对其UX员工进行调整和监督的最合适的模型。

UX团队模型分为以下三种:

  1. 集中式UX团队
  2. 分散式UX团队
  3. 矩阵UX团队

每一种模型都有明显的优缺点。即使团队的结构可以遵循这三种通用的模型之一,我们也不能期望它是一成不变的或完美的。

不断修改和纠正是必要的:在团队的某个时间点起作用的模型可能会在新的和不同的压力下过时。这些模型是通用方法,应随着团队的了解和不断发展来应用和调整。

1. 集中式UX团队

在一个集中的专业UX团队中,所有的UX团队成员都向UX经理报告。UX团队成员根据需要处理各种产品和业务工作,基本上充当组织其他部门的顾问,并为产品赋能。

产品经理,产品经理网站

一个专业的集中式UX团队有一个UX经理,UX成员向其汇报工作。UX成员根据需要处理各种产品和工作,充当组织其他部门的顾问,UX成员可以与一个或多个团队合作(或等待下发任务)。

一个在用户体验方面有大量投入的公司会有一个更精细的组织结构图,有多个层次的UX管理,但是如果它遵循一个严格的集中模式,公司的所有用户体验专业人员将向一个单一的层级汇报,由用户体验副总裁,用户体验总监,或者公司顶级用户体验人员使用的其他任何头衔。

这种模式有时也被称为“内部代理模式”(因为代理通常以这种方式组织设计和研究资源),或“用户体验即服务”(UX as a service)或“用户体验中心”。

1)集中式UX团队通常的工作方式

当某个产品或项目需要UX支持时,UX经理与产品团队负责人反复沟通,以充分了解需求。然后,UX经理根据项目需求与UX团队成员的技能及可用性相匹配,将一个UX团队成员分配给该项目一段特定的时间。项目完成后,被分配的UX团队成员将返回资源池以等待其他分配。

用户体验团队成员可以根据每个需求的工作量处理一个或多个项目。一个项目可能会持续很长或很短的时间。

2)集中式UX团队的优势

高水平的用户体验:

拥有一个专业的集中式用户体验团队意味着有一个用户体验经理或执行官监督该团队的绩效和贡献,因此,团队将输出高水平的用户体验作品。用户体验经理可以向其他团队的成员描述、支持和捍卫用户体验,并担任预算和资源管理员。

广泛的UX技能:

集中式用户体验团队通常包括各种各样的用户体验技能,从信息架构到用户研究。因此,集中式用户体验团队具有更大的宽度和灵活性,可以从团队中获得大量用户体验(UX)技能,集中为产品团队提供他们所需要的东西。此外,用户体验团队成员可以经常在不同的专业领域内相互指导和帮助,随着时间的推移,团队的整体技能不断发展。

UX团队成员更多的机会:

作为顾问,用户体验团队成员从事各种项目,获得更多的产品经验和跨产品知识,并为产品赋能。

工作的多样性通常有助于用户体验专员在工作中保持挑战性,减少“无聊”。此外,集中式用户体验团队可以互相传递更多的知识,在需要时相互咨询,并将不在一起工作的产品团队联系起来。

明确的职业道路:

集中式用户体验团队往往规模很大,并且已经建立了工作职称、描述和职业道路。这个环境可以为用户体验人员提供奋斗的目标。那些想要走技术路线的人仍然可以成长和提升,而那些想成为管理的人可以瞄准某些职位。拥有高级管理和高级技术的团队,提供用户体验角色模型和导师,他们可以建立新的UX成员的职业信心。

UX团队内部资源共享:

一个集中式的UX团队可以共享设计、研究资源以及知识,实现个人成长并提高整个团队的专业知识。DesignOps或ResearchOps的流程和角色可以最大限度地帮助实现团队间的知识共享:共享的UX工具箱(例如,交付成果的模板、用户研究见解数据库、研讨会议程等)有助于避免团队成员每次在使用工具或流程时浪费精力和时间。共享的研究参与者数据库有助于团队在进行用户研究时克服普遍存在的参与者招募的障碍。

3)集中式UX团队的弊端

UX团队通常是“退款中心”:

通常,其他团队必须将与UX团队的协作列为项目预算中的一部分。

因此,UX团队必须说服项目团队在他们的项目中加入UX(通常是一场艰难的battle),用自己的预算支付UX的费用。

为了避免此问题的出现,某些企业会要求每个产品团队分出一定的资金来支持UX工作。这种方法可以减少专业的UX团队说服产品团队参与UX活动的需要。

但是,即使是基于最佳的考虑和目标,UX成熟度较低的企业也可能会要求产品团队使用不符合特定的需求和环境的用户研究方法。

看不见,想不到:

由于UX人员没有从头到尾并入到项目或产品团队中,这些团队可能会忘记主动地将UX工作流程引入到他们的工作流程中。

用户体验团队成员可能不会被邀请参加关键的讨论、活动或会议,这并不是出于有意的忽视,而是因为他们并不是最重要的。

缺乏共识及理解:

在某些情况下,产品团队和UX专业人员之间可能缺乏共识。

各个产品团队可能对UX知之甚少或缺乏相应的理解和尊重,当因为没有从头到尾参与项目中而导致专业的UX团队成员无法获得足够深入的产品知识,导致效率降低时,这种看法可能会更加强烈。

难以预测人员配置:

如果UX经理对即将到来的项目不是很了解,或者是没有与其他团队leader达成一致,用户体验人员可能要么人手不足,无法帮助到需要他们的项目,要么人手过多,无所事事。

2. 分散式UX团队

这种模型,没有一个专业的需要向UX经理汇报的用户体验团队,而是将单个UX团队成员嵌入整个组织中的多个团队中,与特定的功能、产品或业务线保持一致。

产品经理,产品经理网站

在分散式UX团队中,UX直接向产品团队输出内容。产品团队有自身预算,包含UX工作的预算。

这种模式通常是用户体验团队在传统的企业或初创企业(非设计机构和用户体验咨询公司)中起步的模式。这种分散模型通常被描述为“分布式”或“嵌入式”团队,或者有时被称为“挂靠”。

1)分散式UX团队通常的工作方式

各个UX员工分布在各个团队中。每个产品团队都有预算,而用户体验工作直接来自该预算。

随着时间的推移,各个UX专业人员与相同的开发人员、产品经理和其他团队成员合作,团队的需求讨论、活动、会议等步调始终保持一致。

2)分散式UX团队的优势

分散式UX团队的许多优势直接抵消了集中式UX团队的弊端。

增强的信任度和机会:

因为每个UX都是产品团队的一部分,所以这些UX专业人士可以与他们的产品团队成员建立信任。UX能够成为其工作的产品或业务领域的专家(由于长期的接触和专注),因此他们的价值可以很容易地被其他团队成员(他们也是该产品的专家)所认可。

UX参与的可能性增大:

在分散模型中,UX团队成员与团队其他成员一样参与相同的讨论,活动和会议。在办公室中,与产品团队成员坐在一起时,UX人员将更加明显。因此,UX可以更多的参与到工作流中,从而提供贡献和证明价值的机会。

经理的责任感:

负责UX人员的直属经理可能会比属于其他团队(如集中式UX团队)的UX人员工作更加努力,以确保并推动UX成功。

3)分散式UX团队的弊端

UX的数量可能会很多:

特别是如果企业(或团队)的对UX的认知度较低时,分散的UX专业人员可能会在出现分歧时难以与许多开发人员和团队的其他成员抗衡。一个或两个UX团队成员的异议很容易被忽略。

设计和研究的时间很少:

UX人员人数过多时,他们可能会花费大量时间来推广、说服和传达给其他团队成员UX的价值。尤其是当UX未完全集成到开发流程中时,尝试将UX插入流程中所花费的精力可能会花费UX人员的大部分时间,而几乎没有时间进行研究和设计!

冗余的用户体验工作:

与集中式模型正好相反,分散的用户体验人员很难定期进行互通和共享资源。尤其是在缺少集中式系统模式、UX框架或研究见解存储的情况下,由于缺乏一致性和协作性,会存在大量的工作浪费和重复。UX专业人员将从头开始创建可交付的成果、研究计划或设计元素,而不是利用现有资源。

没有流程改进:

由于没有指定的UX管理人员负责公司的整体UX工作,因此没有人负责寻求不断提高UX工作质量和生产力的方法。

3. 矩阵UX团队

矩阵UX团队模型是集中式模型和分散式模型的结合体。

在这个模式下,UX人员既要向集中的UX经理汇报,也要向项目团队汇报(其中一个管理者具有优先权,因此比另一个管理者具有更高的权重)。

因此,UX团队成员由特定负责用户体验的领导和单个项目团队领导共同进行管辖。

产品经理,产品经理网站

集中式和分散式UX模型的结合体是矩阵式UX团队。

1)矩阵UX团队通常的工作方式

在矩阵UX团队模型的常见实例中,UX人员分布在许多团队中,他们在其中充当长期资源和团队成员。

根据组织结构的不同,他们的团队可能会适应特定的功能、产品、领域或业务范围。

日常指导由产品团队负责人负责,但是,UX经理也会从职业发展和个人成长的角度进行负责。通常,UX团队会议之间会保留各个UX团队成员之间的沟通协调和协作,例如设计评审或实践社区。

此外,UX经理可能会监督少量的未分配给产品团队的人员,负责公司范围内的计划,例如创建设计标准或运行可用性实验室,用于给负责每种产品的UX人员进行相应的产品设计测试。

2)矩阵UX团队的优势

对UX的双重关注:

在矩阵模型中,UX经理和产品团队负责人同时对UX人员进行监督。因此,两名负责人需要对UX人员的成功负责,从而对用户体验负责。

建立真正合作关系的可能性很高:

由于UX专业人员与单个产品团队长期合作,因此其他产品团队成员可能会将UX员工视为他们团队的真正组成部分,共同参与关键的讨论、会议和活动。

增加灵活性:

矩阵UX团队比严格的集中式或分散式的团队更灵活,因此可以轻松适应不断变化的组织压力或短期、紧迫的需求。

3)矩阵UX团队的弊端

UX人员的困惑:

由于用户体验人员以某种方式向两位负责人汇报,他们可能会感到被拉向两个不同的方向,不确定哪个负责人在设计方向上拥有最终的决定权,谁来处理人事或团队问题,或者谁来谈论职业目标。

难以实施:

在需要各种相互对齐的大型组织中,矩阵模型可能难以操作。然而,在有多个产品团队的组织中,只要UX团队领导和产品团队领导与他们的UX目标同步,矩阵UX模型就可以结合集中式和分散式的优势。

二、选择哪种模型更适合?

我们并没有绝对的说法哪种模型更合适,并没有最佳模型。

总体企业/公司环境(例如,公司规模、产品复杂性、UX团队的能力与组织需求相比)应决定采用哪一种模型。

通常,设计机构中的新生团队始于集中式模型。在团队成立之初,通常没有足够的设计和研究人员来支持分散模型。随着UX员工人数的增加(通常与对技能的需求增加相关),团队可能会演变为分散模式,因为现在有足够的UX人员和UX专业知识以固定的方式分布在各个团队之间。

相反,内部产品组织通常从分散的团队开始。由于认识到对UX的需求,因此各个团队都可以雇用UX角色。随着个人价值的实现,其他团队开始寻求UX角色的支持。最终,可能会批准其他角色的人员编制和预算。随着UX员工人数的增加,UX团队成员通常开始领导并建议一个集中的团队,以提高效率和知识共享的优势。

经过一段时间的学习和教训,许多组织(代理商和内部产品组织)最终都采用了矩阵模型。通过这种灵活的混合方法,组织可以平衡UX和产品团队之间的长期合作关系,而又需要在核心UX团队之间保持协作和一致性。

在确定哪种模型最适合您的团队时,请考虑以下因素:

现有流程:

团队当前使用的流程中是否包括UX流程?

如果没有,用户体验对任何人来说都是困难的,并且对于分散模型中产品团队中的单个UX人员来说尤其困难。缺乏支持和资源意味着此人将花费大量时间试图说服团队做用户体验工作。

与产品和产品团队数量相比,用户体验团队的规模:

是否有足够的UX人员致力于单个产品团队?或者,是否需要按项目进行优先级排序?如果分散式的模型是合适的,但是产品或产品团队比UX人员更多,那么哪个团队将有UX人员,而哪个团队没有?我们能够客观地一致地做出判断吗?

工作量:

是否有足够的需求在各个产品团队中使用UX专业知识来证明用户体验的合理性?或者,分散的UX团队成员会发现自己坐在那里无所事事,希望可以为需要他们技能的工作做出贡献。

UX的成熟度和文化:

分散式UX员工的专业知识和见解是否会像单个产品团队的其他成员一样有价值?UX人员之外的其他人员,是否对用户体验知识有相应的了解。

协作机会:

如果UX团队以分散模式分布,那么如何在UX团队之间实现协作和资源共享?可以安排哪些会议、讨论、活动等来确保能相互保持一致?

三、总结

下表总结了这三种UX团队模型的优缺点:

产品经理,产品经理网站

 

原文地址:https://www.nngroup.com/articles/ux-team-models/

原文作者:凯特·卡普兰、卡拉·珀妮斯

本文作者 @Henry-Lee

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部