本节书摘来自异步社区《当用户体验设计遇上敏捷》一书中的第3章，第3.2节，作者【英】Lindsay Ratcliffe , Marc McNeill，更多章节内容可以访问云栖社区“异步社区”公众号查看
3.2 一个重大的设计挑战
当用户体验设计遇上敏捷
IT负责满足业务对更高效、更有效的软件交付方法的需要并对此给出响应。如今，作为设计师，需要迎接挑战，重新对设计进行设计，将其带回到与数字产品开发一致的、快速的状态，并且将设计注入到敏捷过程中。我们要的是高效的、有效的以及带着愿景出现的设计，但我们也想创建让人为此埋单的、合心意的体验。
本书的任务有以下两个。
帮助设计师理解自己在敏捷过程中的位置以及如何使自己的优势最大化。
帮助项目管理者、开发人员和其他每一个参与软件交付工作的人理解设计的重要性以及设计在敏捷开发过程中的位置。
设计，其存在的目的是为了影响用户的感知和行为，在传统上已经落入业务（更具体来说就是市场部门）的范围内。然而创建了敏捷过程的是软件开发人员，所以到目前为止，大量关于敏捷的书籍文章资料都出自软件开发人员之手，为的是达成创建更好的软件这一目标。
敏捷不是要特别地排斥设计，也不意味着设计和设计师的角色对过程不重要。而是到目前为止（在本书出版之前），还没有人真正讲解设计及其在敏捷项目中的角色。
体验设计就是解决问题，这既需要逻辑的、分析的思维，也需要创造性的设计思维。
当我们将问题解决方法分解开，我们可以看到它由许多组成部分，由许多相关的而且互补的活动组成。这些活动可以因背景、设计师和设计挑战的不同而不同，而过程是可重复的。
提示：
在敏捷环境中进行设计的时候，给你的第一个重要提示就是，你需要为产品/服务创建一个有根有据的愿景，随着设计细节在项目剩余的部分渐渐浮出水面，这一愿景将用于指导设计细节方向。
我们首先来看业务和最终用户的需求和背景。我们来了解解决问题、获得反馈以及将想法精益成一到两个，从而可以越来越详细地探究不同方法。无论是在瀑布还是在敏捷环境中工作，这个总体过程都是一样的。主要的不同在于，在瀑布中所有上述内容都是在单一的项目阶段中由设计师们独立工作完成的；而在敏捷项目中，这些活动分散在项目中，而且是协作完成的（图3.1）。
敏捷从业者建议直接编码，并且以最快的速度交付可工作的软件。然而，可工作的软件并不意味着结束。如果软件既不能给业务、也不能给最终用户带来价值，那么就只是一堆无用的代码。所以，我们在进入设计细节的开发时，要确认有个有根据的、经过深思熟虑的愿景。
对于正在开发中的产品或服务，愿景是其基础和框架。
愿景不仅指导开发方向，也让开发保持正轨。我们欢迎有根据的改变，但不欢迎随机凌乱的路线。
在敏捷项目中，愿景的创建有时候会被忽视，这经常只是因为许多敏捷项目管理者只有技术背景，但不熟悉以业务或设计角度来看产品开发过程。而这是这一过程的关键部分，只要是用户体验对成功至关重要的项目都必须将其包含。如果没有时间来考虑业务和用户环境，进而使用这些信息来形成设计愿景，那么设计师的交付过程将会十分坎坷。
与能够以独立的小块来开发的故事不同，一小块一小块的设计之间必须完全互相依赖才能创建出全面、一致而且动人的体验。这不是偶然的。在喂饱一群饥饿的开发大军之前，要先把饭菜做好。
再次强调，这不是大量的前期设计。设计愿景只是完成足够打基础并且设置好清晰的方向的工作。即使Martin Fowler也同意：
“人们都认为我是个胆小的极限编程者（XPer），但我对此不敢苟同［关于直接进入编码细节］。我认为得有一个负责广泛的、开始点的架构的角色”。
于是挑战在于，在设计的时候理解哪些工作是刚刚好的，以免又犯了过早创建过多细节的老毛病。我们将在第7章中详细探究这个问题。
