一、事情起因

工作特殊性，我所在的組做的事情是在另外一個組產出的設計稿基礎上去和客戶對接，基于客戶的要求提供定制化服務。所以一旦有新的設計改版升級，我們都需要讓另外組的設計師們提供交互文檔，然后我們基于這份文檔來繼續后面和客戶對接的工作。

然而當我們接收到了新文檔打開后，懵了！禮貌的詢問對方：“請問這個是過程稿，還是最終稿”？因為簡直「太亂了」，導致我看文檔看的非常費勁，即時花了大力氣因為文檔亂以及信息確實，最終也沒能了解功能具體如何運作。在一個大家熟悉產品的設計團隊下，產出這樣的交互稿著實讓我吃驚~

這里面的亂主要有以下幾點：

1. 文檔無主體結構，標題不統一
2. 內容未分模塊講述，相互穿插，無集中講述
3. 內容呈現邏輯弱，無從大-小講述
4. 頁面信息多且雜亂，包含：更新信息、待確認信息、分析信息、會議紀要...和設計界面無關的信息
5. 規則描述不完整且板式混亂

更多干貨：

二、交互稿最基礎要達成什么程度

交互稿絕對不是必須要做的非常漂亮，但絕對要「清楚」

因為交互稿承載的是功能、產品界面以及如何運轉的（包含頁面流轉、規則、樣式、反饋...)。需面向 PM、UI、RD、QA 全流程工作人員進行查閱的。正常一份可讀性好的交互稿，其他人一看大概就知道你產品、功能具體是啥樣的。

至于說交互稿到底要做到什么程度，我們可以拆分來看看看

1. 刪除不必要信息

對外交付的設計稿需刪除和具體頁面之外的信息，諸如：分析、溝通結論、會議紀要、競品分析、用戶分析等等。因為你交付出去的是最終確認的，比如開發同學只需要看最終明確的設計及規則即可，這些分析過程可以放在畫板外面供自己或團隊查看即可。對于一些設計目的或者目標什么同樣內部匯報可以放，當時交付出去的時候可以移走。

2. 頁面模塊劃分及標題

根據實際產品，對功能模塊進行劃分，分別針對單一模塊進行詳細的呈現。并且對于不同的界面需要有對應的標題。

3. 交互說明要盡可能完整和統一

頁面的交互說明可以遵循從大-小的方式。如大的框架的說明，再到細節的說明。

如：卡片整體的結構，包含標題、副標題、評分、評價...信息，哪些是必選，哪些不是必選，基線狀態是怎樣的。說完這些可以繼續拆分描述，標題是一行還是兩行、超出怎么顯示等。

對于界面的說明要完整，即：頁面上有的內容需進行規則描述。規則描述上也盡可能可以遵循一個規則來，如：常規規則、特殊規則、限制說明、文案、操作反饋、手勢、提示、動效等，需要盡可能的覆蓋不同的場景將規則盡可能的描述完整。

如 1：一行文字，最多顯示多少個字符，超出后是...溢出、跑馬燈、折行、字體縮小展示等；

如 2：搜索結果 feed，默認展示幾個結果、沒有結果什么樣式、后續多余的答案是滑動加載還是需要分頁、加載過程成功、失敗樣式、無網絡樣式等

如 3：按鈕切換會有 toast 提示，toast 規則是怎樣？誤操作多長消失、有操作是否會消失、若同時快速點擊其他按鈕 toast 提示是已最后點擊的為準反饋還是按照順序依次反饋...

這些規則會有很多，交互設計師初稿肯定無法能夠做到 100%的覆蓋，但是基礎場景至少需要闡述清晰~

總之，之前前輩說的一句話：凡是界面上有的信息及元素都應該有自己的規則說明，但同樣的不做重復說明，有一次就行。

4. 頁面功能流轉要清楚

有些功能涉及到的頁面流轉很多，這時需要頁面之間進行連線，方便讀者在更加直觀的看到頁面間如何出入，及對應的分支流程。

5. 更新記錄及版本說明

因為交互稿面對多倫的評審肯定會進行多輪的迭代修改，對于每輪具體的修改項都需要完整記錄，這個可以單獨開一個模塊為版本記錄，所有頁面的修改都可以在這里進行記錄。只不過記錄的時候需要分點。

如：

首頁模塊：

1. 修改XXXXXXX,詳見頁面「1.2.2 首頁說明」
2. 修改XXXXXXX，詳見頁面「「1.2.6 滑動說明」 ...

總結

以上初略的可以作為交互稿的基礎，至于說細節板式，字號，顏色這些當然統一更好，但是我想說的是，更重要的是內容，交互設計師需要組織好內容信息及結構，引導讀者根據你所呈現的信息來一點點了解產品的全貌。

歡迎關注作者微信公眾號：「小發的設計筆記」