敏捷与用户体验：失败的“婚姻”？

Behance / 2023年6月2日

设计理论 109 0 0

这篇文章分析了用户体验和设计（UX）与敏捷软件开发模型/哲学的整合或试图整合的情况。它认为，尽管有一些尝试在两者之间取得平衡，但敏捷和用户体验设计之间富有成效的整合仍然是顽固的，真正成功的例子有限。它是基于我作为用户体验/设计领导者和管理科学家的个人经验，并不代表我的组织。最后，我将写一篇后续的文章来帮助拯救这段婚姻；它将探讨如何克服这些挑战，最终建立和扩展一个有效的UX/D组织。

还有一篇关于敏捷和用户体验的文章？

这篇文章是基于十多年来与全球顶级企业在不同领域、国家和成熟度方面的经验。它为用户体验从业者和敏捷交付团队在软件/产品开发领域所面临的挑战提供了一个真实的世界观。它在三个基本原则的基础上进行识别和操作：

敏捷和用户体验没有什么共同之处；前者是一种开发哲学，后者是一个领域。
将用户体验融入敏捷交付过程是一种需要，而不是一种选择。
敏捷的领导者通常不是来自用户体验（设计或研究）的背景。

可能有一些敏捷和用户体验做得好的例子，所以这篇文章既不是对敏捷和用户体验应用的详尽研究，也不是万能药。它利用作者作为该领域用户体验领导者的观点来确定根深蒂固的挑战，并谨慎地提供一些建议，以帮助更好地实现敏捷组织中用户体验团队的潜力。

我还想强调的是，本文总体上侧重于在较大的、传统的、缓慢的组织中实施敏捷开发模式，特别是那些正在进行转型的组织（通常已经实施了补充系统，如章节模式）。

什么是Agile开发？

试图就敏捷是什么（或意味着是什么）建立共识是徒劳的。简单回顾一下关于敏捷的大量内容，就会发现它：

是一种软件开发的方法/理念
重视交付/速度而非完美
接受变化是一种常态，并寻求对其作出回应
建议由产品负责人领导的小型、有权力的团队

我继续写这篇文章时，假设你了解敏捷，因为它往往存在于现代公司中，并且参与过或至少听说过流行的Scrum框架（通常与敏捷同义），以及构成Scrum的典型仪式（Backlog grooming、Spring planning、Standups和Retrospectives）。如果你不熟悉敏捷，或者想进一步了解这个主题，我在本文的末尾推荐了一些阅读材料。

敏捷的必要性

敏捷方法由一群软件开发人员在2001年创建，它帮助项目团队在快速变化或不可预测的环境中快速实现目标，现在正被广泛用于整个组织。但是，做敏捷和做敏捷是两件不同的事情。

到现在，大多数企业，不管是新的还是旧的，都已经熟悉了Agile。虽然较新的企业，如Atlassian、Uber或Airbnb是天生的敏捷，但其他企业，如亚马逊、澳大利亚电信和主要银行都在经历敏捷转型。规模化实施敏捷的挑战，尤其是对那些并非天生敏捷的公司来说，是一个奇特的挑战，我建议阅读这篇HBR文章，它对如何实现这种规模化提出了平衡的观点。

我认为，敏捷是在需求、环境和技术变化的挫折中诞生的。在敏捷之前的世界里（你可以认为是瀑布，但它比瀑布更广泛一些），公司试图在建造/投资之前充分了解事物。这就造成了一些问题，往往意味着当 “需求 “明确时，已经太晚了。正是这种不断追赶的挫折感导致了理念的改变，最终形成了敏捷。我对它的看法是：

敏捷是对我们永远无法知道足够多的信息（以做出正确的决定）这一事实的一种认命。

什么是用户体验？

冒着自我宣传的风险，我建议阅读我的文章《用户体验金字塔》，以了解用户体验和设计的领域。我试图提供一个框架，帮助用户体验作为一个领域的概念化，并帮助把用户体验的各个层面结合起来。简单的回顾一下也无妨。用户体验，正如它今天存在的那样，是一个处理用户和技术之间的交互设计的领域，基于对用户的需求、背景、挑战和最终目标的理解。同样，让我强调，我对 “用户体验就是一切 “或 “用户体验就是解决问题 “等概括性的说法保持清醒，这些说法虽然不是不真实，但却不是有用的定义。因此，在这篇文章中，我是在比一些人认为的更窄的意义上看待用户体验的。

用户体验的领域已经经历了快速的转变。许多专业，如用户界面（UI）设计，用户体验研究，交互设计和服务设计已经出现了。即使是经验丰富的用户体验专家也很难跟上这些变化，以至于我们仍然无法达成共同的理解。这是用户体验和敏捷结合的主要挑战之一；用户体验专家本身不能就用户体验的含义达成共识；因此，敏捷的领导者，如Scrum大师或产品所有者，几乎不可能清晰地掌握它。

在大多数情况下，用户体验设计师（为了简单起见，我们假设用户体验研究员+设计师）在一个刻板的公司中的工作是接受来自业务的输入，加上对用户、设计基础的理解，最好还有系统/技术，并提出一些东西将如何工作/被终端用户使用。很少有公司从一开始就由一群用户体验设计师来设计产品；我们中的大多数人都会花时间来构建或改进现有产品的功能（尽管很多人声称自己是产品设计师，但根据我的经验，这只是UI/UX设计师的一个假名）。

例如，当我在Atlassian工作的时候，这是一家知名的软件巨头，制造了流行的Jira和Confluence产品套件，我负责Confluence的管理员体验。基本上，这意味着我们试图与产品经理和技术负责人一起，为Confluence管理员设计用户界面，因为新功能正在被添加到产品中（因此需要管理）。我们对这些功能的内容几乎没有发言权，这种功能我们可以称之为战略用户体验（告知效用而不仅仅是可用性）。用户体验从业者很少从头开始设计东西，当他们这样做的时候，敏捷决定了新产品的开发要循序渐进。那么，你能渐进地设计吗？

典型的软件开发过程

敏捷提倡现在无处不在的增量开发理念，它限制了风险，并最大限度地增加了学习和转向的机会。虽然这个想法在概念上似乎是正确的，但现实往往是非常不同的。

在典型的遵循敏捷开发模式的现代公司中，一个工作项目通常以企业领导想要追求的某些主题开始。把一个主题看作是一个广泛的想法，当它被细化时，会产生一系列潜在的项目，或称为路线图项目。如何决定这些项目并确定其优先次序是一个单独的讨论，同样，在我对用户体验的狭义定义中，用户体验师在这个过程中扮演的角色是有限的，尽管有些人可能想更多地参与。

一个案例研究

让我们用一个电信公司的例子来继续这个讨论。想象一下，你是负责后付费移动产品组合的产品经理。你想为现有客户提供一个新的国际漫游服务，以取代客户可以用来进行国际漫游的旧的、笨重的系统。我们将跳过你认为这是一个好主意的原因；让我们假设它是一个。这可以被认为是一个主题。它可以根据用户如何使用它（即购买、使用和管理国际漫游通行证），以及为新产品提供动力的几个后端功能，分解成各种功能。我们如何从这个高水平的主题到详细的用户体验？这就是应该发生的事情与真正发生的事情开始出现分歧的地方。

应该发生什么

应该发生的是，在一个合作过程的基础上，创建一个最终的客户愿景，通常由一个服务设计师或战略用户体验设计师来制作。客户旅程图是一个非常简单的想法：一个说明你的客户在与你的公司打交道的过程中所经历的步骤的图表，无论是产品、在线体验、零售体验、还是服务，或者任何组合。这个旅程图解释了客户可能有的与主题（国际漫游）有关的那种潜在体验。就你的主题而言，旅程图（或类似的人工制品，如服务蓝图）可能包括客户与国际漫游互动的阶段，以及这些阶段将支持的一系列任务（基于，比方说，待完成的工作框架），然后转化为功能需求。

在这个阶段，要求是高水平的，也就是说，产品的定义/结构会出现。例如，国际漫游主题的一些要求可能是：

能够在70个国家使用，分为3个区，每个区都有一个收费结构的关系。
能够购买7天、14天和30天的相应使用/数据包。
能够对某些数据包进行促销活动。
能够随时取消，并按比例退款。

这些高层次的需求描述的是什么，而不是如何。我想强调的是，这些需求对于技术团队估计或建立功能来说是不够的。从这里开始，用户体验的定义过程就开始了，遵循着

以用户为中心的设计过程：与用户共情，定义痛点，构思解决方案，创建线框和原型，测试和迭代设计。通过这个过程，更详细的需求出现了，这种需求定义了用户体验，开发者和关注技术/交付的产品负责人（PO）所关心的，并实际确定了可行性，例如：：

用户将能够按名称或按地区搜索国家。默认视图将是区域性的。
价格将按单个国家和地区显示。如果你选择购买多个套餐，但在大多数情况下，按预先定义的区域购买会有更好的经济意义，我们会通知用户。
用户将能够在 “我的服务 “下查看他们活跃的漫游包（想象一下这是一个现有的视图）。漫游包将显示价格、用量和到期信息。如果a.他们的使用余额快用完了，或者b.他们还有两天就到期了，用户将能够更新他们的套餐。
将会有一个新的部分来显示可用的促销活动。根据用户的购买历史，某些促销活动可以被优先考虑并优先显示。

虽然这些都是想象中的细节，但你可以看到在业务需求中出现了多少功能和用户体验方面的细节。当交互设计被充实后，更多的细节会出现，然后会通过可用性测试来完善。

并非所有这些出现的需求都会被优先考虑，以确定哪些工具可以被利用，如用户故事图，但原则上，在将交付计划分解成一个优先列表，导致最小可行产品（MVP）之前，你想从设想的体验向后工作。

通常会发生什么

使用上一节中的同一个例子，企业确定需要为其客户提供国际漫游服务。他们想知道在时间/能源方面 “将花费多少”。在技术公司的背景下，企业高管需要依靠他们的技术人员来帮助计算成本和交付估算，通常是软件架构师，他们参与其中并试图找出解决方案，这将告知粗略的’成本’。在这个阶段，没有各种类型的专业设计人员参与进来（我接下来会写一个主题）。问题是，如果没有详细的需求，这些估计只是猜测，更糟糕的是，当用户体验设计师最终定义和完善详细的需求时，被定义的 “解决方案 “往往会成为一种限制因素。在考虑到系统的复杂性、构建估计和交付团队的速度的情况下，创建一个交付日期和时间表。如果确定了优先级（基于这些估计），工作就会被移交给一个PO和他们的团队（或多个PO），他们开始在冲刺阶段计划工作。此外，PO和他们的团队经常根据这些承诺获得资金。

因此，团队不是从客户的体验开始倒退，而是从交付日期和能力计划开始倒退。

然后，工作被分解成用户故事，通常由业务分析员来完成。例子可能包括一个寻找国际漫游通行证的故事，另一个是比较的故事，另一个是添加到购物车/购买的故事。这时用户体验设计师往往会参与进来，正如你可能猜到的那样，他们现在只剩下一项具体的工作：”设计添加到购物车的体验”。如果用户体验设计师试图为这个新的漫游包进行实际研究并设计最佳的添加到购物车的体验，他们往往会面临反驳，并被要求利用现有的组件，”因为没有足够的时间来建立新的组件”。同样，如果用户体验设计师设计一个搜索体验，使用户更容易找到对漫游包感兴趣的国家，他们会被告知，我们没有能力支持搜索体验（我们也没有时间/金钱/授权来建立一个）。如果用户体验设计师推动新的东西，PO会认为这是 “范围蠕变”。根据我的经验，这是一个典型的敏捷和用户体验紧张点。为了反驳这一点，我认为：

用户体验不会增加范围。用户体验有助于定义和细化范围，然后，可以优先考虑并逐步交付。定义和完善细节，通常需要新的能力，是用户体验的特权；然而，选择建立什么和何时建立，则不是。

因此，在这种情况下，用户体验已经被时间和现有技术所限制而实际定义了，用户体验设计师所能提供的附加值非常少。而这一切，令人沮丧的是，都被包装成了敏捷，它假定体验（+功能）将被反复改进。这在纸面上听起来不错，但有两个问题：

如果你一开始就没有设想到最终的用户体验（尽可能的），你将很难进行迭代构建，因为基础架构的设计/构建方式往往不允许这种增量的增加。你会被困在一个优化陷阱中。
更多的时候，MVP会变成我开玩笑说的实际上的最后一个版本（PLR），因为优先级改变了，团队会继续做别的事情。

在这个简单的案例研究中，包含了一些挑战，我在下一节中讨论。

基本的挑战–基于经验

该案例研究试图强调软件开发过程在许多组织中通常是如何运作的，包括我曾经工作过的几个组织，并解释了UX设计师在将一个新功能/建议付诸实施的过程中所扮演的有限角色。本节阐述了这些挑战，并解释了为什么这些挑战会导致糟糕的用户体验，而这些体验往往无法得到解决。

哲学

敏捷哲学，正如我所论证和举例的那样，是基于这样一个前提：产品最好是逐步建立和发布。虽然这种方法没有错，特别是如果以合理的方式部署，但它与用户体验设计的基本理念不同。用户体验追求的是整体性。用户体验专家的工作是通过数字媒介在用户的需求和系统的能力之间架起一座复杂的桥梁。用户体验，就其本身的定义而言，寻求设想和连接。我对那些了解这两个领域的人的问题是：你如何逐步设想一种体验？

我认为，你不能也不应该这样做。从史蒂夫-乔布斯到杰夫-贝索斯，他们都强调需要从客户体验出发进行逆向工作；也就是说，先设想解决客户需求的最终状态，然后再想办法实现它，这当然可以是渐进式的。虽然敏捷在理论上并不妨碍这一点，但大多数组织的设置方式是，用户体验团队只有在工作被定义和承诺后才会参与。

组织设计

用户体验团队在敏捷组织中应该处于什么位置？我曾与一些公司合作，他们在工程/技术、产品、客户体验、数字，甚至是他们自己的垂直领域工作。例如，较新的公司倾向于将其与工程捆绑在一起（因此设计师往往是帮助前端开发人员编码的UI设计师），而较成熟的公司可能会将其放在产品或独立的机构中。

挑战在于以下几点。大多数敏捷的公司都倾向于有跨职能的任务团队，为一个产品或功能工作。在案例研究中，我们看到有两个不同的团队：第一是业务和架构组，第二是PO和他们的敏捷交付团队。在这个看似简单的结构背后，隐藏着更多的复杂性。例如，虽然UX团队与PO和他们的团队一起工作（他们只有在工作定义和优先级确定后才开始行动），但他们有一个角色，可以说是帮助业务和解决方案架构师理解将出现的那种体验的一个基本角色（因此在估计时间/投资时应该考虑）。

即使他们在会议上有一席之地，谁来决定他们是否应该把时间投入到 “没有被优先考虑 “的事情上？用户体验经理？敏捷的PO？还是其他什么人。此外，在许多较新的、扁平化的组织中，当涉及到这种决定时，UX经理的作用是有限的（与亚马逊这样的公司相比，他们确实有发言权），因为那是PO的特权，PO没有动力参与（无论是直接还是通过他们的代理人）到定义过程中，除非它被优先考虑和承诺。

因此，由于是PO团队的一部分，UXer影响早期阶段思考的能力被削弱了，这反过来又导致了不恰当的业务需求的定义，这些需求现在是神圣不可侵犯的，因为已经承诺的交付时间表。我见过一些公司在流程的早期增加服务设计师来应对这种情况，但这导致了更多的孤岛和进一步的忠诚度分裂。

确定优先次序的来源

即使遵循以用户为中心的设想过程，正如案例研究中所提到的，这将导致一系列的人工制品（高水平的旅程图，更详细的线框图和交互流），关键功能的优先级（松散的用户故事，为特定功能提供动力）是困难的，敏捷对这个挑战的解决方案是MVP的概念。然而，在大多数情况下，PO是在一系列的限制条件下工作的（技术和财务），并试图满足交付期限，将东西推出门外。根据我的经验，功能的优先级几乎总是基于可行性，很少或根本不考虑任何用户研究或可能表明的其他情况。

范围/要求

业务需求和详细的用户需求（因此称为用户故事）之间有一个根本的区别，后者是基于事情如何运作。用户体验应该在定义事物如何工作方面发挥主要作用（当然，在合理的范围内，熟练的用户体验设计师也应该理解总体的约束，而不是无赖地运行）。然而，我经常看到POs采取高层次的业务需求，查看现有的能力，并为这些需求制定最短的路线，而不允许探索可能的功能，以获得最佳的用户体验。

这意味着用户体验设计师往往是在为PO想要的或已经承诺的用户体验进行改造。把这看作是事实上的设计–在没有设计师的情况下出现的设计–实际上是指PO寻求一个最终的UI工件，以便前端工程师有规格来构建。他们（和我们中的许多人）不明白的是，UX处理的是功能–从用户的角度看事物是如何工作的，而不仅仅是它们看起来如何。当你定义事物如何工作时（如案例研究中搜索国家的能力），你就在定义，或至少是进一步完善需求。

敏捷的整个理念是，需求永远不会是明确的。我发现很多时候，PO使用业务需求（+他们自己对细节的看法）来交付任何可行的东西，另一方面，使用敏捷和它的哲学来反击UX工作，争论MVP的价值，并将任何额外的功能定义反驳为范围蠕变，范围是他们经常根据我们讨论的约束条件任意决定的。

在这种情况下，我们真的应该指出问题的所在。我的建议是：

当需求明确时，机械化的过程比仅仅称其为敏捷的东西要好。如果你知道你想建立什么，以及它将如何为用户工作，你就不需要用户体验设计师，因为你事实上已经定义了用户体验。

衡量和奖励

敏捷的一个基本组成部分是测试和学习。然而，这在实践中说起来容易做起来难，我很同情那些不得不不断调整优先级并转向下一件大事的PO们。这意味着在实践中，无论是产品还是设计，都是以 “MVP/测试和学习 “的方式发布的，但文化、优先级、资源和能力等组织因素抑制了PO的能力，使其无法有效地做到这一点。关于这个话题，我推荐HBR的这篇文章，以了解组织在做出让客户满意的决定时所面临的挑战。

此外，大型组织中还存在多种类型的PO。例如，在我以前的一个组织中，有一个业务PO（坐在产品垂直领域内），一个数字PO（实际上是在数字背景下帮助交付主题的人，因为一项工作可能不限于数字渠道），一个体验负责人（EO），负责确保多个相互关联的客户旅程从长远来看是有意义的，还有技术PO，他们实际上负责管理敏捷交付团队。但是谁负责测量和测试MVP所要评估的假设呢？如果你说，每个人，那么它真的意味着没有人。

我发现敏捷的观点，即以PO为中心的跨职能团队，是过于简单化的，在更大的组织中会被打破。用户体验设计师的挣扎因这种复杂性而加剧。他们最接近TPO（因为他们往往是敏捷团队的一部分），但正如前面所讨论的，他们的影响应该是在TPO参与或感兴趣之前的一个阶段。

严谨的态度

敏捷的测试和学习、迭代方法的一个相关挑战是，它在计划和交付过程中假定了很大程度的严格性。这将需要设想用户的体验，向后工作以培养功能，绘制用户故事，并决定发布时间表。在这个过程中，UX设计师和PO将需要勤奋地捕捉假设或假定，并寻求主要数据来澄清，或在生产中设计一个测试，作为下一个版本的一部分，并承诺在随后的版本中改变产品，如果结果指向那个方向。

然而，PO的路线图总是被超额认购，除非有什么东西坏了，否则我很少看到在现实世界中持续测试和透视实施所需的严谨和纪律。严谨性的缺乏并不归咎于POs；UX设计师，即使适当地嵌入到一个组织中，也并不总是有必要的技能来明智地发现他们自己研究中的差距，并与POs合作，以减轻由此产生的风险或通过生产中的测试进一步调查。此外，至少在澳大利亚，设计师在一个组织中的职业生涯是短暂的，这阻碍了他们真正理解用户的需求和行为的能力，以及组织的压力。

用户体验规划

组织设计和测量的一个相互关联的挑战是用户体验规划。根据一个组织的结构，用户体验团队可能 “坐在 “一个区域或另一个区域中。然而，我从未见过用户体验以这样的方式整合，即团队中的用户体验资源与敏捷团队的其他成员，如开发人员或测试人员，是同一个规划过程的一部分。基于我的整体前提，有人可能会提出这样的理由：UXer不应该受到同样的规划（以故事点来衡量），也许类似于团队中的商业分析师或解决方案设计师，但UI设计师当然应该？

各种各样的方法，最常见的是在开发冲刺前几周进行设计冲刺，已经被尝试过。然而，我认为这些方法并不奏效，原因有二：

谁拥有设计冲刺缺乏明确性。在敏捷团队中，Scrum Master和PO负责冲刺计划，但当设计冲刺单独存在时，在大多数情况下，Scrum Master或PO对接手另一组活动的计划没有兴趣，最终，当涉及到可用的团队能力时，这些活动并没有被衡量（如反映在消耗表上）。
用户体验能力没有被作为团队交付能力的一部分来衡量，这意味着用户体验成为某种不相干的、好的活动，没有这种活动不会导致风险或成为交付的障碍（在狭义的交付意义上）。

谁拥有设计冲刺缺乏明确性。在敏捷团队中，Scrum Master和PO负责冲刺计划，但当设计冲刺单独存在时，在大多数情况下，Scrum Master或PO对接手另一组活动的计划没有兴趣，最终，当涉及到可用的团队能力时，这些活动并没有被衡量（如反映在消耗表上）。
用户体验能力没有被作为团队交付能力的一部分来衡量，这意味着用户体验成为某种不相干的、好的活动，没有这种活动不会导致风险或成为交付的障碍（在狭义的交付意义上）。

战略性用户体验的空间

当用户体验至少在名义上是由PO领导的敏捷团队的一部分时，他们在更多的战略层面上影响工作的能力，通常是在上游，比敏捷团队的其他成员参与得更早，这一点被严重地限制了。我们在案例研究中看到，当用户体验设计师开始探索设计方案并定义 “国际漫游如何与移动应用用户相关 “时，已经太晚了，现有的机制阻止了任何有意义的探索和推动在承诺的时间范围内交付的东西。

除了对用户体验质量的明显影响外，这也有一个更隐蔽的影响，那就是打击用户体验团队的士气，因为他们最终会觉得他们被要求移动像素并帮助可视化一个已经定义的用户体验。这不是一个有能力的UX团队或设计师所能带来的，虽然有些人可能会戴上UI的帽子，但那是一种奖励。我把在 “设计光谱 “上不断向左推进归结为这个问题，视觉设计师想做 “更多的UI”，UI设计师想做 “更多的UX”，UX设计师想做 “更多的服务设计”，服务设计师想做 “更多的CX”。在这些愿望中，包含了对像素以外的东西的渴望。

PO的作用

在大型组织中，正如前面所指出的，敏捷所设想的包罗万象的PO角色并不存在。有多个PO、PM、TPO、DPO、BPO。每个人都是一个PO，每个人都对整个CX有发言权。虽然CX应该是每个人都关心的问题，但缺乏明确的责任会给UX设计师带来很多挑战。在专注于交付的敏捷团队中，我遇到过PO（基本上是TPO，他们的任务是交付已经定义好的东西）对用户体验研究或用户体验驱动的范围定义进行反击，当涉及到什么对客户有价值时，往往依靠 “PO的特权 “来做决定。

同样，这种方法的问题是，当涉及到定义需求时，TPO依靠业务部门把它们交给他们/他们的团队，但如果UX设计师（通常是他们团队的一部分）试图为功能增加任何严肃的投入，他们会退回到作为PO的发号施令（并有效地阻止任何此类活动）。大多数这样专注于交付的PO经常与用户和使用环境脱节，而这正是一个合适的PO应该致力于做的事情。作为一个思想实验，问问你的专注于交付的PO，他们最后一次参与初级用户研究是什么时候，甚至更好的是，为它做宣传（而不是像 “我们应该做一些快速和肮脏的测试；好的研究也不是！”这样政治上方便的问话）。