在一個項目中，交互設計起著承上啟下的作用。一份好的DRD應包含哪些內容，注意哪些方面呢？讓我們一起跟隨作者看看吧。

這是一篇在2017年就已完成的關于交互文檔的規范性總結，當時要給咱交互組做交互規范及分享，其中包括“交互設計師的工作流程與規范”、“產品架構”、“交互流程圖”、“交互文檔規范”、“交互自查清單”等。部分總結已在組內分享或推動～今日甚是涼(xia)快(yu)，忙碌了一天，拿出電腦打開了這份總結，決定更新更新，也許對咱UED組日后的工作或交流有所幫助，順手放這兒跟小伙伴們交流交流～

一、什么是交互文檔？

交互文檔，即交互設計說明文檔。英文“Design Requirement Document”，縮寫“DRD”。用來承載設計方案、交互原型、交互說明等內容，存檔并交互項目相關伙伴的團隊協作文檔。

二、為什么需要交互文檔？

你也許會說：“產品經理就可輸出DRD，無需交互設計師?！钡鋵?，許多交互設計師也可承擔產品經理的角色…balabala此處省略1萬字～只要你夠優秀，CEO都成！說白了，崗位名稱不過是對工作職責的劃分而已，是公司或部門提高專業性和工作效率以達到公司目標的一種方式罷了～（瞎說什么大實話，人家也是個有態度的射擊獅?。?/p>

言歸正傳，作為交互設計師，工作職責起到“對接上下游，承上啟下”的作用，不論是在方案評審的講解，還是日常的工作溝通，都應具備優秀的語言表達和DRD表達能力。

而DRD不僅能完美闡釋產品內容和設計思路，還利于設計規范與統一，讓產品保持一致性，在項目各方協調工作中起到重要作用，也方便后期進行項目總結。

因此，DRD是利于團隊協作的媒介，也是產品規范與項目總結的重要輸出物。

三、都有誰在看交互文檔？

業務方/需求方：包括產品經理/運營經理，這里大多指產品經理。

Ta們會通過DRD關注你的設計方案是否滿足業務和用戶需求。交互設計師與Ta們討論產品規劃及業務需求后，結合用戶需求，分解關鍵因素，最終歸納出設計需求。而DRD正是整個設計思路的闡述媒介。

視覺設計師：這里包括視覺和UI設計師，或包括動畫設計師。

Ta們需知道產品定位是怎樣的？有哪些頁面要設計？頁面間的跳轉是怎樣的？各頁面各元素包括什么狀態？遇到特殊情況（數據加載、網絡異常、極端情況等）如何設計？

開發人員：包括iOS、Android、H5、Web等前端開發工程師和后端工程師。

Ta們需從DRD知道，產品要實現多少功能？多少頁面？如何去實現？頁面間是怎么跳轉的？異常情況怎么處理？… 然后用代碼將其實現出來。

測試人員：包括測試工程師和參與測試的其他人。

Ta們需參考DRD梳理測試用例，測試用例須覆蓋所有功能、使用場景、操作行為、產品細節，須保證上線無bug，或是少bug狀態。

后續相關人員：如客戶經理和客服專員等。

Ta們需對業務和產品足夠了解，方能更好的展開后續工作。

四、交互文檔的結構和內容

那么，一份好的DRD應包含哪些內容，注意哪些方面呢？以下是我整理的DRD輸出思路，僅供交流或參考。內容源自工作經驗的總結，源自同事的溝通及反饋，源自過往閱讀過的相關文章的總結。

4.1 撰寫交互文檔用什么工具？輸出什么格式？

你習慣用什么工具撰寫交互文檔？PPT、Sketch、AI、Axure?… ？

你習慣用什么格式輸出你的交互文檔呢？PPT、PDF、HTML …？

我也會問自己同樣的問題，什么工具和格式才是最好的呢？實踐后，總結如下：

若是大項目或復雜的大需求，推薦Axure輸出HTML格式。

Axure含有站點地圖，可清晰展示層級關系，可很好的完成場景的跳轉。還可通過分享鏈接，實時更新，協作更方便。

若是小需求，推薦Sketch輸出PDF格式。

\Sketch畫原型效率高，輸出PDF，美觀、全局、不易看漏內容，無設備和網絡限制，方便閱讀。但無站點地圖，故不方便大項目/大需求的閱讀。

若是方案概述，推薦PPT輸出PPT格式。

PPT無使用門檻，方便高效，看上去較正式、美觀，無設備和網絡限制。但一頁PPT放不了幾個界面，且無站點地圖。

4.2 交互文檔應包括哪些內容？

DRD可根據公司或項目實際情況來定內容、元素和樣式。這只是我工作中整理的較通用的文檔結構模板：分為文檔封面、更新日志、文檔圖例、設計背景/思路、整體業務流程、頁面交互、特別說明、廢紙簍等部分。

DRD封面

[該圖片不商用，若涉及侵權請聯系本人]

DRD封面：包括文檔標題（項目/產品名稱）、版本編號、發布時間、作者等基本信息。按需可增加參與該項目的各方負責人。（如：產品經理，交互設計師，視覺設計師，開發，測試，團隊名稱等）

更新日志

更新日志，包含具體新增或修改的內容，修改人，修改日期等信息。在實際工作中，方案的修改和優化是不可避免的。更新日志方便項目成員一目了然關注到重點更新的內容，也方便開發找到對應的負責人進行溝通，提升工作效率。

其他細節經驗分享：

1. 文檔更新的日期按最近更新的排最前（最好還能用顏色區分一下）。這樣不會因日志過長需要找太久；
2. 最新修改的頁面可點擊直接跳轉至相應頁面。方便更快找到對應的文檔頁面。

文檔圖例

針對你在該文檔所用到的圖例進行說明，輔助閱讀。尤其對初次接觸你DRD的人來說，助于對方理解你的文檔，尤其是一些非通用的標識。

設計背景/思路

可包括一些項目背景、需求分析、用戶調研、競品分析等。用于設計思路的整理和記錄，方便閱讀，方便參與評審會的人理解整個項目背景下的設計思路，也方便日后回溯和總結設計。但無需將所有的分析內容都放入，結構化整理重點內容放入即可。

需求分析應包含業務需求/功能需求，用戶需求，和對需求的分析與歸納。下圖是隨手舉例，僅供參考：

業務流程圖

主要是整體的業務流程圖。工作中，大多是產品經理撰寫，經由交互設計師溝通和整理放上來（本次不做具體分享）。該流程圖也可根據具體項目進行位置調整，例如跟著頁面交互的模塊或流程走。

頁面交互

頁面交互，是DRD的主體。包括信息架構、任務流程圖、界面交互圖、交互說明等。頁面交互的結構，應根據產品信息架構搭建。要求功能層級要清晰，命名合理，格式統一，更新的內容統一標識，方便他人瀏覽查找。

1.?信息架構：是整個產品的骨架，它相對穩定，動到信息架構的需求，一般都是新產品、新功能或產品大改版。信息架構圖可幫助我們在前期梳理整個產品的結構，后期按照大的架構來迭代，同時讓信息更易理解與瀏覽。

構建信息架構，需根據產品特征確定結構類型，明確功能優先級，根據其重要度、商業價值、使用頻率等排序，將重要功能抽提出來。還需考慮可擴展性，方便后期迭代優化。

2. 任務流程圖：即分任務用\圖形化表達產品邏輯關系的步驟和過程，指用戶使用產品中操作后的各種結果反饋等。

你需完全了解需求，站在用戶的角度去考慮和引導用戶完成用戶目標，關注用戶的操作不僅可以讓你的思維更清晰，還可避免有操作邏輯的遺漏。也能讓其他人能快速地理解。

其他細節經驗分享：

1. 分任務寫，別把所有流程都寫在一個大流程里，不方便瀏覽，也容易遺漏或出錯；
2. 流程圖的“開始”和“結束”避免半天找不著；
3. 流程主次分明，順暢地瀏覽住流程，也能全面看到各流程；
4. 流程圖盡量簡化，流程線盡量避免繞來繞去，多流程指向同一結果可合并。

3. 每頁交互文檔的內容：

1. 文檔頁面標題：一般在每一頁文檔的頂部。寫明當頁內容是屬于哪個模塊或流程的，讓看的人不容易迷失；
2. 界面標題：注意命名，方便交互稿中的互相聯系，如“跳轉【XX頁面】”，“回到【XX界面】狀態”；
3. 界面：界面尺寸建議按實際界面的比例縮小，避免你想當然的設計并不符合規范，也避免一個界面太大影響閱讀效果；
4. 設計說明：邏輯關系、操作流程或反饋、元素狀態、字符限制、異常/特殊狀態 等等，都可以放在設計說明中；
5. 流程線：說明界面間邏輯關系；
6. 跳轉鏈接：指向其他頁面，例如某子流程，開發伙伴閱讀起來會很方便。

特別說明

包括一些需要特殊說明的內容，例如全局通用說明、缺省頁匯總、動效說明、音效說明等，根據實際項目而定。一方面，可保證設計規范性和產品一致性，在文檔頁不用每個細節重復說明；另一方面便于視覺設計和開發整體查看。這部分內容通常也被放在“頁面交互”結構內。

廢紙簍

廢紙簍，其實就是DRD的“后悔藥”。設計方案不斷調整優化的過程稿，本以為沒用的內容，都統統放這兒，以防后期可能用到。（改改改，你懂得～）

其他細節經驗分享：

“廢紙簍”后面最好備注下“忽略不看/僅UE查看”。否則很有可能會有不明所以的人兒跑過來問你，這個頁面和前面哪個才是最新的……

4.5 其他小經驗分享

1. 別為了寫文檔而寫文檔，要為了解決問題。

開頭提到DRD是用來承載設計方案、交互原型、交互說明等內容，存檔并交付給相關人員參考。因此，別為了寫文檔而寫文檔，要解決實際問題。

2. DRD要做到邏輯嚴謹，文本簡明

DRD的內容結構、頁面交互的結構需思路清晰，邏輯嚴謹，符合產品架構的層級關系。文檔內容書寫要邏輯嚴謹，簡明扼要，將交互設計的思路和方案更好的可視化和簡潔化。

3. 美即適用，注意文檔的體驗

DRD也要考慮美？答案是肯定的。

DRD也是給人用的，也應注重用戶體驗。另外，自己在其他方面的能力（如邏輯思維、產品創意等）有出色到能蓋過自己在表現層上的缺點么？若有，那你大可不必過于在乎形式。不過DRD“美”的定義和視覺不太一樣，它應該是美觀、清晰、易用、符合用戶體驗原則的，它更偏向于一種邏輯美，一種體驗美。

4. 在做方案時，先考慮和做完正常情況，再開始畫所有異常頁面或內容。

因為從整體開始做，中途老大或需求方想看方案就能有階段性完整的方案可看了；另外，大流程和頁面都沒確定的話，再細又有啥用呢？

5. 一頁交互文檔一個任務/流程。
每一頁能展示的內容有限，若堆積過多，會成問題；另外，也方便形成通用的任務/流程

6. 同一界面/頁面的不同狀態最好在同一頁交互文檔展示。
以免造成修改或閱讀混亂。

7. 交互原型盡量使用黑白灰。
避免原型圖對視覺設計師產生干擾，影響視覺發揮。另外，若顏色和視覺稿不一致，測試會來問到底用哪種～

8. 對齊讓文檔可讀性更好。
界面與設計說明的對齊、界面和界面間的對齊，會使文檔閱讀性更好。

五、總結

交互文檔很重要，但其核心并不是單純的形式美，交互設計師最重要的是在做設計時多方面思考。

（本文雖未對“需求分析和設計思考”著重筆，但真的真的真的很重要?。?/p>

多了解了解業務需求，多問問為什么，多找找最根本的問題，總結核心的業務需求，挖掘用戶最根本最真實的需求……

面對這些需求和問題，有哪些解決方案？哪個方案更優？還有更優的解決方案么？當設計師養成把所有的都考慮清楚，然后權衡取舍。就可以把產品的用戶體驗做的更好，自然也就能做出一份高質量無邏輯問題的DRD了。

如此一來，你的方案做的怎么樣，一看DRD便知，而你的DRD好不好，一看便知～

作者：Tricia（微信號：WX2225788009），YY歡聚時代交互設計師，前UI設計師。

本文由 @Tricia 原創發布于人人都是產品經理?，未經許可，禁止轉載。

題圖來自 Unsplash ，基于 CC0 協議