在設(shè)計流程中，設(shè)計者需要建立交互說明文檔，通過它清晰地向團隊成員展示場景的梳理和頁面交互行為，進而有效降低溝通成本，推動業(yè)務(wù)進程。本篇文章里，作者從交互說明文檔觀看者、交互文檔包含內(nèi)容、優(yōu)秀的交互文檔是怎樣的三個方面，全面闡述了交互說明文檔，不妨來看一下。

交互說明文檔是體驗設(shè)計師連接上游產(chǎn)品經(jīng)理，對接下游UI（如有區(qū)分交互和UI）和開發(fā)的重要資料，是對功能需求涉及場景的梳理和頁面交互行為的說明。

一般團隊僅需要靜態(tài)交互說明文檔，部分場景下也需要可操作的交互demo。具體需要依據(jù)團隊或功能需求進行及靈活處理。

所以，一份足夠完整和詳細的交互說明文檔可以減少溝通成本及信息不對稱。

一、誰需要看交互說明文檔？

1. 產(chǎn)品經(jīng)理

首先不同公司，不同團隊產(chǎn)品經(jīng)理與交互設(shè)計師或UE設(shè)計師之間的配合輸出物是不固定的。

• 有的公司產(chǎn)品經(jīng)理輸出比較仔細會連帶原型及說明一起出了，找交互開會更多是想要從體驗層發(fā)覺存在的可能問題；
• 有的存在各種原因情況下，可能就是一句話給到交互，交互需要從功能規(guī)劃、信息架構(gòu)、原型說明一起搞了。
• 還有比較正常的流程就是產(chǎn)品搞PRD，交互搞交互文檔，彼此之間的邏輯可以互相印證。

2. UI設(shè)計師

不同公司團隊，崗位名稱不同或職責不同，需要輸出UI界面稿的可能是UI也可以是視覺設(shè)計師。

作為交互設(shè)計師的下游，他們有時候也需要較早的介入需求溝通之中，提早避免后期可能存在的問題出現(xiàn)。

3. 前端工程師

前端團隊如果不看交互說明文檔，那一般就需要以PRD文檔為主，這個的話，需要看公司團隊的流程是怎樣的！

一般而言，還是建議前端團隊看交互文檔，畢竟頁面實現(xiàn)和相關(guān)規(guī)則取值，交互文檔一般都會涉及。

二、交互文檔包括哪幾部分？

1. 修訂記錄

修訂記錄的目的不僅僅是讓我們的交互說明文檔顯得更為專業(yè)，更為緊要的是幫助團隊或其他協(xié)作人員了解你修改的模塊是什么，避免浪費時間一個個去確認細節(jié)的調(diào)整點。所以，建議輸出說明文檔的時候，建議保留。

2. 需求說明

需求說明的目的在于解釋當前交互設(shè)計的業(yè)務(wù)背景，闡述交互或體驗設(shè)計師需要關(guān)注解決的痛點是什么。同時，也可以減少其他協(xié)作設(shè)計師不必要的溝通，提升協(xié)作效率。

3. 業(yè)務(wù)流程

業(yè)務(wù)流程涉及當前需求或當前功能模塊的業(yè)務(wù)操作閉環(huán)。分任務(wù)分環(huán)節(jié)的梳理清晰用戶的操作細節(jié)。（業(yè)務(wù)流程圖：用來描述業(yè)務(wù)流程的，通過一些特定的符號和連線來表示具體某個業(yè)務(wù)的實際處理步驟和過程，詳細地描述任務(wù)的流程走向）

4. 頁面流程

頁面層級之間的信息連接關(guān)系。這個部分的信息內(nèi)容可以在進行交互方案設(shè)計過程中，同步進行。

（案例來源網(wǎng)絡(luò)，侵刪）

5. 原型設(shè)計

1）原型交互展示整體邏輯

2）頁面交互說明方式

依據(jù)設(shè)備端的不同，交互設(shè)計文檔輸出展示也略有差異。一般移動端（手機、手表、AR)交互設(shè)計說明偏向左右結(jié)構(gòu)，左圖右文的方式；而WEB端（客戶端、大屏、智能設(shè)備等）偏向上下結(jié)構(gòu)，上圖下文。

主要目的都是為了方便上下游協(xié)作人員等查看和理解。部分項目，還需要把整個流程融合到頁面流程中，就是方便和其他協(xié)作人員之間降低溝通成本。

限于篇幅以及自己當前所處行業(yè)問題，其他關(guān)于埋點側(cè)的東西暫不進行闡述。后續(xù)會針對電商領(lǐng)域案例有針對的聊聊自己對于埋點的理解！

三、你認為怎樣的交互文檔是優(yōu)秀的？

一份比較好且規(guī)范的交互說明文檔，不僅可以彰顯自己的專業(yè)能力，而且還可以幫助團隊提升工作協(xié)作效率。那怎樣的文檔才算是一份比較好的交互說明文檔呢？

這個標準我也不是很清楚，只能依據(jù)當前和不同團隊協(xié)作過程中取得的效果來說說自己的一點點看法。

認知一致的業(yè)務(wù)目錄我們在輸出交互說明文檔的過程中，盡量不要去變動產(chǎn)品PRD的說明思路，所涉及的交互功能設(shè)計方案也盡量與業(yè)務(wù)流程保持一致，非必要不變動，變動必提前同步同團隊及協(xié)作團隊。這樣可以降低上下游的學習和認知成本，目錄的一致也可以給自己做交互文檔有一個清晰的規(guī)劃思路。

描述簡潔明了，言簡意賅我們的交互說明不是越多越好，文字多并不代表一定專業(yè)。闡述內(nèi)容時，首重邏輯梳理，其次再是流程節(jié)點，最次才是文字描述。而且在這個過程中，還需要明確一點，如果可以用控件元素進行說明的，就不要再贅述一些文字內(nèi)容了。

模擬真實環(huán)境，數(shù)據(jù)盡量保持邏輯性關(guān)于這一點很多人恐怕都會忽略掉，只是交互稿而已，干嘛搞那么麻煩呢？但是對于數(shù)據(jù)模擬的真實性或起碼保持數(shù)據(jù)邏輯的真實性，一方面可以將場景盡量還原更加貼近真實環(huán)境，另一方面，也可以方便下游開發(fā)更快理解頁面邏輯順序，減少溝通協(xié)作成本。

公共組件相關(guān)的說明，統(tǒng)一說明展示交互說明文檔中會涉及重復的組件模塊，這個時候，如果我們復制粘貼之后，雖然工作量不大，但是會產(chǎn)生兩個方面的后果：

• 對下游人傳遞的信息就會不明確，兩處的說明到底有無不同？
• 如果要進行修改，所有涉及的部分都需要進行更新，會耗費不必要的時間和精力。

為了降低團隊協(xié)作成本，所以，涉及多模塊或多頁面公用相同組件的，最好是在一個地方進行統(tǒng)一說明，涉及相關(guān)說明的加一個跳轉(zhuǎn)鏈接進行展示相關(guān)的使用細節(jié)。

最后的一個小分享，我們在進行初次交互設(shè)計評審或者二次交互設(shè)計評審之后，依據(jù)公司或團隊協(xié)作方式的不同，一定要及時將更新后的設(shè)計稿同步到上下游，不僅僅是項目協(xié)作涉及的同學，必要時如果是郵件就抄送一份各利益相關(guān)人上級一份，如果是OA辦公協(xié)作軟件，就最好在項目協(xié)同群把他拉進群并@他，確保更新后的信息同步到位。

具體緣由，各位應(yīng)該都是心知肚明的！

本文由 @賺圖記 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自 Unsplash，基于 CC0 協(xié)議