敏捷和用户体验之间的区别不在于数量与质量

我曾经和一些人合作过，他们声称自己既是开发者又是设计师，统一在同一个人身上。大多数人要么是涉足设计的开发者，要么是涉足开发的设计师，所以我完全可以理解当我自己宣称自己是那种半神话般的生物：设计师/开发者，数字产品创造世界的 “独角兽 “时，迎接我的怀疑。我们认为普遍化必须以牺牲专业化为代价，这是常识。我不同意，但我当然可以理解为什么这被视为一种既定事实–我承认确实有更多的例子对它有利而不是不利。

我为自己提出这个有争议的主张是为了提供一些背景。同时存在于两个圈子里让我确信，开发世界中最糟糕的事情就是设计世界中最糟糕的事情：我们在做不同的工作的错觉。我明白为什么我的设计师和开发人员的同事在我说这句话的时候都看着我，好像我突然长出了第二个脑袋。这显然是不同的工作，我怎么可能认为它不是呢？我今天只想集中讨论这个所谓的分工中的一个部分来说明我的意思，尽管这可能是在我们之间引起最多争执的部分：敏捷性。

最糟糕的电话游戏

在 “必须结束的敏捷时代”

迈克尔-伯内特

声称，敏捷性是以三个基本缺陷为前提的：

1. 人类不是机器。
2. 设计不是库存。
3. 产品不能被定义为由任意数量的具有任意技能和经验的人在两周的冲刺阶段所能完成的事情。

迈克尔对敏捷性的看法绝不是他一个人的。思考和书写我们的手艺的UX专业人员已经在反敏捷性的尖叫声中形成了一个流派。Dave Malouf在《DesignOps Handbook》的开篇，讲述了他自己在敏捷制度下的糟糕经历。他讲述了他在这种 “为工程师优化的文化 “中观察到的问题，并以此诊断了问题的根源：

我发现，我们在开发和产品管理方面的合作伙伴的成功指标与设计方面的指标不同，导致了不合格产品的出货。问题就出在这里：开发人员和产品经理用产品是否按时发货来衡量成功，而不是用设计是否满足用户需求来衡量。

最后一句话的重点是来自Dave本人，我基本上同意这个观点–尽管他的这个评估忽略了一个关键细节。

我所见过的对用户体验中的敏捷性的最好处理来自于

Jared M. Spool

(虽然我承认，我是Spool的忠实粉丝）在他的敏捷UX培训中。即使在这里，当Jared宣称敏捷性只是为了更快地完成工作，因此敏捷性从根本上缺乏任何质量的概念时，我也感到非常沮丧。贾里德认为，这正是需要用户体验的地方，将敏捷性对发货的痴迷引导到值得发货的产品上。

在敏捷教练和Scrum大师嘲笑这种情绪之前，请理解这些是对几乎所有情况下实际实施敏捷的方式的非常合理的反应。悲剧的是，用户体验专家对敏捷的了解仅仅来自于他们所工作的公司的实际实施情况–来自于我们作为Scrum大师和敏捷教练向他们展示的东西。他们基本上不知道敏捷性应该是什么。为什么他们会知道？这是一种 “为工程师优化的文化”，而不是为他们。他们通常不被邀请参加Scrum Master的培训。他们为什么要浪费时间去读《敏捷软件开发宣言》–如果他们读了，为什么会比Michael在他的上述文章中读到的 “敏捷团队 “的实际经验更轻蔑？

当然，悲剧在于，解决这种对敏捷性的嘲弄的办法是实际的敏捷性–但是除了Scrum倾向于创造的货物崇拜，没有任何敏捷性的例子，我们有什么权利对他们最终一次又一次地重塑敏捷性感到惊讶呢？

我发现，迈克尔所说的位于敏捷性核心的三个基本缺陷，分别由《敏捷软件开发宣言》的四个价值观之一来解决，而这正是整个敏捷运动的原点：

1. “人不是机器 “表达了与 “个人和互动高于过程和工具 “相同的观点。
2. “设计不是库存 “是 “客户合作高于合同谈判 “的一个很好的例子。
3. “产品不能被定义为由任意数量的具有任意技能和经验的人在两周的冲刺阶段所能完成的事情 “是 “应对变化而不是遵循计划 “的一个很好例子。

根据Michael的说法，Scrum “是这样的 “的原因之一是 “它必须以Sprint为时间框架，以确保软件可以在一个’迭代’周期内发布到市场上。” 的确，Scrum要求我们把工作切成小块，以便可以迭代地发布到市场上，但这是一种策略，而不是一个理由。原因是由宣言的第一个原则给出的：

我们的首要任务是通过早期和持续交付有价值的软件来满足客户。

我们的重点是定期交付和运送工作产品，这不是为了它本身，而是作为创造高质量产品的手段。敏捷性假定我们在处理复杂的问题，也就是说，我们不一定确定需要做什么来解决问题，也不完全确定如何去做。对于这样的问题，我们必须尽早将不完整和不完善的东西投入到这个世界上，开始获得反馈，并朝着真正的解决方案迭代。

在 “敏捷时代”，很少有公司真正遵循这一理念，尽管Scrum货物崇拜几乎已经无处不在。这些团队称自己为 “Scrum团队”，但他们通常会砍掉Scrum指南中定义的流程的关键部分，比如组建跨职能的团队并让这些团队自己管理。

我尊敬的UX同事，你知道吗，当Scrum指南提到 “开发人员 “时，也是指你？Scrum指南将 “开发人员 “定义为 “Scrum团队中致力于在每个Sprint中创建可用增量的任何方面的人”。这里的 “开发者 “是指 “开发产品的人”，而不仅仅是程序员。用户体验研究员和设计师在Scrum中和软件工程师一样都是开发者。Scrum团队应该是跨职能的，”意味着成员们拥有每个Sprint创造价值所需的所有技能”。用户体验研究和设计是每个冲刺阶段创造价值所需的一些技能，所以如果你不是团队的一部分，那么它实际上就不是一个Scrum团队。

然而，”双轨制敏捷”（甚至 “三轨制敏捷”）远比《Scrum指南》明确定义的Scrum团队更常见。这里的问题又回到了我与Dave Malouf上面的黑体字的分歧点。他写道

“……开发人员和产品经理以产品是否按时交付来衡量成功，而不是以设计是否满足用户需求来衡量。

但我们要清楚：开发人员确实以产品是否满足用户需求来衡量成功。这就是《敏捷软件开发宣言》的第一条原则。我们的目标不是按时交付产品，而是定期交付，以此来确保我们能满足客户的需求。产品经理有一个衡量成功的三要素：可行性（产品是我们可以实际生产的吗），可用性（用户会喜欢这个产品吗），以及可行性（产品能不能盈利）。衡量成功与否的不是开发人员或产品经理，而是我们在组织中更高层次的共同上司。更快地交付更多软件的承诺是企业进行敏捷转型的最常见的原因，但这并不是敏捷的重点。正如Allen Holub所说：

我当然可以理解，从用户体验专家的角度来看，他们被排除在这一切之外，被打入 “双轨制敏捷 “计划中，甚至更糟糕的是，敏捷似乎只关心数量，但这不是敏捷的问题–这是敏捷的心脏被挖出后留下的苍白阴影的问题。

在文章的结尾，迈克尔提出了他认为的创造产品的卓越程序。他的程序中的前三点是：

1. 确定需要建设的内容。
2. 确定如何最好地建立它，以实现可扩展性和面向未来。
3. 然后建立它，无论需要多长时间。(不需要两年，但也不需要两个星期。只要产品是按规格建造的，发布就可以被切成片状和块状）。

在我职业生涯的早期，有许多项目正是按照这种模式运行的，而这些项目确实需要两年甚至更长的时间，我不确定我是否相信这个括号里的断言，但我想重点谈谈这个观点的基础，以及它与支撑敏捷性的观点的对比情况。第一步是确定需要建造的东西。这建立在一个不言而喻的假设上，即在任何人开始建造任何东西之前，都有可能知道需要建造什么–与敏捷性的假设相反，我们面临的问题是复杂和多变的。

死信箱的问题

上面的备忘录是由一位平面设计师在LinkedIn上发布的。它很好地表达了设计师对开发者的挫败感。在花了好几个小时为令人愉快的界面制作漂亮的高保真模拟图之后，实际出来的产品往往是令人失望的，似乎与设计的东西相去甚远。

尽管在这些时候你可能很难相信，但开发者可能并不是要破坏你的设计。这可能也不是说他们无能。他们可能并不像你那样了解构图、平衡或视觉层次，但他们可能知道一些你不知道的关于技术限制和事物在屏幕上的呈现方式的事情。很有可能的是，这些问题中至少有一些正是来自于这种情况。在 Figma 中，在这里放置一条线是世界上最简单的事情，但在实际产品中可能要花一整天的时间才能实现。在编程中，哪些问题是微不足道的，哪些问题是几乎不可能的，这常常是令人惊讶和不直观的，甚至开发人员在深入了解问题之前也不一定知道其中的区别。

对于设计师来说，模型中的哪些部分是重要的，哪些部分显然是早期草案的产物，或者仅仅是附带的，可能看起来很清楚，但是程序员所要做的就是模型本身，所以他们并不总是能够分辨出来。通常情况下，开发人员尽其所能将你的设想变为现实，但你可能没有在那里帮忙。毕竟，你不是Scrum团队的一员。你可能正忙着为即将到来的冲刺准备下一批模拟模型。没有你的指导，开发人员尽了最大的努力–让所有人都感到失望。

通常情况下，作为设计师，我们的目标是促进什么

丹-梅尔

比喻为 “死掉”。他和

Brad Frost

多年来有很多关于我们如何重新思考设计师和开发者之间的关系，消除交接，而是更紧密地相互协作。

Shamsi Brinn

最近写到这种交接文化对设计师和开发者都是灾难性的，他写道：

交接导致了设计和开发团队之间的错误对立。设计师们为 “进入房间 “而奋斗，但设计移交是一扇我们无法走进的门。而对于开发者来说，前置设计意味着他们总是在构建他们没有发言权的解决方案，并被留在产品的烫手山芋上。

当然，更紧密的合作听起来非常好，但一个顽固的实用主义者可能会问这是否真的是真的。双钻的两颗钻石通常被总结为：

设计正确的东西。
设计正确的事情。

如果这些步骤做得正确，那么设计者与开发者合作，或者开发者觉得他们没有被包括在内，这有什么关系呢？我们是否考虑过这样的可能性：他们没有被包括在内是因为他们没有任何有用的东西可以补充？我们可能需要确保我们移交的工件有更好的文档–或者我们只是需要开发人员学会如何正确地阅读一个模拟图–但是如果我们设计了正确的东西，并且我们设计了正确的东西，那么剩下的唯一步骤就是让开发人员做好他们的工作，对吗？

做了所有正确的事情，但还是出错了

在用户体验中，有一种持久的信念，即我们可以从一开始就确保产品的成功–我们可以找出正确的设计，然后以正确的方式进行设计，这样就没有必要再进行反复的设计。说白了，用户体验提供了一些惊人的工具，绝对能在用户之前发现很多问题。你在纸质原型中发现的问题远比你在实际产品中发现的问题更容易解决。但是，尽管用户体验很有价值，它也不是万无一失的。你可以把所有事情都做对，但仍然有可能出错。

安格斯-莫里森

给了我们一个关于这样一个案例的详细事后分析。Angus在用户体验的工具和流程方面做得很好，但他最终得到的解决方案使用户注册的可能性降低了20%。他在A/B测试中发现了这个问题，但是在问题被发现和解决之前，它仍然需要被实施并被放在大量的用户面前。

即使我们对参与者的选择和研究方法很严格，事情的真相是，用户对原型的行为并不总是与他们对现场成品的行为完全一样。有一些因素在起作用，而这些因素只有在产品实际发布时才存在。通常情况下，这些差异小到可以被忽略，但它们可能是关键的–而且在世界范围内出现产品之前，没有办法知道你可能遇到哪些差异。

邪恶的问题

在 “论设计思维 “中

麦琪-格拉姆

将20世纪的设计史描述为两个强大的理念之间的拉锯战，这两个理念在几十年间以略微不同的形式反复出现。

在美国，设计在1930年代首次作为一种职业出现。当这些设计师去打仗时，他们与科学家、工程师、数学家和其他人一起工作，从而熟悉了 “设计师作为跨领域巧妙解决方案的全能设计师的想法”。这种接触不仅为设计师赢得了更大的尊重，而且在许多情况下，促使设计师将他们的手艺应用于更大的问题。像C.West Churchman、Christopher Alexander、John Chris Jones、L. Bruce Archer和Herbert Simon这样的人物都对 “设计过程可以被完全编目、描述和合理化 “的想法做出了贡献。

进入Horst Rittel。像丘奇曼、亚历山大和西蒙一样，他的设计思想也深受战时经历的影响，但他从另一个方面经历了冲突。霍斯特1930年出生在柏林。他是Flakhelfer一代的一员。1940年他10岁的时候，德国正处于战争状态，加入希特勒青年团是强制性的。当他15岁时，他被征召在注定失败的柏林保卫战中担任炮灰。像其他 “四十岁的人 “如尤尔根-哈贝马斯一样，这段经历给里特尔留下了对民主和自由所有混乱的活力的深刻赞赏，以及对任何披着理性和严谨的科学精确性外衣的集权意识形态的根深蒂固的怀疑。

Rittel因引入 “邪恶问题 “的概念而最为著名。在Scrum培训师经常使用的斯泰西矩阵的版本中，”复杂问题 “类与 “邪恶问题 “有很大的共同点，包括没有明确的表述，没有停止的规则，没有对解决方案的直接或最终测试，以及与其他问题不可避免的联系。

Gram写道：

对于Rittel来说，设计问题的邪恶性意味着它们永远不可能被置于一个单一的解决过程中。不可能有一种 “方法”。教科书倾向于将工程工作分解为 “阶段”： “收集信息”、”综合信息并等待创造性的飞跃”，诸如此类。但对于邪恶的问题，Rittel写道，”这种类型的计划是行不通的”。了解问题需要了解其背景。在开始制定解决方案之前，不可能收集全部信息。没有什么是线性的或一致的；设计师没有，也不可能这样想。如果有任何关于设计过程的描述，那就是作为一种争论。设计是多种批判性的声音，在未知的地形上敲打问题，直到它自己形成或不形成某种解决方案。

Rittel认为，这种无方法性是一件美妙的事情。他后来写道，这意味着一种 “令人敬畏的认识论自由”（斜体字是他的），没有算法的护栏或有效性规则。他写道：”带着认识论的自由生活是不容易的，”因此设计者们经常寻找sachzwang–实际的约束，固有的必要性，”一种’从事实中推导出应该’的装置。” 但他们不应该这样做。没有方法论的约束，设计就有了异质性的空间。它有能力带来惊喜。”Rittel写道：”没有什么东西必须是或保持它的原样，””或者它看起来是。

设计作品是一个单一流程的副作用，它满足于死板的交接，因为它相信一个单一的流程可以可靠地达到正确的答案。如果你相信这一点，那么敏捷性的核心概念就没有必要了。我们不需要通过发布产品的迭代来发现它是否可行、可用和可行。我们有一个过程可以确定这一点。我们只需要遵循这个过程，我们就可以确保它在第一次发布时是正确的。瀑布式方法没有理由不可行。

但是，如果我们去掉这条信仰，并对Rittel所做的事情产生同样的怀疑呢？如果我们承认设计是一种争论呢？Rittel的邪恶问题是我们只有一次机会来解决的问题，在那里，设计者没有权利犯错。他和Melvin Webber在1973年发表的介绍这一概念的开创性论文中写道：”我们不能建造一条高速公路来观察它是如何工作的，然后在不满意的情况下轻易地纠正它”。这使得我们在数字产品设计方面的大部分工作明显不是邪恶的。虽然他们可能会分享这些问题的复杂性，但我们明显地被授权去尝试一些东西，从中学习，然后纠正它。Rittel会认为我们有多傻，看到我们被赋予了这样的恩惠，却不去利用它？

设计与居住

当我们考虑创作过程时，我们经常想象一个人有想象新事物的远见，并有使这种远见在世界中成为现实的技能。不过，这与艺术家通常描述他们的过程并不一致。米开朗基罗有句名言：

在我开始工作之前，雕塑就已经在大理石块中完成了。它已经在那里了，我只是要把多余的材料凿掉。

我们大多数从事艺术创作的人都能体会到这一点。我们不仅仅是在塑造材料以配合我们的愿景；材料同时也在塑造我们的愿景。其结果不是艺术家的愿景得以体现，而是艺术家和材料之间的某种争论所留下的东西–这种争论是通过工作而产生的。

在《对环境的感知》中： 关于生计、住宅和技能的论文》中，Tim Ingold讨论了他所谓的 “住宅视角”，并将其与 “建筑视角 “进行对比。对你们中的大多数人来说，建筑视角是看待世界的传统方式。这是艺术家的视角，他将自己的视野强加在材料上以创造艺术。这是一个二元的视角，在这个视角中，思想先于行动，计划先于行动，发现和定义先于开发和交付。双重钻石是建筑视角的一种表达。

对英戈尔德来说，是发展生物学、生态心理学和现象学哲学导致了一种不同的观点，他称之为居住的观点。

从这个角度来看，生命不是对预先存在的形式的揭示，而是形式产生和固定的过程。……正是通过被居住，而不是通过同化于正式的设计规范，世界才成为对人有意义的环境。

这似乎更接近我们一直以来的观点，即《敏捷软件开发宣言》、Horst Rittel和Michelangelo的观点。

我觉得我需要（最终？）在这里保持一些克制，避免挖掘沃尔特-翁的《口述与识字》，以及居住视角似乎是如何从口述中产生的，而建筑视角似乎是由识字造成的认知扭曲产生的。英戈尔德在他的书中探讨了这些观点塑造历史、现代世界和更广泛的人类经验的无数方式，所以我们在这里重点讨论它对创造数字产品这一非常狭隘的利益意味着什么。

用户体验和敏捷性之间的分歧不是说用户体验关心质量，而敏捷性只关心交付。这是一个关于世界的更深层次的哲学分歧，也就是如何把高质量的东西带到这个世界上。

在旧的瀑布环境中工作，用户体验设计师遵循Churchman、Alexander、Simon和其他人的工作，遵循建筑的观点和它所建议的流程，这是完全可以理解的。在他们被赋予的角色范围内，这种观点为他们提供了为用户创造美好体验的最佳机会。问题是，建筑视角是错误的。建立在它上面的流程经常不能创造出好的体验，不是因为我们下游的同事的失败，而是因为整个流程建立在一个错误的假设之上。

在下游工作，更接近交付的时候，从编程开始走向居住的观点是有道理的，但这并不意味着它只适合于编程的东西。当Scrum指南提到 “开发者 “时，它很明确地指的是程序员和设计师–以及其他所有参与开发产品的人。

Agility在这个问题上是完全正确的。Horst Rittel在著名的雪鸟会议之前30年就试图告诉设计师这一点。如果我们有勇气接受他所谈到的令人敬畏的认识论自由，那么就会是设计师向程序员传授这一课，而不是反过来了。

但就像种树一样，改变的第二个最佳时机就是今天。而事实是，敏捷开发亟需用户体验。早期的敏捷实践往往涉及到让客户与程序员一起开发软件。这对于几十个高度专业化的专业人员使用的专业软件来说，效果非常好，但是没有一个客户能够代表数百万使用一个流行的公共应用程序的用户。这就要求房间里有一个用户体验研究人员。明智地选择用户体验指标可以给敏捷团队一个比速度和故事点更好的优化目标。

Teresa Torres

开创了持续发现的做法，这是一种用户体验和产品研究的方法，包含了居住的观点和Rittel的设计即论证的想法，可以作为持续交付的一个令人难以置信的补充。

长期以来，用户体验专家一直认为，用户体验不能被看作是流程中的一个阶段，而是每个阶段都涉及的东西。这和敏捷性坚持的居住观点一样明确正确–但是，为什么我们继续依赖双钻模型，或者在双轨或三轨的Scrum模仿中工作，在其中我们交出设计工件而不是直接参与工作？当我们说我们不是流程中的一个阶段，但仍然把我们的工作分为我们参与的阶段和我们不参与的阶段时，我们的同事应该怎么想？

Rittel是正确的：带着认识论的自由生活是不容易的。它可能是可怕的。Scrum指南将勇气作为其价值之一，这是很好的理由。在认识论的自由中生活需要勇气。设计不是一个适合懦夫的领域。如果我们能够超越这种恐惧，Rittel所梦想的所有宽广的疆域仍然存在。当我们把设计植根于居住的角度时，它能成为什么？当我们接受在实践中学习的事实时，我们可以开创哪些新的设计方式？我们可以发现哪些新的合作方式？我们可以一起创造出哪些美妙的新事物？

没有什么是必须的，也没有什么是必须保持原样的，或者看起来是这样的。

翻译：云瑞设计
原文：uxdesign