注重團隊設計
與瀑布模型的單打獨斗不同，快速迭代設計更推崇團隊設計，由設計師主導，把握設計框架，整個團隊給出解決方案。一些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流程繼續使用的信心，致力于建立一個持續的可改進的快速響應團隊。本文所提及的流程并不適用所有情況，希望大家各取所需，保留對自己有價值的部分，摒棄不適合的。