交互設計師的工作雖不只是畫交互稿子，但是好的交互稿不僅能夠完美闡釋產品內容和設計師的設計思路，還能夠在項目各方協調工作中起到重要作用。保證完整的呈現產品需求和設計思路的交互稿，能夠讓各方工作人員有一致的工作目標，而有良好體驗的交互稿，還能夠便于各方理解，提高后期開發對設計的還原度，提高各方工作效率。

對于一個設計團隊來說，統一的文檔規范和設計規范，不僅能夠減少合作方的學習成本，提升設計師和設計部門影響力。即使產品不同需求不同設計師不同也能夠帶給前后端、底層和QA們一致的文檔體驗。

或許每一個設計團隊都有自己內部的交互文檔規范，而且不同類型或量級的產品部門可能交互設計文檔的體量和組織方式都是不同的，我們設計部是一個剛滿一周歲的寶寶，部門里的設計師也都是設計行業的freshman，但是我們也在這一年中不斷地積累和學習，提升設計文檔體驗，構建了組內的設計文檔規范，以下共享，互相交流學習。

一、結構篇-交互文檔目錄

無論對于大型產品還是中小型產品，文檔目錄均需要有清晰的頁面結構，無論以何種形式展現，整體交互項目應盡量包含明確的修改記錄、交互規范、全局性設計說明、業務設計等。

1. 便于查找信息的修改記錄

（1）明確的迭代上線日期

前后端、QA們能夠對產品迭代內有有一直的認識，清楚哪些是自己某一個迭代要按成的事情；

（2）業務需求及對應設計師

便于協作方進行工作分工，并能夠隨時找到交互設計師；

（3）修改內容以及前端開發人員

明確寫明什么頁面修改了什么內容，或者一個需求增加哪些頁面，便于協作方了解設計細節內容。寫明前端開發人員，則有助于幫助自己和QA們找到對應功能點的前端開發人員是誰（我在一個迭代中可能對接好多個前端人員，具體哪些需求點是誰實現的是記不住的，太笨了～）。

2. 全局頁面說明和全局交互

全局頁面說明主要包括Z軸內容層級，X軸和Y軸適配方案、整體跳轉邏輯等，這些均需要在產品研發前期周知前端、視覺等協作同事的。準確傳達自己的整體產品設計思路，便于他們進行框架搭建或者視覺定義。另外還可以指導后期復雜需求的交互設計。

全局交互則是為了組件化設計，不僅保證產品設計的一致性，也能夠提高視覺和開發工作效率。

3. 全局性方案

全局性方案不僅包含404／403方案、全局請求異常、空狀態、頁面／信息流加載方案等，還包含一些業務全局性方案，比如平臺性的欠費停服流程（所有產品模塊均需要）。

二、布局篇-交互文檔布局

1. 單頁面文檔設計

我們組做的基本都是 Web 端的設計，由于每一個頁面的內容比較豐富且交互邏輯復雜，所以逐漸形成了每一個文檔頁面只做一個頁面的設計的規則，保證設計文檔中的頁面與真實產品中的頁面一一對應，便于交互文檔按照產品業務組織和減少協作方查找內容時間。

單頁面設計其實與一個頁面只講一件事情的設計方法相通，在表述本頁面內的設計內容時要說明清楚每一個與其他頁面關聯的用戶接觸點從哪里來到哪里去，保證開發、QA們閱讀交互說明的時候能夠理解當前頁面內容與其他內容的關系。

2. 統一頁面內容布局

作為交互文檔，它的目標用戶比較明顯的主要是與我們協作的前后端開發、QA們、視覺小伙伴，其實我們可以很簡單的就了解到他們幾乎90%都在使用公司配置的顯示器，公司配置的顯示器基本尺寸微1920*1080，所以便可以根據顯示器的尺寸定義Web頁面大小、交互說明顯示區域等，這樣便可以盡量保證在首屏內顯示相關內容。

另外，根據向開發了解，他們較為習慣Y軸方向瀏覽信息（其實感覺大部分人都喜歡Y軸方向瀏覽信息），因此文檔頁面和交互說明布局以縱向為主，在他們單方向瀏覽時，保證所有交互點都能看到。

• 頁面頭主要包括頁面名稱、設計師信息和時間信息；
• 主頁面可在Y軸方向延伸，X軸方向盡量不做延伸，但是不排除有特殊的業務需求需要在X軸方向做延伸（比如運營平臺中有強需要在表格中橫向顯示十幾項信息內容）；
• 交互說明主要包括交互點編號和交互邏輯。

三、色彩和字體篇

1. 盡量使用灰階色

不少交互設計師做交互稿的時候是非常認真的，會盡量做高保真的設計，有藍色或綠色按鈕、橙色的警告圖標等，有時候還會直接用視覺設計定義的視覺色彩規范去做交互稿，呈現出完美的交互稿，說實話真的是很漂亮的交互稿，幾乎不需要視覺設計師做什么修改。這樣完美的交互稿卻在無形中對視覺設計師、開發、QA們造成了困擾。

就這個問題，我跟對接的視覺師有過深入的溝通，對于視覺設計師來說，在交互稿中出現的那些彩色其實會對他們做視覺設計造成一定的干擾，表示不同明度的灰色調其實是他們能夠理解到交互設計師所要表達的意思的。另外，交互稿中彩色內容還會成為視覺焦點，跟開發和QA們有溝通過，他們表示這會無形中會干擾他們對交互邏輯和細節的關注。

就這個問題，我們總結了一些灰階色使用的大致范圍，基本來說明度低于#333灰色是盡量不用的，大面積背景是盡量不使用明度地獄#999的灰色等一些原則，也能盡量讓交互看起來干凈整潔和有一定的美觀度。

2. 統一字號和字體

對于字體，其實沒有特別的要求，只要統一字體即可。我們組內統一使用微軟雅黑，選擇這個字體純屬因為它是無襯線字體，看著簡單，而且微軟雅黑是各瀏覽器適配系統字體時的常用默認字體。

對于字號，倒是有些要求的，比如正常頁面文稿中不得使用小于12px的字號，通用字號為14px，強調可用加大字號和加粗解決。字體中有一個正常頁面文稿唯一可以使用的彩色，即警告色#ff6666（彩色也盡量使用飽和度較低的彩色）。

四、內容篇

前面說了很多見面展示的東西，內容上的話主要是交互頁面和交互說明了，這是個比較復雜的事情，要針對不同類型的業務需求做出不同的頁面設計，我就簡單說一下需要注意的幾個細節點吧。

1. 不同類型的需求應有不同的方法呈現設計

我們都知道，產品需求大致可以分為兩大類：任務型和信息型需求，針對不同類型的需求要能夠通過一些基本的設計方法去呈現我們的設計。

比如對于任務型需求，我們可以提供必要的流程圖去幫助開發和QA們更好的理解用戶在完成任務的過程中可能會走到哪里，有助于他們進行研發設計和測試設計。那么對于信息型需求，則提供信息結構圖和業務架構圖，讓他們在宏觀上能夠更好的理解需求。

2. 交互說明應便于閱讀和查找

交互說明中盡量字體稍微大一些，，交互說明的字體大小我們使用的16px，比一般字體會大2px，這一方面可以區分交互說明文案內容和頁面內容，另一方面也便于開發和QA們閱讀。

面上內容與交互說明的組織方式可以有很多中，比如畫上連接線、編號標記等。我們組目前做的業務需求還是都比較復雜的，考慮到不想讓頁面變成編織網一樣的東西，便采取了實用編號標記的方式去組織交互說明，如果交互說明中出現不同內容的點需要再次寫交互說明的時候，編號采用N-N的形式，交互點鐘每一條交互內容以中劃線開頭，交互內容中如果再有分級，便可使用無序編號等等，依次類推下去。

如果交互說明中出現與其他頁面的關聯，著重標出來，這樣便于開發和QA們在閱讀的時候能夠很快定位跳轉或回跳頁面，明確本頁面與產品其他部分的關系。

3. 交互說明應具有邏輯性

邏輯性或許是每一個設計師的必備屬性，我們使用MECE也好，使用邏輯樹分析法也好，都是讓我們能夠遍歷或窮舉我們想要寫的交互點的各種情況的。這里我主要想說的是要真正的具有邏輯性，我接觸的一些設計師，雖然也能對一些用戶接觸點做處詳盡而無遺漏的說明和解釋，卻經常會出現說此言彼的情況，使得交互說明冗雜而不易閱讀。而真正的具有邏輯性，是能夠清楚自己在每一個用戶接觸點上想要說明的場景和處理方式，盡量減少各個用戶接觸點的交叉說明，保證交互說明思路清晰而內容詳盡。為此我也總結了一套簡單的方法，即PTC4，此處先簡單的說明下，以后會專門介紹一下這個方法。

4. 交互流程應具有封裝性

封裝性的概念其實來源于研發中代碼封裝的概念，說的是如果一個方法被封裝好了，當使用到這個方法時，只需要傳入不同的參數便可以得到想要的結果。這里我引用到流程的封裝上，一個全局性的需求流程可能是不一樣的，定義好變量參數，便可以在不同的模塊調用這塊邏輯。這是比較符合開發們設計代碼的主要思路的，所以和研發們解釋起來是非常順暢的，而且能夠減少重復設計。

作?者：李田莉，網易蜂巢交互設計師，做交互，會視覺，懂產品，了開發，不可多得的全（wan）棧（mei）設計師。主要負責網易蜂巢的交互設計工作，掌控各種復雜技術型B端產品的設計秘籍。

本文來源于人人都是產品經理合作媒體@網易UEDC，作者@李田莉