交互文檔該怎么寫呢？這個問題不只是新手在問，在工作中要負責交互問題的產品經理、設計師，都在糾結這個問題。本篇文章就從基本認識、工具選擇和制作過程這三部分內容來為大家講解交互文檔要怎么寫，快來看看吧。

今天要分享的，是后臺和社群里幾乎每天都有人問的交互文檔該怎么寫的問題。不只是想要往交互設計師方向發展的新手，還有工作中要負責交互問題的產品經理、設計師，都對它存在大量的疑問。

所以我們在今天這篇分享里完成一次深入的掃盲。

一、交互文檔的基本認識

1. 交互文檔是什么

交互文檔，是一份用來解釋項目交互方式、內容、規則的說明文檔，也叫 DRD ( Design Requirement Document )。

在過去的分享中，我們有解釋過，B端項目會包含大量的交互內容，需要前期繪制交互原型來展示和確認交互方案。

如果是比較簡單的小型項目，或成熟產品的小迭代，那么這樣的連線圖確實就足以表達交互的意圖和方案了，寫太多注釋文字反而會畫蛇添足提高觀看者的認知成本。

但是，如果項目和展示的流程內容，邏輯非常復雜，包含非常多的選項和狀態，那么單靠原型和連線是絕對不夠的，添加更多的圖文說明就變得非常有必要了。

同時在團隊協作場景中，就需要將這些內容制作成一份規范的 “文檔”，用來進行統一的展示、備份、歸檔。

所以做交互光靠畫交互原型是不夠的，“文檔” 就成為必要的輸出成果。

2. 它和產品文檔的區別

在產品側（非開發），文檔就有好幾類：

• 商業需求文檔：BRD,Business Requirement Document
• 市場需求文檔：MRD,Market Requirement Document
• 產品需求文檔：PRD,Product Requirement Document
• 交互說明文檔：DRD,Design Requirement Document
• 設計規范文檔：DGD,Design Guidline Document

BRD 和 MRD 是一個產品經理行業內部也在反復科普討論的東西，和我們沒多大關系可以暫時忽略。設計規范文檔 DGD 大家應該也有概念，比較容易辨識，也不需要在這里強調。

而產品需求文檔 PRD，是和交互文檔最撞臉的文檔類型。它們的文檔規格、樣式幾乎一致，還包含大量界限模糊、相互交叉的內容范疇，會對新手的理解造成很大的不便。

要理解產品文檔和交互文檔的核心差異，就得從他們各自的工作職能說起，產品經理的主要產出是解釋產品要做的功能和邏輯，所有的原型和連線的目標都是為了解釋功能本身。

部分產品經理會 “順帶” 在這個基礎上增加交互的元素，以及相關的說明。這恰恰是問題的關鍵所在，因為產品經理制作產品原型的過程是可以覆蓋一部分交互信息的，所以很多設計師也天真的認為交互內容是應該由產品來出的。

這當中一定要關注里面的 “順帶”，因為一份有效的 PRD 主旨一定不是以交互為核心的，在面對需要大量圖例、連線、方案、解釋的交互問題下面，產品經理往往選擇直接跳過，只把功能描述清楚，剩下的就交給交互設計師還是 UI 設計師來完成具體的交互方案。

所以，交互文檔就是在產品文檔的基礎上，進行交互內容的補充，專注于解釋項目的交互內容，讓設計師和前端開發可以更直觀得理解后續的工作內容。

來自 UEDART 的付費文檔，案例地址：http://vip.uedart.com/interactive.html

交互文檔和產品文檔是相互獨立和補充的，當產品文檔無法完成對產品交互的有效解釋時，我們就應該選擇輸出獨立的交互文檔，來提升項目協作的效率。

二、交互文檔的工具選擇

1. 主流的交互文檔工具說明

主流的交互文檔輸出有三種方式：

1. Axure/墨刀 導出
2. 一般文檔制作
3. 線上 Wiki 記錄

Axure 和墨刀是用來制作產品原型的軟件工具，也是目前在產品經理、交互設計行業中應用最廣泛的原型工具。

它的主要優勢，在于可以比較方便的制作可交互的組件、連線、導出。

當然，光制作原型圖并不能叫交互文檔，它們還提供了比較全面的內容標注、文本記錄、圖形繪制的功能。

這就可以讓我們完成原型繪制以后，結合頁面結構的管理，添加交互文檔所需的其它信息，并最終輸出文件。

而在一些比較傳統的行業或外包領域，使用的記錄文檔往往要使用 Word 或 PPT（方便開會演示或要打?。?。這就要在原型完成以后，導出原型圖例，并使用這些文檔軟件進行文字的記錄和連線。

受限于 Word、PPT 的布局限制（強行分頁），使用它們做交互文檔是非常難受的，并且這些文檔需要保存到本地，存在各種文檔版本管理的問題。

所以還有另一部分也希望使用普通文檔格式記錄，并滿足云端同步、備份、版本管理的團隊，就會使用 Wiki 類的工具來制作交互文檔。如語雀、飛書、Confluence、Notion 等工具。

如果只是一些比較小的項目迭代、一次性使用的交互文檔，使用前兩種方法都可以勝任。而真正大型、系統性的交互文檔，往往都使用團隊內部的 Wiki 進行創建和管理。和設計稿不同，這些使用了內部賬號或需要內網訪問的文檔資料，是不會沒事發到網上來分享的，這也是在網上找不到完整交互文檔的主要原因。

2. B端設計師的交互文檔工具建議

和你們網上可以找到的大多數交互設計干貨不同，我即不推薦你們使用 Axure/墨刀 來畫原型，也不推薦用它們或普通文檔、Wiki 的形式來輸出交互文檔。因為：

—— 太低效了！

產品經理和交互設計師的主要產出物就是文檔，自然可以耗費比較多的精力和時間去制作原型和編寫內容。而 UI 設計師的主要工作肯定是最終的視覺界面和交付，所以用最復雜的方法去制作交互文檔，顯然是不合理的。

同時還要提一句，Axure/墨刀 等軟件用來制作一般的線框圖原型，效率實在是太低了。且絕大多數情況下的頁面跳轉、交互都是可以忽略不做的。而且隨頁面增加，它的左側導航層級、數量會非常龐大，導致查找和瀏覽的效率進一步降低。

我始終都建議直接使用你們正在用的云端 UI 設計軟件直接繪制產品、交互原型并輸出文檔，如即時設計或 Figma。原因包含：

• 速度快：能用 Axure 五分之一的時間完成所有原型繪制
• 可復用：做好的原型方便復用，而且可以直接在原型上完成后續設計
• 交互性：對于表達交互流程所需的基礎跳轉和動效都能滿足
• 更自由：一些需要復雜圖文結合的說明方式不再受到普通文檔布局限制

比如下面這樣的原型案例，就可以通過一個簡單的鏈接快速分享出去，或者添加團隊成員自由查看。

在我過去長期的實踐體會中，這種方式是優勢最明顯、效率最高、最易懂，也符合 UI 設計師工作需要的。如果項目中有其它因素要求，你們也可以選擇前面的方式輸出。

任何文檔的目標都是為了書面記錄和讓看的人更容易理解我們要表達的信息，不要被固定的方法局限住，要努力去探索適合團隊當前場景的方式。

三、交互文檔的制作過程

1. 文檔框架結構制定

前面把基本的信息聊完了，這里就來具體講講交互文檔應該如何進行輸出。

當然，輸出交互文檔前需要先理解交互是什么，交互設計的具體設計內容和步驟。交互文檔是對你已經設計出來的方案的書面記錄，你不能在對交互一無所知的情況下強行編寫文檔。

交互文檔制作首先要確認文檔的記錄內容和文檔結構。

記錄內容指的是你在該文檔準備放哪些交互內容進去，并不是每次項目設計都要把項目所有頁面和流程交互都重做一遍。

比如一次中等規模的迭代，新增幾個通用的列表頁面，調整了一些細節字段，增加了一個功能流程。那么文檔重點記錄內容肯定就是流程而不是所有頁面。畢竟通用的列表頁和細節更改，在產品需求評審階段就可以完整的解釋，而功能流程則不行。

如果是全新的項目，包含數十上百個頁面。把所有流程、頁面的交互內容全部表現出來的工作量是頂不住的，在繪制原型的過程中，你就會發現有大量的重復頁面、流程和交互。所以制作文檔就要有目的性的對重復的內容進行合并，以及只保留重要的頁面和流程。

具體該放什么要考慮項目的實際情況，需要設計師自己評估。除此以外，標準的交互文檔里面會包含背景介紹、編輯日志、文字圖例、業務流程、名詞解釋、頁面結構等等。

這些 “文縐縐” 的細節，并不是必備的，你可以根據當前場景自己決定需要加哪些。比如項目、業務背景前面的產品需求已經講清楚了，業務流程、名詞解釋團隊成員也都了如指掌的時候，那么這些頁面模塊就完全沒有放的必要。

并且，基于前面對放置內容的考慮，結構的順序并不一定要類似下方案例，完全按照產品的導航目錄來走。

所以，根據一個中等規模的迭代項目，我會制定一個這樣的一級文檔結構：

• 基本信息：項目的簡單信息，快速目錄，參與人信息等
• 基本組件：涉及的相關組件展示和交互規則說明
• 原型一覽：本次迭代涉及的所有頁面原型和連線一覽
• 流程介紹1：流程1的所有頁面、狀態、說明展示
• 流程介紹2：流程2的所有頁面、狀態、說明展示
• 流程介紹3：流程3的所有頁面、狀態、說明展示

每個1級文檔結構對應 UI 軟件中的 Page 目錄，力求所需的 Page 數量越少越好，而不是像 Axure 的做法一樣密密麻麻的。

結構可以根據復雜程度做進一步的細分，它像寫文章的大綱一樣，幫助我們提前規劃好后續完成文檔所需的內容和工作量。

2. 關于連線和標注信息

有了結構，就要在對應的 Page 中填充內容了。其中一般的文字介紹、流程圖、思維導圖，只要正常輸入或將導出的圖例黏貼進來就可以。

而針對具體的交互內容，流程解釋上，則重點處理連線和標注說明。比如下面是我自己在課程演示中的一個簡單的交互流程演示案例。

在 UI 軟件中，制作連線其實是很簡單的事情，只要畫出一個直線，再設置箭頭和尾部圖形、描邊色彩和粗細即可。

然后，將該線段的圖層放置在畫布之外，起點放置在觸發交互的區域之中，終點尖頭則緊貼目標畫布的邊緣（不用特意延伸進畫布內）。如果使用水平、垂直的方式連接兩個畫布，那就可以雙擊進去添加錨點制作 90 度的折角。

連線的應用是非常簡單的操作，不要舍近求遠通過插件或是其它的一些功能來實現。而除此之外，我在文檔中添加的解釋性文本主要有兩種，交互事件和交互規則。

交互事件代表了連線的兩個頁面是如何被觸發跳轉的，所以我會在線段中帖一個文字卡片，解釋觸發的條件和交互操作是什么。

然后，就是頁面或流程中的交互細則，包含兩個部分，數字標簽和對應文字注釋。它們都是用 Auto layout 可以快速制作出來的組件，每次要做備注的時候，只要復制標簽到頁面上，設置對應的數值，再將右側的文字卡片復制到頁面旁邊，再加上對應的數字、內容信息即可。

在設計軟件中，畫布的自由度極高，你想要怎么備注和添加內容都沒關系，只要在內容翔實的基礎上保證 —— 團隊成員能看懂，就是一份優秀的交互文檔。多在繪制過程中和同事溝通，優化展示的做法，可以避免很多會出現的問題，進一步加速我們的制作效率。

3. 文檔的團隊協作應用

將文檔全部做完以后，最終就是關于交付和協作的問題了。

既然我們使用線上的 UI 軟件來完成交互文檔的制作，那么文件設置公開訪問權限，再分享鏈接自然是最簡單的辦法。

但每次項目分享個網頁鏈接，或者并行有好幾個項目，需要其它成員自己去收藏網址，也是挺麻煩的。所以盡量充分應用軟件中的團隊協作功能，通過創建一個團隊，添加成員，讓他們自行查看當前文件目錄中的交互文檔。

查看過程中，團隊其它成員可以通過評論的功能對交互內容進行糾錯、提問、建議，方便我們進行優化改進。

通過這種簡單高效的文檔協作模式，我們可以非?？斓猛瓿烧w交互內容的定稿，并開始后續的工作。

再回到前面的話題，我們是 UI 設計師，不是全職交互設計。原型文檔輸出完了，下一步可是要做視覺界面的，所以交互文檔就可以不用管了嘛？

交互文檔的最佳狀態是 —— 應用最終界面圖例解釋交互內容。

也就是當我們把所有頁面內容設計完成后，強烈建議將界面的展示和交互文檔進行整合。除了前端和產品可以看到最終的交互落地效果外（有時候最終設計和前面的交互不一致），還可以直接通過這個文檔查看界面數值標注，而不用往返于交互和設計文檔來回切換，這才能讓文檔作用最大化。

四、結尾

以上就是關于交互文檔的相關解釋，下一篇，我們會聚焦在和表單有關的交互干貨分享。

我們下篇再見。