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

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

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

一、互動文件的基本認識

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. 主流的互動文件工具說明

主流的互動文件輸出有三種方式：

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 軟體來完成互動文件的製作，那麼檔案設定公開訪問許可權，再分享連結自然是最簡單的辦法。

但每次專案分享個網頁連結，或者並行有好幾個專案，需要其它成員自己去收藏網址，也是挺麻煩的。所以儘量充分應用軟體中的團隊協作功能，透過建立一個團隊，新增成員，讓他們自行檢視當前檔案目錄中的互動文件。

檢視過程中，團隊其它成員可以透過評論的功能對互動內容進行糾錯、提問、建議，方便我們進行最佳化改進。

透過這種簡單高效的文件協作模式，我們可以非常快得完成整體互動內容的定稿，並開始後續的工作。

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

互動文件的最佳狀態是 ——

應用最終介面圖例解釋互動內容

。

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

四、結尾

以上就是關於互動文件的相關解釋，下一篇，我們會聚焦在和表單有關的互動乾貨分享。

我們下篇再見。

作者：酸梅乾超人；公眾號：超人的電話亭（ID：Superman_Call）

本文由 @超人的電話亭 原創釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash ，基於 CC0 協議。

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供資訊儲存空間服務。