本文共 2481 字，大约阅读时间需要 8 分钟。
本节书摘来自异步社区《当用户体验设计遇上敏捷》一书中的第3章，第3.1节，作者【英】Lindsay Ratcliffe , Marc McNeill，更多章节内容可以访问云栖社区“异步社区”公众号查看
当用户体验设计遇上敏捷
“人们总是设计东西。人类最基础的特征之一就是制造各种不同的工具和其他人工制品来实现自己的目的。随着这些目的的改变……就有了精益……有时候全新类型的人工制品就会孕育、产生”。——Nigel Cross，工程设计方法：产品设计的战略
设计师与此相干，因为敏捷蒸蒸日上，而这是一种完全不同的工作方式，要求用新的方法以及新的态度对待设计。
正在阅读本书的读者，可能是因为工作与敏捷相关，可能是进了一家新公司，而这个公司使用敏捷方法，也可能所做的工作采用敏捷。与许多设计师一样，读者可能之前对项目管理方法并不怎么关心，你可能对此不以为然。
你必须与此相干是因为，寻求更高效能和效率的项目交付方法的公司正在越来越多地采纳敏捷及其派生方法。我们需要理解敏捷与其他正在使用的方法的区别：这是一种涉及团队中所有人的方法，包括设计师，也包括开发人员。作为设计师加入敏捷项目团队中的结果，我们完成设计的方法也会有巨大的变化。如果不能掌握这一不同的工作方式，就难以顺应潮流。
不用抱有幻想，就如所有改变一样，一开始你会觉得有点不舒服，可能会有强烈的抵制甚至反叛感，你会想重回你原来所居住的安逸世界。我们自己在抵制、反叛、怀念从前。而围绕着过程迭代之后，我们可以给大家消除疑虑了。作为设计师，我们完成了向敏捷的转换，并且成为了其倡导者。我们有成功的故事，可以证明敏捷和设计可以快乐共存。
当用户体验设计遇上敏捷
设计师注意到的关于敏捷的第一件事情通常是它没有设计阶段。敏捷项目一头扎入开发中，对设计师所信仰的设计是产品开发过程的重要组成部分这一理论完全不给面子。设计师所看到的是许多短得荒唐的最后期限，在这些期限上要交付可工作的软件，并且不对重要的设计活动的工作量和复杂性做任何考虑。结果，许多设计师相信设计会受到严重损害，于是直接就对此很排斥了。敏捷公开宣称，它反对大量的前期设计，这听起来像是对设计的批评。这样的立场会让对敏捷不太了解的设计师感到不舒服。
让我们加入一些上下文，应用一些观点，并且揭示“敏捷中没有设计空间”这一流言的真相。
争论中大部分都与软件的前期设计有关，所以我们将首先快速了解一下这方面内容，然后探究如何将这些论点用在体验设计上。
我们已经知道，敏捷是由于对软件项目交付方式的不满意而产生的。敏捷离开了离散的、顺序的、功能特定的方法，而采用跨功能的协作和并行工作方式。另一项基本改变是不再在实现任何价值之前将每件事都做得很彻底，包括设计在内。它的思想是只做刚刚好的工作，然后随着了解深入而精益。
这意味着传统上总是事先完成达到第n个程度的系统架构设计，是最先进行根本改变的内容之一。 Martin Fowler在“设计死亡了吗？”白皮书中探究了“经过计划的设计”过程这个通常在建筑设计中遵循的做法，并且将其与软件架构进行比较。建筑师将设计绘制出来，在他们做这件事的时候，他们考虑并解决建筑设计的问题。一旦设计完成，就会递交给按设计进行施工的工程人员与建设公司。这也是软件设计的通常做法。在软件构建之前，软件架构师花费可观的时间来定义一个系统，而后才将软件设计规格说明书递交给不同的团队或其他公司来构建，这会造成以下两个主要问题。
难以解决在设计阶段完成之后出现的设计问题。由于不可能提前想到所有问题， 在后来的阶段中出现问题将不可避免，这时系统设计师已经转移到其他项目中工作了。
软件架构师不再是开发人员。开发人员典型的职业生涯是从编写代码开始的。最终他们会毕业，成为软件架构师，然后就几乎不再写一行代码。考虑到软件开发技术的更新步伐，这就意味着软件架构师很快就会与开发方法脱节，在需要解决一些让开发人员焦头烂额的底层实现问题时不那么有效。替代大量的前期设计的是演进式设计。一些死忠于这一方法（比如极限编程， XP）的人，相信大量的前期设计不应当存在。他们相信项目应当尽可能赶快开始编码，并且可以按需通过“重构”来解决设计问题。这里的讨论强调在敏捷中对“设计”这个词的使用。在技术社区经常讨论并研究前期技术设计要多少才合适。那么，也可以对体验设计问一些相同的问题：
与提前做所有的系统设计相比，提前做所有的体验设计是否更合理？尤其当我们知道并且接受这样一个事实：对建立良好体验产生影响的因素会改变。
试着在产品发布之前让其完美，却延长了初始想法和业务开始得到投资回报的时间之间的间隔，这是否有意义？
答案是否定的。
如果认为体验设计是成功的关键，那么我们不认为项目应当从编码开始，就如我们不应该在建筑的概念得以探明之前就开始施工。
如果是这样，那么建筑工应当从哪个地方入手？砖头、砂浆还是基础结构？要是建筑师将建筑设计成玻璃与钢的结构或者使用圆柱形的形式又该如何？是否要把建筑工人已经完成的东西推倒，从草图重来？
仅创建刚刚好的前期设计做为开始，并且通过测试、学习和精益来完成设计细节是更为有效的工作方式。在前面所提及的那篇论文中，Martin Fowler以这样的建议来表达他对这一观点的赞同：
“为了让软件能工作，演进式设计需要有股能驱动其朝向某一个点会聚的力量。这股力量只能从人而来——团队中必须有人能做出决定，确保设计保持高质量”。
那么敏捷与反设计矛盾吗？它并不与设计相悖，而是反对任何浪费的或者不直接创造价值的东西。于是，我们不会在项目的早期阶段进行所有的设计活动，然后将输出结果扔给墙外的开发人员；而是要看看我们在哪些地方可以将浪费最小化、将价值最大化，并且不需要对设计的质量或者用户体验做出妥协。我们的做法是只做刚刚够建立设计愿景的思考，这个设计愿景可以测试与验证，而后以迭代的方式构建设计细节。
转载地址：http://xotka.baihongyu.com/