在过去的几年里,我们遇到了许多不清楚任务或交付品是产品管理(PM)还是用户体验(UX)的责任的案例。作为用户体验者,我们经常认为用户体验角色的定义不够好,无法被用户体验专业人士或产品开发人员理解,这导致了对职责的误解。我们也听到我们的PM朋友抱怨用户体验工作的模糊性,以及用户体验专家是如何做PM的职责。
为了了解用户体验专家和产品经理如何看待他们的角色,以及角色之间的关系,我们进行了一项调查,看看pm和UXers对谁应该负责与这些职业相关的各种常见活动的期望。正如你将在详细的数据图表中看到的,我们发现很多UX和PM专业人员在谁应该做什么上存在分歧。或者,对于我们的发现的总结,你总是可以直接跳到结论.
我们的研究
我们对UX和PM专业人士的调查旨在回答以下问题:
- 其他角色是否超越了PM和UX的工作,如果是,频率是多少?
- 哪个角色与PM和UX重叠?
- 为什么会出现重复工作?
- 工作重叠的影响是什么?
- DO PM和UX认为谁负责哪种活动和可交付成果?
- 谁在这个组织中掌权?
本文将讨论最后两个问题。一个同伴的文章涵盖前四项。
本文中的分析来自372个来自专业人士的反馈,他们描述了自己在UX(279人)或PM(93人)中的主要角色。整个调查包括了500多份回复,这些回复来自于在产品开发中从事不同工作的人。
大多数受访者(60%)在PM或UX地区工作了3-10年,21%不到两年,而且超过10年的19%。
大多数受访者(54%)来自美国;第二大群体(27%)来自欧洲。
pm和ux在“谁该负责什么”的问题上不一致
我们问我们的受访者,他们认为谁应该负责几个经常做的活动,与用户体验和PM:
调查问题:许多事情是作为一个团队合作的。但对于许多活动和可交付成果,有人有“最终说”或最负责任。对于以下每个活动,您认为哪种角色应该是最负责任的?角色:内容,CX,开发,营销,产品管理,产品所有者,QA,支持,UX等。活动:
- 行为发现
- 进行用户访谈
- 进行用户测试
- 想象,并确保团队传播,在新的设计理念上
- 在设计中优先考虑用户需求
- 定义IA(信息架构)
- 在UI中定义任务流
- 在非常早期的设计阶段的线框或绘制UI流量
- 使UI原型
- 决定一个设计的外观和感觉
- 在UI中创建最终视觉效果
- 确定UX团队将研究哪些领域
- 决定UX团队将设计哪些特性
- 确定哪些内容进入UI
- 确保用户研究和响应发现是路线图的一部分
- 将客户的意见传达给产品团队
- 解释领导的设计
- 从涉众那里获得设计的支持
- 收集项目的业务(执行领导)需求
- 创建产品愿景
- 商业需求的优先级
- 确定产品需求
- 确保项目满足业务需求
- 创建产品路线图
- 决定哪些特性将最终出现在产品中
- 决定开发人员将编写哪些特性
- 维护产品待办事项列表
- 优先考虑客户需求
- 跟踪项目进度,确保项目按时完成
- 估计产品或服务是否会符合收入目标
- 了解产品的竞争位置
- 在内部和外部支持产品
- 向领导层报告产品状态
我们进行了统计测试,以了解对于每个活动,在用户体验和PM受访者之间,在将该活动归因到某个角色上是否存在显著差异。在下文中,除非另有说明,所有讨论的差异均具有统计学意义(p <0.05)。
UX相关任务
PM和UX没有就谁应该负责以下关键的UX任务达成一致:
- 进行用户研究
- 设计工作
- 定义站点的信息架构(IA)
- 管理设计相关的工作
- 沟通设计和客户知识
- 决定的内容
进行研究
我们的结果显示,尽管大多数PM和UX回答都将用户访谈和用户测试分配给UX,但他们在这方面做的程度存在显著差异。最大的分歧与发现有关,但即使对于传统的用户体验任务,如用户测试,也存在显著差异,只有46%的pm认为这是用户体验活动。
用户体验被写到一个问题引起人们不擅长做研究:“用户体验的研究non-researchers往往不符合我们的质量或工艺标准,导致用户测试,发现,和建议不反映实际用户的行为和对产品造成负面影响。如果这些建议被付诸实施而失败了,那么我和研究团队已经或将要提供的积极工作就会被否定。”
需要明确的是,任何团队都不需要完全拥有任何研究方法——相反,方法可以被许多角色共享。然而,如果PM和UX在谁应该负责什么的问题上不一致,那么工作很可能会重复,会出现混乱,人们会感到不满意。
同样重要的是,所有角色中的人都要充分利用自己的技能,并对与这些技能相关的工作负责。用户体验被写他的团队是如何充分利用和如何传播误解和缺乏对用户体验:“我们大多数人觉得我们可以提供更多的价值和更满意我们的角色在实践中如果我们能够把所有这些会导致研究的技术解决方案,解决用户的需求。但由于我们不能这样做,其他利益相关者的看法不会也不会改变。”
设计工作
当涉及到设计工作时,我们发现用户体验和PM受访者之间既有一致的意见,也有不一致的意见。
协议。对于调查中以下3个与设计相关的任务,PM和UX一致认为它们应该由UX负责:
- 决定设计的外观和感觉(82%的pm和80%的uxer认为这应该是用户体验的责任)
- 制作UI原型(82%的pm和88%的uxer认为应该由UX来完成)
- 在UI中创建最终的视觉效果(79%的pm和78%的uxer将其分配给UX)
分歧。PM和UX都倾向于将以下活动分配给UX,但UX受访者比PM受访者做得更多:
- 意念
- 定义任务流
- 线框图和草图设计
- 优先考虑用户需求
特别是最大的分歧是在创意和设计中优先考虑用户需求:超过四分之三的用户体验受访者认为他们是用户体验的责任,但只有大约三分之一的PM受访者,另有三分之一的人把他们分配给PM。
设计应协同。UX,PM,发展以及大多数其他角色都应该绝对有助于设计。但调查问题是关于谁应该的负责任的, 不是涉及.如果不清楚谁负责设计活动,就很难推动和完成设计。
一位UX受访者的评论表达了人们对没有UX技能的人做设计的普遍看法:“我的老板,一个高级UX经理,总是说,‘每个人都是UXer。“想象一下,如果你是一名会计师、医生或首席执行官,然后有人这么说?”这种认为这个职位毫无意义的心态是对在这个领域工作多年的员工的不尊重。我认为这部分是因为UX是一个非常宽泛的术语,它为这种消极行为打开了一扇门。”
信息架构(IA)
PM和UX受访者也是在谁应该负责定义信息体系结构的问题上存在分歧的网站。大多数(50%)产品经理认为开发应该负责IA,只有27%的产品经理认为它应该是UX工作的一部分,而75%的uxer认为UX应该负责IA。
虽然代码架构当然是开发的强项,但在应用程序中创建信息的分类和层次结构是信息架构师的工作,这是一个UX角色。UX有能力学习-与方法就像卡片分类,树的测试,以及点击测试——如何以对用户有意义的方式放置和命名链接和命令。
管理设计相关的工作
PM和UX受访者对于谁应该管理设计工作也有不同的看法。一般来说,大部分(约50%)回应者认为这些管理活动应由项目管理人员负责.相反,UX受访者的观点则更加多样化,有些人把他们分配给UX,有些人分配给PM,有些人分配给产品所有者(PO)。有趣的是,在所有这些管理活动中,用户体验者(超过38%)最普遍的反应是用户体验应该做这些事情。一般来说,数据显示了用户体验和PM角色对与设计相关的适当管理工作的趋势.
决定用户体验团队将研究哪些领域是挪用的最明显的例子: uxer认为UX应该做,PM认为PM应该做。
很容易理解为什么Uxers和PMS在谁应该做这些活动时未对准:这些任务具有清晰的管理组件,也是一个明确的用户相关组件,所以根据定义,它们是模糊的。这就是为什么对于组织明确地消除不确定性并建立关于谁应该做这些活动的指导方针是非常重要的。这些是在软件开发过程中最艰难的决定,即使没有所有权问题。当被问及这些问题时,你几乎可以想象PM和UX人们指向所有不同方向。
沟通设计和客户知识
在这个领域,我们也在PM和UX之间发现了广泛的错位.用户体验调查对象也倾向于使用所有这些活动(至少49%的uxer将它们分配给UX),而pm对于谁应该做它们有更多不同的观点。
将客户的声音传达给产品团队是这类活动中pm被划分得最多的一些PM(25%)认为这应该是PM的工作,其他人(29%)认为这应该是CX的工作,16%的PM认为这应该分配给PO。只有9%的pm把它分配给UX(相比之下,54%的UX受访者)。
为the other 2 activities (explaining the design to leadership and getting buy-in for the design from stakeholders), we also saw appropriation from PM respondents: most PMs thought these activities should be the PM’s job (45% and 53%, respectively), but the next common PM response was that they should be UX’s job (29% and 23% respectively). These findings show the当涉及到谁应该负责时,用户体验和PM之间的脱节销售和解释设计.无论涉及的角色,除了设计师投球时都没有一个好主意 - 演示者可能无法正确理解每个决定背后的推理,并且可能无法准确地将反馈传达回设计人员。此外,这种情景(下PM向领导和利益相关者提供设计)从组织中可见的机会抢夺UX,从长远来看,可以降低UX角色,UX团队和UX的可信度和增长专业人士。
之间的关系CX和用户体验也有时候不清楚。这些部门最初是分开的,CX负责其他非焦互动和客户反馈。用更新残雪转换在今天的许多组织中,这些领域之间的区别变得模糊,非常清楚地定义和区分他们的职责是很重要的。
决定的内容
在由谁来决定内容的问题上,PM和UX也有些不一致:他们都倾向于将其归因于用户体验或内容人,但PM倾向于更多地归因于PM(23%的回复),而UX只在5%的情况下将其分配给PM。(PM和UX受访者将内容分配给不同角色的百分比之间的其他差异并不显著——例如,即使28%的PM和41%的UX将这个活动分配给UX,这种差异也不显著。)
就像设计屏幕和工作流程一样,决定内容也是一项很多人参与的活动相信几乎每个人都能做到。很多人确实会写,但大多数人写不好数字媒体。然而,关于谁拥有内容的分歧是次要的。
与管理项目相关的任务
PM和UX在谁应该负责以下与管理项目相关的关键任务上没有达成一致:
- 产品远景以及业务需求和产品特性的优先级
- 管理项目并测量结果
- 福音调整产品和团队的产出
- 理解竞争
产品愿景和优先级
大多数PM受访者(超过63%)认为,所有与愿景、业务需求和产品特性的优先级相关的任务都应该是他们的责任。相反,uxer通常被分成两部分,一是将这些任务分配给产品负责人,二是分配给产品经理。为所有这些任务,更多的PM受访者可能会把它们分配给PM用户体验调查。相比之下,更多的用户体验受访者倾向于将这些愿景和策略活动分配给产品所有者比点受访者——除了决定产品需求和决定哪些功能应该由开发,实现项目经理分配的百分比之间的差异在哪里,阿宝和用户体验的百分比分配给阿宝只是略微显著(分别为p = 0.054, p = 0.09)。
总体而言,尤克斯似乎没有明确了解产品所有者和产品经理在产品愿景和战略方面的不同责任,并且在整个组织中对这些角色的明确透明区别将受益于创造共同点。
在精益和敏捷变得流行起来,并引入了产品负责人的角色项目经理角色通常是软件工程经理,负责运行项目及其进度。程序经理也相当普遍,有更为普遍的行政角色,并照顾工作的工作。今天的产品主似乎似乎采取了(大多数)过去的项目和计划经理的任务,并成为敏捷仪式的托管人。但是,随着产品所有者的角色可能是如此之大,产品经理可能需要偶尔执行这些任务中的一些,这一重叠可能导致一些关于责任的混淆。
管理项目和测量结果
总的来说,尽管用户体验和PM受访者倾向于将以下任务分配给PM,但他们这样做的程度通常是不同的:
- 维护产品backlog:更多的PM比uxer更倾向于将产品backlog分配给PM,但是PM和uxer认为应该把backlog交给产品负责人的百分比之间的差异并没有统计学意义。
- 跟踪流程以确保准时交货:这个任务是唯一一个由uxer分配给PM的次数多于PM的任务。PM受访者的百分比和UX受访者认为应该将其转到PO的百分比之间的差异并不显著。
- 评估产品是否应该达到收入目标:尽管PM比ux更大的比例(59%比48%)将这项任务分配给PM,但这种差异在统计学上没有显著性(p >0.1)。然而,与pm相比,更多的uxer认为这项任务应该交给PO(这种差异在统计学上是显著的)。
- 确保项目符合业务需求:PM认为这个任务应该交给PM,但是UXers把它分配给PO。两种差异均具有统计学意义。
总的来说,在这个类别中最大的误解是关于谁应该确保项目满足业务需求。uxer更容易混淆PM和PO的属性。同样,PM和PO之间应该有一个明确的区别。
福音调整产品
项目经理受访者倾向于适当的活动在这一类别下,但uxer被划分为分配给PM或PO.总的来说,分配给PM任务的产品经理比分配给产品经理的多,分配给PO任务的产品经理比分配给产品经理的多。大多数用户体验反馈(41%)认为PO应该支持产品(与大多数PM反馈相反,他们将任务分配给PM)。虽然大多数PM和UX受访者都说报告产品状态应该由PM完成,但更多的PM分配给PM(72%对53%),更多的uxer分配给PO(40%对22%)。
竞争
PM和UX受访者对于谁应该研究产品竞争也有不同的理解。项目经理占用了这项任务,但是uxer被分配给项目经理、订单经理或市场营销人员。分配给PM的项目经理多于分配给PO的项目经理多于分配给PO的项目经理。将这项任务分配给市场营销的pm和uxer比例相当(21%对24%;差异无统计学意义,p > 0.1)。
权力的角色
权力的想法是相关的,因为如果他们选择这样做,那么强大的角色的那些人可能会影响或做那么强大的角色的工作,并且强大的角色可能无法对此做出多大效果。
为了理解UX和PM专业人士如何看待他们组织中的权力平衡,我们问了以下问题:
调查问题:以下哪个角色在你的组织中最有权力?请根据角色的影响力排序,1是最强大的,10是最不强大的。每个数字只能使用一次。
我们计算了每个角色的平均等级,由PM和UX分配。总的来说,两组受访者对所有角色的排名非常相似。唯一具有统计学意义的差异(通过wilcoxon秩检验,p <0.05)是产品负责人在PM中的排名比在UX中的排名要高.
产品开发的角色不是统一定义的
很有可能,一个被正式雇佣的人可能擅长并负责传统上由不同角色完成的任务。例如,一个初创公司可能有一个产品经理和开发人员,但没有UX人员。在这种情况下,所有的研究都可能由PM完成,设计可能在PM和开发人员之间进行分割。无论是初创公司还是成熟公司,产品开发角色在所有组织中都不会以相同的方式定义,所以我们的调查对象可能经历了我们问题中任务的不同分配。他们可能是根据自己的经验和想法来回答我们的调查的,即使可能存在更有效的任务分配。
近年来,一些开发团队将重点转向招聘技能而不是角色.一个团队技能的差距分析可能表明团队需要具有跨多个传统角色技能的人员。例如,团队不需要雇佣产品经理或视觉设计师,而是需要能够创造产品愿景或能够构建高保真原型的人。这种低粒度、以技能为重点的人员配置方法可能比传统的基于角色的方法更灵活。
对于个人来说,这意味着,无论他们的职称是什么,他们可能有机会改变他们在工作中所做的任务。掌握各种各样的任务可以令人满意,刺激员工的增长,帮助组织保留伟大的员工。
另一方面,这种工作类型也有消极的一面,比如:
- 小练习:有些人如果不经常练习一项技能,可能就无法完全掌握,所以他们的产出可能质量较低,需要更多的时间来完成。
- 缺乏认识:享受不是技能。仅仅因为人们津津乐道做某事或看到需要它并不意味着他们擅长它。似乎有很多人喜欢做UX工作。
- 失踪的专业知识:UX是如此微妙,以至于非UX人士很难知道UX工作什么时候做得好或不好。不会写代码的人是不会去做工程师的工作的。如果他们这样做了,他们也不会走多远。不了解业务目标和约束的人是不会创建产品待办事项列表的。如果他们这样做了,没人会遵循它。但是任何人都可以下载线框图工具并开始素描,或注册在线用户测试应用程序并启动一项研究。也许他们会做得很好。但他们往往不知道自己做了不合格的工作。这就是问题所在。尽管UX活动的入门成本很低,但缺乏经验或培训的人做好这些事情的可能性也很低。以及他们比a做得更好的可能性受过培训或有经验的UX专业人士甚至更低。
- 降低效率:组织可能有其他人可以更好地完成工作。例如,UXER可能能够进行研讨会并导出产品愿景,但PM可能会更彻底地做到并获得合适的高级利益相关者。PM可能能够勾勒出早期的设计流程,但有经验的用户体验人士会考虑设计原则利用他们之前收集的用户数据和知识。
- 困难的招聘:如果团队需要的技能是多种多样的,那么就很难找到拥有这种特殊技能集的人。
企业领导者需要在工作效率和激励和留住优秀员工之间取得平衡。松散的职位描述为个人的变化和成长留下了空间。但是,重复或低水平的工作是与未定义的角色相关的可能风险。如果明确了角色之间的界限,这些问题就可以得到缓解,这需要领导者和个人之间进行更多、更好的沟通。
总结:与个人在项目中的责任保持一致
每个组织都有自己的文化、工作角色和工作方式。许多人并没有被局限在传统上与他们的职位相关的少数活动中。然而,令人不安的是,pm和ux有非常不同的观点,在他们的评估中,谁应该负责与设计和管理项目相关的关键领域,并没有达成很多一致意见。事实上,几乎所有关于责任的反应都是不同的。
一些最大的误解围绕着研究,即谁应该进行发现,构思新的设计,并确定UI中的任务流程。决定用户体验应该做什么工作,比如用户体验团队将研究和设计哪些功能,也是一个错位点。沟通设计,如向领导解释设计和获得利益相关者的支持,是其他不一致的领域。
对于上述所有领域,pm认为他们应该负责,而ux则认为他们应该负责。这是一个有趣且清晰的挪用的例子,PM和UX倾向于相信一切都是他们的工作。
另一方面- PM任务和责任-用户体验受访者经常对产品管理和产品所有权之间的区别感到困惑,特别是对于产品愿景、业务需求和产品功能的优先级划分、宣传产品和团队的输出以及理解竞争等任务。
对于这种缺乏同步,该怎么办呢?我们可以推荐一个庞大的项目来标准化产品经理和每个用户体验角色的工作描述。但当我们完成了可以广泛应用的描述时,世界已经发生了变化,这些描述将不再起作用。这就像割草一样巨大的财产。当你完成的时候,你开始的地方的草已经很长了,你需要重新开始。
所以今天,在项目的早期阶段,pm和uxer应该真正同步研究和设计,并明确地说谁将做发现、创意、早期草图和设计工作流程。同步这些内容不仅可以缓解一些最大的痛点,还可以在项目开始时为沟通、授权和边界设置一个阶段。
在整个项目中,清楚地确定每个人应该完成的任务可以帮助人们在工作中表现出色并感到自信。每个人都应该知道他们在每个项目或项目的每个点上应该做什么。同样,产品团队的其他成员也应该知道这些职责。清晰的定义可能会增加职能小组之间的协作,消除“我必须做所有事情”的感觉。“如果每个人都知道该找谁做什么,和谁一起工作可能会更令人满意,生产率将会提高,结果也会改善。”
关于用户体验和产品角色如何协同工作,你有什么建议或故事吗?在这里分享.我们计划再写一篇建议汇编的文章。我们的课程,产品和用户体验:为更好的结果建立伙伴关系获得一个可适应的框架,以便在特定的项目和整个产品开发生命周期中校准和定义谁做什么。
分享这篇文章: