注重团队设计
与瀑布模型的单打独斗不同，快速迭代设计更推崇团队设计，由设计师主导，把握设计框架，整个团队给出解决方案。一些design scenario和workflow的归纳，即使经验丰富的设计师，也不如团队智慧来的全面，当然，除非你是乔帮主，使用导演中心论的设计流程。另外，团队设计的好处还可以减轻设计师的负担与压力，一起承担产品兴亡的重任比一个人承担要安全可靠的多。
设计不多不少，恰好就行
兵贵神速，指的就是以快为王。特别是在快速迭代设计中，你不必在你的原型或草图中事无巨细的列出所有可能，完美的概念在这里是不适用的，甚至你不需要完成设计的整个部分，只要把关键模块讲清楚了，开发与测试理解了，就足够。想想那些精美的设计文档中无数看上去perfect的图片和排版，最后真的有人在乎吗？只要你在迭代开发流程中能于脑海中攫取所有细节并传递给团队，不要文档都可以。无需太具体，思考那些真正有价值的地方。
写好User Story
User Story是在Agile开发流程中从用户角度对系统的某个功能模块进行的简短描述，它包含了目标用户（不同角色）、功能需要（可以做什么）以及其创造的价值（实现目的）。它可以是：
1、一个用户需求
2、产品功能的描述
3、用来计划和追踪任务的工具
4、团队沟通的桥梁
通常我们把一个User Story按照以下格式写在即时贴上：
以第一个句型为例：
As a _ I would like _ so that _
作为（某个角色），我希望可以（做什么），以达到（什么目的）
User Story照理应该是由PO写，不过有些团队（比如我们：D）是由设计师来完成，同时在即时贴上标注预估完成时间（我们团队采用了Story Point这样一种估算方法，这里不赘述）和优先级别，以便开发团队根据它们来形成Sprint Backlog。
任务量
不同的功能模块其工作量也不尽相同，我们可以按以下三种类型划分：
1、Large
一般来说每个User Story都需要在一个Sprint内完成，避免太大而跨越几个Sprint。如果出现太大的User Story导致一个Sprint塞不下，则需要将User Story分解，这个Sprint完成一部分，但是不release，只是demo给PO/PM， 余下的在接下来的Sprint里完成。
2、Normal
按正常流程进行快速迭代设计。
3、Mini
JDI （Just Do It）， 一些小功能的实现无需文档，任何沟通方式都可以用来传达你的设计思路，然后交由开发去实现。
关于文档
原本瀑布开发模式下设计师的唯一交付物Specification，在快速迭代设计中已经不是那么重要，因为快速变化的用户需求让设计节奏加速，不断更新维护Specification成本太高。用户是为你设计出的产品或者功能付款，而不是你的设计文档，所以传递设计思想才是主要目的，PPT、Visio等Wireframe或者email、meeting notes等记录都可以作为设计参照。
对于文档，我们一般遵循如下原则：
尽可能在文档中简单的描述需求、分析结果、信息架构和设计细节，只要它们恰好满足PO的要求即可。
如果该Scenario的逻辑足够复杂，那么请毫不犹豫的用文档详细的描述，以开发团队恰好能充分理解为宜。
文档的简繁程度需要经过几个Sprint的迭代，才能找到最合适的level。
保持一直设计
设计对产品来说如此重要，特别是在敏捷开发流程中，没有一个专门的设计阶段（There is no design phase），整个流程都伴随的设计。从前期纸片概念，白板框架，用户场景测试，到具体细节代码实现，终极用户测试，都离不开设计的跟随。这不再是那个只需要在早期完成设计就弃之不管的模式，他要求你每天都不停的参加讨论参入迭代参与设计。
Epilogue 后记
我们团队面对的是一款由公司早期元老打造的工程领域软件，它的用户基数庞大，它的地位曾经显赫。然而它的功能逐渐老化，模块架构也相对固化，开发团队很难对整个系统进行改动，因为整个软件架构已经固定，任何大的改动都是牵一发而动全身，不但会造成许多与改动处无关的环节出现问题，莫名其妙的regression defect也让QA措手不及。一些设计改进都必须得在之前设计的基础上进行调整，力求一致性，很难加入全新的交互模式和UI风格。同时，正是由于产品功能没有大幅度的更新，瀑布模式比较擅长的低风险复杂功能开发已经无法满足用户需求的小快灵。 因此，我们目前所使用的敏捷设计流程尽管无法跟全新开发的产品一样自由，只是在大框架的制约下进行功能的迭代更新，但也取得了不错的效果，3年做下来完成了许多小功能的快速成功发布，提升了大家对于Scrum流程继续使用的信心，致力于建立一个持续的可改进的快速响应团队。本文所提及的流程并不适用所有情况，希望大家各取所需，保留对自己有价值的部分，摒弃不适合的。