最近一直在琢磨著交互文檔這個事。其實早幾個月前就整理了一部分，把自己給整自閉了就整平臺規範去了。好了，說了一堆廢話言歸正傳。

在做交互文檔之前，我們先要明白什麼是交互文檔、為什麼要做以及做了給誰看。

一、什麼是交互文檔

交互文檔，即交互設計說明文檔。英文 Design Requirement Document ，簡稱DRD。主要是用來承載設計思路、設計方案、信息架構、原型線框、交互說明等內容。

二、為什麼需要交互文檔

有些人可能對文檔這種東西比較反感，尤其是從事工作不久的朋友。其實工作得越久，越會發現文檔的重要性，它可以幫助你理清思路，並記錄下來，便於回顧。

工作上而言，有一份規範的文檔可以讓你的設計更有說服力，也易於工作對接，提高彼此之間的溝通效率。

三、交互文檔給誰看的

交互文檔其實要說給誰看，其實具體情況具體分析。有的公司老闆也要盯交互文檔，以及甲方爸爸、運營部門同事，都有查看的可能。不過有4類人，無論如何他們都必須是交互文檔的忠實“讀者“：

【產品經理】產品經理與交互設計師可能是溝通最多的人，產品經理主要在文檔中確認設計思路和業務流程，然後過一下頁面交互模塊。

【視覺設計】UI設計師通常最關注的是頁面交互模塊，有著產品思維和體驗思維的設計師也會仔細看一下設計思路和產品背景，以便於自己更瞭解產品業務邏輯和用戶心理。

【開發人員】前端的開發同事和UI設計師一樣，最關注頁面交互模塊，其他的作為提升會輔助瞭解。而後端開發人員關注更多的是業務邏輯、信息架構、操作流程等，這些都清晰了，他們才能輸出一份準確合格的開發文檔。

【測試人員】因為測試人員是把關產品上線的一群人，所以各個模塊、步驟都應該去了解透徹，才能提出有效的bug。

四、如何撰寫交互文檔

本文主要闡述以Axure軟件為撰寫工具，大家可以根據實際需求決定用什麼軟件（Sketch、PPT、Word、PS、AI 等）。比如小需求可以用Sketch，快而高效。如果是要給甲方爸爸/大老闆看的，使用PPT會讓他們更好理解。

沒有軟件基礎的設計師朋友可以後臺回覆“教程“即可獲得入門Axure視頻教程。

通常，一個比較基礎、規範的交互文檔（DRD）由：文檔封面、更新日誌、文檔圖例、設計背景/思路、業務流程、頁面交互、全局通用說明、廢紙簍八部分組成。當然，這不是絕對，你可以根據你的實際工作需要進行增減。

比如，如果是C端產品的話，用戶調研的結論、用戶畫像、用戶體驗地圖等等，都可以放進去給看的人一個參考。尤其是在如今這麼關注用戶體驗、產品思維的一個大環境下，這些數據支撐很有力量。同時還可以幫助開發人員、界面設計人員培養產品思維、體驗思維，大家一起將產品變得更好。

其次，交互文檔的整潔與美觀也很有必要。相信在過去幾年不少人有遇到過這樣的產品經理（兼交互），他們會輸出一些有時連他們自己都看不太懂或者直接從其它競品截圖來的線框圖。當開發和界面設計的人提出質疑的時候還美其名曰線框不重要，重要的是裡面的業務邏輯。。。其實用產品思維想，交互文檔就是交互設計師的產品，而看的人就是用戶，保持良好的可讀性，可謂至關重要。

交互文檔的封面如上圖，通常包括產品的名稱、Logo、版本號以及版本發佈時間、所屬部門、對接負責人/對接人。

2、更新日誌

我們都知道，在產品的迭代的過程中，需求/功能是會不斷調整的。而更新日誌，就是為了迭代而生。它一般由修改日期、修改內容、修改人、版本號和備註組成。如果是新增的功能或模塊，建議是要加上鍊接可直接跳轉至新增內容的，如上圖。

版本號也是同理，都應加上對應的版本鏈接，便於查看者回溯之前的內容，與當前的新版本形成對比。這一點對開發人員來說很重要，其次是對於新同事深入理解產品也能起到很大的幫助。

修改日期，通常是按時間倒序排列，查看起來會比較方便。

3、文檔圖例

文檔圖例，顧名思義就是關於此文檔的一些輔助說明，目的是為了讓讀者更好地理解文檔。如上圖的：操作/跳轉圖例、標籤圖例、流程圖例以及手勢操作圖例。

4、設計背景/思路

設計背景，根據實際工作需要，放置一些關於思路整理、靈感來源的文檔。比如用研報告、用戶畫像、競品分析報告、商業畫布等等。增強文檔的說服力，儘量讓每一個人都能理解到產品的戰略目標和業務邏輯。

因為我今年對接最久的是一個B端產品的項目，所以整理了一個產品畫像，以上僅供參考。

5、業務流程

業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程，例如淘寶APP，買家購物由至終的流程就是它的業務流程。通常用泳道圖的形式展示，多數情況下是由產品經理繪製。

以上是我所負責產品的核心業務的流程圖。因為是B端產品，涉及角色較多，針對3個代表性角色分別進行了繪製，僅供參考。(因為涉及到保密協議，所有關鍵詞都去掉了)

6、頁面交互

6.1 信息架構

信息架構屬於用戶體驗的結構層，是一個產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。

6.2 權限說明

如果是C端產品，權限這一塊相對簡單，比較好整理的。B端產品涉及角色眾多，可能要單獨拎出來分析整理。以上僅供參考，大傢俱體情況具體分析。若是功能很單一的產品，交互文檔中也可省去這個模塊。

6.3 操作流程圖

產品操作流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。

注：不要將所有流程彙總在一個表裡，或者展示在同一個頁面中，而應跟隨具體的操作或者功能模塊放置。時刻想著看文檔的人的感受，怎麼易懂怎麼來。

上圖是登錄、註冊和找回密碼的操作流程圖。僅供參考。

6.4 頁面線框圖

頁面線框圖，是通過圖形化的表達形式，闡述產品在頁面層面的信息。包括：

【頁面標題】即每一個頁面的對應標題，一般就是導航欄標題

【頁面內容】以黑白為主，保證信息規整、易讀即可

【交互說明】用標籤將其對應起來，包括交互邏輯、操作流程及反饋、元素狀態、字符限制、異常/特殊狀態、相關規則 等等

【主流程線】只需要畫出主流程線即可，千萬不可太多太雜，時刻考慮讀者的感受

以上是註冊的的頁面線框圖，僅供參考。

以上是登錄的線框圖和詳細的交互說明。將重點內容用紅色標記，可以讓查看者一目瞭然更好理解文檔。

7、全局通用說明

全局通用說明，指整個產品可通用或者複用的元素。一般是邊做文檔邊整理出來的，方便自己或者接手該項目的設計師直接調用。其次，對開發及時封裝可複用控件也是有參考價值的。

7.1 常用控件

常用控件類似UIKit，通常將極具複用價值的控制整理在一起，方便及時調用。

7.2 複用界面

顧名思義就是全局可複用的一些內頁，比如選擇聯繫人、獨立搜索頁等。

7.3 時間規範

在做產品的第一步，就應該約定一個時間規範。不然各個端開發出來，你會發現iOS是斜槓的，Android是橫槓的，WEB是圓點的...真到了發現的時候再改，那真是彼此都是無比崩潰的。

7.4 缺省頁彙總

缺省頁一般包括加載失敗、加載中、網絡中斷和無數據的空頁面。為空頁可以按照模塊整理在一起，方便UI設計師最後一起設計缺省頁，保持風格統一。

8、廢紙簍

廢紙簍，被稱為是交互文檔的“後悔藥”。在需求不斷變動的情況下，改改改的過程中，請把你改過的稿子，放這裡！！！因為很可能最後還是用的第一個方案....（此刻內心有點絕望）

五、總結

文檔、軟件只是工具，最重要的還是要落地、實行起來才能對產品有所幫助。所以在撰寫文檔的每時每刻，都應該站在“讀者”的角度思考，他們看的時候感受會是怎樣的，會覺得很難理解嗎？除此之外，還需要有耐心，耐心給他們講解理解不透徹的地方。用一個朋友的話總結下：好的設計都是本虐出來的。（其實幹哪一行不是呢...）

本文旨在提供參考，並非規範，還望拋磚引玉，多多交流。

閱讀更多 宛蘇 的文章

關鍵字: Axure 設計