二. 為什么要寫？

DRD非項目必需環節，一般情況下也不會為交互設計師專門留出相應的時間預估。沒有這份文檔，項目也會繼續，但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話，項目的質量也會受到影響。所以寫與不寫，交互設計師需要做把握，時間被統一包含在“線框圖”環節內——如果你要寫，請在評估時預留1-2天的時間。

那么，結合我過去的經歷，談一下此文檔的必要性。

下圖是一個產品開發項目基本的流程。

敏捷開發意味著很多不同角色的流程需要并行操作。如果等到產品經理的FRD已經全部敲定，交互設計師再開始去畫線框圖，固然會減少溝通成本和返工風險，但是同時意味著交互設計師的很多想法不被采納。如果產品經理再強一些，他甚至會在FRD里連原始的DEMO也一并繪制出來了，功能性的需求和界面交互的需求有時無法區分太清楚——比如他會在FRD里直接要求每頁條目40條，超過40條即分頁。而交互設計師可能會認為像蘑菇街那樣不斷裝載出足夠長的頁面會更親和……所以，我們希望是和產品經理同時開始工作，在術業有專攻的時候相互補充。

同樣，開發工程師也希望及早介入需求，在FRD并未確認的時候就了解需求，進而將商業需求和功能需求轉化為開發工程師看得明白的開發需求清單（這個清單，大部分叫做UC，即USE CASE）,當這份清單由工程師需求分析師——在過去，這個角色被叫簡稱為RA，但是目前已經取消此專門的職位，而是由開發工程師代表擔綱此環節工作，為了便于描述，在此文里，我仍然將做這件事情的人稱為RA——交付給具體的執行工程師后，執行工程師基本上可以當作一條條的checklist開始高效工作，而不必再思考商業邏輯和需求。同樣，測試工程師也需要編寫具體的文檔去指導很多測試人員在開發后高效測試，這也是基于UC和FRD去撰寫的。

開發部門的需求分析師：

• 每次變動都很痛苦，設計變了之后，我就要跟著改UC，改截圖，有時候UED改了還忘了通知我們，導致UC有問題……
• 頁面交互的需求容易漏掉，因為UC里面不可能寫太多交互方面的東西。
• 希望UED能夠在提交HTML DEMO給RA時，能同時給出一份頁面元素描述文檔，需要介紹html demo中的文案、鏈接以及相關的圖片尺寸或顯示字符個數?，F在RA在這方面花費的時間比較多，經常要和UED去確認這些內容。

產品經理：

• 前期RA和PD溝通過程中，有很多交互點點不能夠明確，比如“默認顯示多少屬性值”，“標題顯示多少字符”等。在以往的需求和項目中，對待這些問題我們都是想到一點補一點的到FRD文檔或者郵件中去。既增加了溝通成本又會存在遺漏細節的風險。PD為了可控性的需求，往往會“越俎代庖”，直接在FRD注明這種需求（對于交互設計師來講，卻又導致沒有發揮余地）

走訪了一些交互設計師后，他們也存在如何清晰無遺漏將交互設計需求傳遞下去的困惑：

交互認為很平常的設計需求，如果不表達出來，還是容易被前端和開發忽略掉。我經歷的一個項目，前端從頭到尾更換了三個人，每次我都要重復去講解下設計需求，講得口干舌燥。而且做好后，還需要去驗收。

• DRD做為參考手冊，一定程度上避免不吻合的問題發生。
• 即使有問題發生，也可以作為界面驗收時的Checklist。將“我對A說，我對B說，A對B說”，轉變為“A和B共同參考同一份文檔”，減少溝通成本及信息不對稱。
• 全程影響用戶體驗（一直到測試，都需要參照設計文檔）。

可是以下問題都可以通過一份DRD來解決嗎？

三. 寫什么不寫什么？

要明確文檔的定位，從寫什么與不寫什么開始，劃清DRD以及FRD的邊界。

不寫視覺規范規格標注

這些說明與功能實現沒有太大關系，主要是為前端做HTML的時候參考的。一般視覺設計師會在PSD里標注清楚。如圖：

不寫功能實現邏輯。

如下圖所示，作為DRD，你有必要傳達清楚Browse by category區域的設計：鏈接的可點擊性，鏈接的指向，字符與條目的數量限制等，但是具體二級類目排列是按產品數目排還是按字母排，還是人工運營，是FRD要解決的任務。

那么文檔寫什么呢？

交互細節說明

相信我，我很不愿意寫這些東西。我喜歡在會議室向各位涉眾演示我的線框圖，我會研究用axure制作各種動態效果，達到它足夠逼真呈現各種聯動——比如當你選擇了下拉菜單中的某項時，頁面上其他區域也發生相應的變化?？墒?，Axure不是全能的。即使能夠表達出來，線框圖交付出去，也不能確保其他人都能夠一一進行點擊嘗試。所以只能在會議室反復講解，在事后再三檢查并敦促修改。

但是當我嘗試用下圖對這塊小小且復雜的區域進行詳細說明后，事情變得簡單多了。所以我用節省的時間去寫了這份PPT.

五. 如何寫DRD?

選擇最有效率的工具。

我的經驗是這個工具最好能夠提供清晰的目錄導航結構，而且易標注。word確實是個寫文檔的好工具，不管你信不信，反正我是信了。