敏捷开发方式是不会被淘汰的。金融危机在过去几个月中终于爆发了；长期的要求和浮夸的前期文档不被接受的情况比以往更为普遍。软件必须从一开始就可见并且有价值。对很多设计师来说，他们对敏捷理论已非常熟悉（对此不太了解的，请参看文章最后的一些推荐阅读）。我们正在面临适应或是被淘汰的选择。好的方面是，敏捷理论仍然允许我们做那些我们认为有价值的事——研究，发展一个观点，测试并提高我们的设计——我们需要的只是新技巧。如果我们想在这越来越严峻的形式下与时俱进，现在是实践的时候了，证明设计可以适应。

    渊 源
    时间，研究和构思有史以来都是设计师熟悉的领域，它们和我们与生俱来的想像和直觉相适应，并且使我们能够将模糊抽象的“品牌”和“用户行为”仔细结合起来然后转化成开发人员喜欢的：技术规范、站点地图、规划图和图表。

    而另一方面，敏捷理论意在快速的交付软件和流畅地应对变化。这两种模式依靠的是微妙对立观念：见招拆招 vs 运筹帷幄，迁就变化 vs 先发制人。 尽管有这些不同，许多敏捷宣言从根本上还是和设计师的思想体系相关的，交互在过程之上，合作在谈判之上，反馈，简洁。都正合我们的意思。

    虽然设计师和开发者通过不同的视角观察世界，敏捷哲学从本质上是足够灵活能够支持这两种不同的方式和思想的。在敏捷的世界仍然有方法可以适应高品质的设计。

    研 究
    鉴于敏捷理论认为“运作着的软件是评估进展的主要方式”，这使得详细研究的空间很小。虽然基于敏捷理论的项目能够在没有任何用户资源而（用直觉代替以用户为中心的设计）的情况下执行，但是输出总是少得可怜。就像手术也许是成功了，而病人却死了。

    当团队成员和目标用户相似时，代入用户可以满足需求。设计师可以利用他们的经验工作，发现潜在的偏见并调解它。然而这种情况并不多见，大多数项目从研究中得到有益的东西，避免从错误的方向得到动力。 “零次迭代”作为一个争取时间的方式被接受，有些团队将这个方式扩展，在没有用户反馈交付的情况下增加了中期零次迭代。开发人员可以整理代码并规划下一步，设计师可以重审品牌、美感、体验这些贯穿整个站点的东西。

    既然研究必须被轻量级，就不可避免会不精确。幸运的是，即使在每次迭代时进行一次到两次小型会议都可以满足需求。一个较好的方式是利用人际网（朋友的朋友，Twitter）并举行双重目的的会议：为未来的构想做研究，为已经完成的构想做可用性测试。如果不可能获得真实的用户，还是有挽救的机会。市场团队常常是拥有大量的人口数据的，服务器日志可以暴露搜索范围以及其他。这很鲁莽，但是甚至是这样的研究也可以帮助设计师弥补不足。

    这种方式显然是不适合需要前期研究的缜密型研究团队。有些团队试图雇用项目之外的研究顾问，以便在需要的时候给予研究结论。然而，这样的结果有可能是混乱的，有用的细节也可能在沟通过程中丢失。因此，除了大型的项目，设计师最好能通过自己做研究获得重要深入的见解。

    设计流程
    敏捷的迭代是计划一个稳定的开发速率，但是设计师并不总能从这种中规中矩的工作流程中得到益处，因此摒弃计划对设计来说也是有价值的。准确性可以很灵活，一个大致的估计也可以帮助减少贸然的设计并且强化与开发同样关键的设计的重要性。

    “最优方法”建议设计师应该研究迭代n+2，设计迭代n+1，支持迭代n，审核迭代n-1。这是个忠告但是无需照字面意思去做：一些构想的设计需要比这些时间线更久的时间。设计师应该用他们的直觉和经验提前找出潜在的复杂构想，获得更长的研究周期。这种做法和敏捷理论的规则有偏差，但是如果对项目有益就该鼓励。

    愿 景
    缺少连贯是敏捷设计的一个普遍缺陷。这源于敏捷理论的模块化本质和某种程度上一个范围内的力量平衡。产品负责人，有时缺少觉察大局的策略。不加以制止的话，这会导致在战略上的突发奇想，提出不稳定需求，产品贴近的是公司幻想而不是客户现实。“地平线效应”能说明这个弊端的症状：潜在的问题在不断的迭代过程中被忽视，在项目完成之前，设计师不能确定解决方案是否完全产生了效果。

    幸运的是，我们可以从其他领域借鉴。电影制片人以相似的方式运作，拍摄的顺序纯粹由逻辑决定。为了保证版本和叙事的连贯性他们聘请专家：导演和监制。在网络领域，设计师可以扮演相似的角色，但必须是自发自愿的。这意味着参与制作用户故事板，并试图引导产品所有者摆脱过度仓促的决定。

    我们仍然没有很多时间探索明确的产品构想，但仍可以通过将用户故事组织成完整的用户流程并设计这一系列的用户故事来达到目的。随后我们可以将之作为一个整体进行审查和测试。这种做法可以表明很多用户的总体体验同时预警那些因“地平线效应”造成的陷阱。

    交付物
    敏捷设计的交付物是轻量的文件。很好——更多的时间用于思考和设计。基于这种倾向，静态的页面文件和线框图是行不通的。这些对于敏捷设计来说太僵化，尤其是在页面已经不是网络的基本组成部分的今天。我们更喜欢“在过程之上的交互”方法，从对话而不是固定的模板开始，使用具有真实交互过程的原型而不是静态的线框图。

    用户体验设计师有许多交付物可以选择，低保真草图和纸质原型是分享设计思路和讨论观点的理想方式，然而这些方式在实际运用中却出乎意料的少见。通过快速而大量的手绘工作，用户体验设计师能够通过构建一个纸上的信息架构（包括元件，按钮，导航元素，下拉框等等）来复述他们的设计。

    使用HTML制作原型或借助Axure和iRise这样的工具也是好的辅助。虽然需要一定的学习曲线，但它们都避免了草图的含糊（还有裁纸）。它们的灵活性足以应对修改的需求，它们的稳定性可以保证测试完整的用户流程。

    视觉设计师仍然需要创造高质量的设计稿，所以终端产品设计也离不开Photoshop或者Fireworks。然而视觉设计师也应该与用户体验设计师一起参与早期原型交互设计。

   应该尽早提出解决方案，尽管与某些观念是格格不入的，但这是敏捷理论的中心。为了节约时间，每一个内容类别只做一个实例——一个形式、一页研究结果等等，是明智的。通过足够的沟通，原型可以兼具说明的角色。

    角 色
    我们知道现代组织体系是超链接形式的，但是在很多公司里设计仍然是单一决策的。为了迅速的迭代设计必须放弃完美：“90%正确”是敏捷的标准。这可能是违反常规的，但是不管怎么说，敏捷将时间线的重要性摆在精湛的技艺之上，并不是多大的损失。

    然而，也有妥协过甚的时候。据Alan Cooper所言“不会有一大群人对你糟糕的产品翘首以盼。”最好的往往会打败最先进入市场的，而设计师天然的在质量管理、通过产品游说赞助商提供额外资源方面做的很好。

    快速有时会诱使设计拘泥于模式化，借鉴其他有创造性的技巧可以有所帮助。设计师应该适应一个协作者的身份而不是一个独裁者。这不是指设计应该变得民主——专业的知识一如既往的必要——只是通过协同工作，设计师可以促进这种共同设计，并以此提高自身技能的信誉。这一方式还需要一种普遍认知：最好的敏捷设计师，产品经理，开发者和产品所有者都对彼此的原则有很好的理解。

    未 来
    当许多设计师热衷于适应敏捷理论，少部分人认为这是一种让步。敏捷就理论来说是成功的：软件开发的最优方法。但是敏捷与Python、可用性测试或者microformats相比并不是最优方法。它只是一种工具：有时适用而有时不是。为此我们看到了后敏捷主义的出现，试图保留一部分敏捷思想而摒除那些不适应项目的部分。

    不管怎么样，现在是将敏捷理论和设计团队就我们共同的未来达成一致的时候了。我们彼此需要，也需要从高高在上的象牙塔上下来。毕竟，我们有着共同的目标：为我们的客户和用户提供最好的结果。