The Part of Agile Designers Fear the Most: Imperfect Work

聚焦敏捷设计师最害怕的部分：不完美的工作

URL 源: https://uxmag.com/articles/the-part-of-agile-designers-fear-the-most-imperfect-work

发布时间: 2026-05-28T03:39:21+00:00

Markdown 内容: _从 Laura Klein 的观点中，我印象深刻的是，在最小可行产品（MVP）中，团队往往忘记了“可行”这个词。_

在研究敏捷产品开发时，我惊讶地发现它具有很大的心理因素。

我们经常谈论敏捷，仿佛它纯粹是一种流程。有冲刺、待办事项列表、站会和规划会议。一切看起来都是程序化和结构化的。但这些仪式背后，对于设计师来说，更不舒服的东西。

敏捷要求设计师在感觉工作完成之前就发布工作。Laura Klein 在我正在学习的课程中直接谈到了这一点。设计小功能并提前发布听起来在理论上是合理的。但在实践中，这常常触发设计师最深处的恐惧：发布不完美且未经测试的产品。这种恐惧并非完全无理。

MVP 中缺失的词

当团队谈论 MVP 时，对话通常集中在“最小”这个词上。目标是构建最小可能的东西，并尽快将其推向市场。但 Laura Klein 不断强调，MVP 中最重要的词是可行。

一个功能的第一个版本可以绝对很小。但它不能是不可用的。如果发布的功能令人困惑、损坏或令人沮丧，我们就无法从中学到有意义的东西。

用户不会拒绝这个想法。他们会拒绝糟糕的体验。

这个区别很重要，因为敏捷依赖于反馈循环。团队发布一些东西，观察人们如何使用它，然后进行改进。但如果初始版本设计不佳，反馈就会变得不可靠。

你学到的不是概念是否有效，而是人们不喜欢糟糕的产品。这并不是什么划时代的见解。

设计师犹豫的真实原因

有趣的是，设计师对发布功能早期版本的抵抗并不总是关于完美主义。在课程中分享的采访和讨论中，许多设计师表示，如果他们相信团队会回来改进它，他们实际上很乐意发布不完美的工作。

问题在于，许多团队没有这样做。

一个功能被发布、庆祝，然后悄悄被遗弃。团队转向了待办事项列表中的下一个项目，不完美的版本成为永久的。从设计师的角度来看，这就像辜负了用户。

迭代使早期发布有意义。没有它，敏捷就变成了一种匆忙将功能推向生产的做法。

迭代不仅仅是增加功能

从课程中学到的一个最重要的区别是，迭代不仅仅意味着增加更多功能。真正的迭代涉及发布、反馈和改进的循环。有时这种改进表现为小的调整。其他时候，它需要对某个事物的结构进行更大的改变。

这就是重构的概念出现的地方。

在工程中，重构通常意味着在不改变用户行为的情况下改变代码的内部结构。开发者可能会重写系统的一部分，使其更高效、更容易维护或更不容易出错。

设计师有时也需要做类似的事情。

想象一个最初具有简单导航结构的产品。起初，应用只有几个部分，所以顶部导航栏工作得很好。随着时间的推移，添加了更多的功能。一个显示以前申请工作的部分。另一个部分用于学习资源。也许有工具来建立更强的个人资料。最终，导航开始感到拥挤。曾经很好的东西不再支持产品不断增长的复杂性。

在这个时候，设计可能需要重构。团队可能会重新组织导航结构，或者转换到一种能够容纳更多内容的不同布局。功能没有改变。用户仍然可以访问相同的功能。但结构已经进化以支持未来的增长。

为什么重构很重要

知道重构是可能的改变了设计师对早期决策的看法。如果每个设计选择都必须支持所有可能的未来场景，我们就永远不会发布任何东西。不确定性会令人窒息。但如果团队接受产品会发展，就更容易专注于当前最好的解决方案。

但这并不意味着设计粗心大意。这意味着为现在负责任地设计，同时为未来留下适应的空间。敏捷团队不试图预测一切。他们构建一些有用的东西，观察它在现实世界中的表现，并持续改进。

设计师需要掌握的平衡

这对设计师来说是一个艰难的平衡。一方面，我们希望预见到未来的需要并构建可以优雅扩展的系统。另一方面，我们知道，直到用户实际与产品互动，许多假设都会是错误的。

迭代使这两种现实共存。我们设计一些解决今天问题的东西。然后我们观察、学习并改进。有时这些改进是小的调整。其他时候，它们需要更大的结构变化。

无论哪种方式，产品都会随着时间的推移而改进。因为我们在用户接触任何东西之前想象的“完美”解决方案通常是……理论上的。

_本文最初出现在 Substack。

特色图片由 Glenn Carstens-Peters 提供。_