交互設計文檔分為兩個版本：一個是界面元素標注版，另一個是附帶交互邏輯版。那么，具體的寫法和要求如何呢？

為什么要寫這篇文章？

寫這篇文章之前，遇到過很多朋友問道：『交互設計的輸出物是什么？』 、『交互設計師怎么與程序員協作？』、『交互設計師還需要出文檔？』等等一些問題。

更多的人在尋找一個交互設計文檔的寫法教程，每一個人的回答都不相同，但是很多入門的交互設計師遇到這個問題時覺得很棘手，因為不清楚自己應該如何寫一份符合自己產品業務邏輯或產品規范的設計說明文檔。

這篇文章就是給這些有很多疑問的同學寫的，可以解開一些疑問，但是指望這篇文章就寫出高質量的文檔顯然不可行，所以看完這篇文章后可以從中提取一些思路，自己整理一個屬于自己的設計文檔規范寫法的模板，長期積累下來，就可以形成自己的設計風格和規范。

什么是交互設計文檔？

我們先來統一一下概念以及名詞，以免后續因為說法不夠一統造成誤解。

交互設計文檔一般是指：交互設計說明文檔（交互設計師產出的規范文檔），又稱DRD（Design Requirements Document），工作中一般稱之為”交互設計文檔”。

為什么要寫交互設計文檔？

如果問不寫交互設計文檔可以嗎？

答案是：可以不寫，那么寫與不寫的區別究竟在哪里？?我們從兩個方面分析一下。

1.可以不寫交互設計文檔的情況

下列情況是目前很多公司存在的情況，既沒有專職交互設計師，也不出文檔，但他們也在做產品，這些情況有可能不需要寫交互設計文檔。

• 產品沒有交互設計環節
• 團隊沒有交互設計師角色
• 交互設計沒有系統化和規范化
• 開發邊界不需要控制
• 產品沒有動效或交互細節
• 有經驗豐富的產品經理
• 產品沒有復雜的人機交互邏輯
• 產品只有一個產品經理或負責任的角色主要負責

2.要寫交互設計文檔的情況

下列條件具備后寫交互設計文檔更具意義：

• 產品有清晰的交互設計流程
• 產品團隊中有專職的交互設計師
• 團隊已有系統化和規范化的作業流程
• 開發實現交互設計時需要定義邊界（驗收標準）
• 產品有比較復雜的、豐富的動效
• 產品有較為復雜的人機交互邏輯
• 產品有多個產品經理或部門協作

寫交互設計文檔的作用就很清楚了，如果要寫這樣一份文檔最大的好處是，可以非常清楚地幫助程序員認知做出的產品是什么樣子的。

看個小例子：

V1.0 沒有交互說明文檔的版本（可能由產品經理PRD代替）

產品需求的描述是這樣的

需求說明：在封面圖片上點擊圖片之后翻轉一圈。

（文字描述交互與需求）

開發人員根據這句話腦補怎么翻轉？360°？從左邊還是從右邊？轉速怎么樣？這些都需要找PM問清楚，如果遇見專業的PM還可以能講清楚，但如果遇到經驗不足的PM，就會說讓開發人員你看著做一個就行……。

V2.0 沒有交互說明，但是有UI設計的版本

UI設計出圖是這樣的

對于需求和期望達到的效果，靜態可視化的說明要比純文字更容易理解，需要給開發人員一個具象化的目標，否則程序員做出來的東西很容易與期望目標偏離，即想要的A而開發給的卻是B。

V3.0 交互原型加演示DEMO

動態demo：

輸出HTML文件預覽

小結：編寫交互文檔是為了將更豐富的人機交互動作、事件準確地傳達給開發人員，確保實現邊界。

若只是語言或靜態圖片交付給開發、測試人員，那么他們很難構建一個產品形態，不好把控開發方向，另一方面，交互文檔也是給參與項目的其他人快速了解項目的背景，不用到處詢問設計細節。

其實寫作交互設計文檔最大的好處在企業管理層面上，產品的交互設計文檔作為產品資料入檔，后續人員變動后，新來的人可以快速掌握整個產品的核心設計。減少人員無謂的溝通，不過有一點，這個文檔要及時更新，有變動要發出更新日志，不然還是少不了同事之間的語言溝通。

交互設計文檔由誰來寫？

誰來寫這個文檔本來不是問題，顯然誰是交互設計師誰提供這個說明文檔，但是，因為一些別的原因導致這成了一個問題。
比如：有些公司沒有交互設計師這個職位，所以不論崗位劃分如何，如果你的團隊中有人負責交互設計這個角色的工作，那么這個文檔就是屬于這個角色對應的人員來提供。

也有可能交互設計的工作被劃分給了UI設計師，所以越來越多的UI設計師改了自己的Title為：UI/UE 設計師。

交互設計文檔要給誰看？

根據項目組角色來定需要提供給：PM、開發人員、測試人員、需求人員、業務方人員等。

交互設計文檔更新機制

有任何一處變動需要更新到說明文檔中，就需要通過團隊的溝通渠道發送通知，我們公司是SVN服務器，設計師更新了設計文件版本或說明書版本后會同步到SVN服務器后生成最新地址與日志記錄后發送郵件抄送相關項目團隊人員。

更新記錄如下圖：

交互設計文檔要寫什么內容？

我不想說一大堆高深的理論，那么下面的內容我會按照實際流程幫助大家梳理出怎么制作文檔。

很多同學在新建一份空白文檔后不知道具體寫什么內容，如前面所說，對于一份交互設計說明書，你只需要把原型截圖或原型直接畫成一個文檔即可。

其實交互文檔就是頁面文檔，所有的軟件頁面、狀態都分離出頁面進行展現，然后加入頁面流程和交互動作說明文字、箭頭指示線條等。

關鍵點：邏輯結構、頁面跳轉、交互狀態的文字說明，統一交互體驗動作，確保頁面組件的一致性。?

小例子：?交互設計說明文檔截圖

這是一個包含交互界面動作、邏輯步驟、頁面流轉、文案與注釋的實例，圖中的交互動作說明是將所有出現的靜態化界面的內容寫在文檔里進行展示。如果你想直接展示動態交互，可以使用原型設計工具設計好交互原型之后再截圖編輯文檔，交付文檔時配合著原型（導出HTML）演示，這樣會更有效率。

交互設計說明書的文檔結構：

版本信息一般包括版本、日期、參與人、變更內容簡要、備注信息。

目錄

這個無須多說，平時我們看的書基本都有目錄，不過記住目錄要合理分級以分清主次。

Log更新記錄頁

這個頁面是用來描述某次更新的信息簡介與頁碼導航等。?下圖為交互設計說明文檔的更新記錄頁的示例：交互設計說明書的更新日志?。

交互設計說明書的更新日志

交互行為邏輯圖+文字說明

下圖某一個應用商店的更新應用交互邏輯+文字說明圖例。

交互設計說明書中的交互邏輯頁面流程

從上圖中可以看出，這個說明文檔是把應用更新功能拿出來當一頁，包括它的架構、交互、流程、邏輯、交互事件及文字解釋說明。?這個過程是針對產品經理和程序人員而言的，因為他們需要看明白交互流程邏輯。

頁面展開圖+邏輯+文字

下圖是頁面、元件、文案、邏輯、頁面狀態的展示：

交互設計說明書的頁面元素

這個部分是針對視覺而言的，需要將所有的頁面都展開解釋一遍，共用部分可以單獨標記。

其他單獨的交互動作詳細解釋介紹

此部分是對不在流程里的單獨的或獨立的交互的補充書寫的。

交互設計文檔的責任邊界

一般情況下，如有需求變更或流程更改，就需要同步更新交互設計說明書并發送給相關同事，同時要抄送給對應項目的測試與產品人員，此文檔加上PRD也是最后的驗收依據，所以中途變更需要記錄log。

給交互設計師們總結一下：

1. 給程序看，使用獨立的章節寫明交互邏輯、頁面流轉
2. 給視覺看，使用獨立的章節寫明所有的頁面展開、公用頁面交互等
3. 給測試看，加好注釋與說明
4. 交互需要按照功能邏輯一個個排著序寫，這樣更容易理解
5. 交互事件的狀態需要用截圖形式展示出來，不建議使用大量文字描述，因為很多人不看小字而是直接看圖

作者：阿西UED，微信號：Hello_Wangsir。

內容節選自《交互設計那些事兒》，有興趣的可以去京東、天貓、當當搜索 《交互設計那些事兒》以了解更多，具體案例在這本書的第八章。

本文由 @阿西UED?投稿發布于人人都是產品經理。未經許可，禁止轉載。