起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識作為體驗設計師，你真的會寫交互說明文檔嗎？
在設計流程中，設計者需要建立交互說明文檔，通過它清晰地向團隊成員展示場景的梳理和頁面交互行為，進而有效降低溝通成本，推動業務進程。本篇文章里，作者從交互說明文檔觀看者、交互文檔包含內容、優秀的交互文檔是怎樣的三個方面，全面闡述了交互說明文檔，不妨來看一下。
交互說明文檔是體驗設計師連接上游產品經理，對接下游UI（如有區分交互和UI）和開發的重要資料，是對功能需求涉及場景的梳理和頁面交互行為的說明。
一般團隊僅需要靜態交互說明文檔，部分場景下也需要可操作的交互demo。具體需要依據團隊或功能需求進行及靈活處理。
所以，一份足夠完整和詳細的交互說明文檔可以減少溝通成本及信息不對稱。
一、誰需要看交互說明文檔？
1. 產品經理
首先不同公司，不同團隊產品經理與交互設計師或UE設計師之間的配合輸出物是不固定的。
- 有的公司產品經理輸出比較仔細會連帶原型及說明一起出了，找交互開會更多是想要從體驗層發覺存在的可能問題；
- 有的存在各種原因情況下，可能就是一句話給到交互，交互需要從功能規劃、信息架構、原型說明一起搞了。
- 還有比較正常的流程就是產品搞PRD，交互搞交互文檔，彼此之間的邏輯可以互相印證。
2. UI設計師
不同公司團隊，崗位名稱不同或職責不同，需要輸出UI界面稿的可能是UI也可以是視覺設計師。
作為交互設計師的下游，他們有時候也需要較早的介入需求溝通之中，提早避免后期可能存在的問題出現。
3. 前端工程師
前端團隊如果不看交互說明文檔，那一般就需要以PRD文檔為主，這個的話，需要看公司團隊的流程是怎樣的！
一般而言，還是建議前端團隊看交互文檔，畢竟頁面實現和相關規則取值，交互文檔一般都會涉及。
二、交互文檔包括哪幾部分？
1. 修訂記錄
修訂記錄的目的不僅僅是讓我們的交互說明文檔顯得更為專業，更為緊要的是幫助團隊或其他協作人員了解你修改的模塊是什么，避免浪費時間一個個去確認細節的調整點。所以，建議輸出說明文檔的時候，建議保留。
2. 需求說明
需求說明的目的在于解釋當前交互設計的業務背景，闡述交互或體驗設計師需要關注解決的痛點是什么。同時，也可以減少其他協作設計師不必要的溝通，提升協作效率。
3. 業務流程
業務流程涉及當前需求或當前功能模塊的業務操作閉環。分任務分環節的梳理清晰用戶的操作細節。（業務流程圖：用來描述業務流程的，通過一些特定的符號和連線來表示具體某個業務的實際處理步驟和過程，詳細地描述任務的流程走向）
4. 頁面流程
頁面層級之間的信息連接關系。這個部分的信息內容可以在進行交互方案設計過程中，同步進行。
（案例來源網絡，侵刪）
5. 原型設計
1）原型交互展示整體邏輯
2）頁面交互說明方式
依據設備端的不同，交互設計文檔輸出展示也略有差異。一般移動端（手機、手表、AR)交互設計說明偏向左右結構，左圖右文的方式；而WEB端（客戶端、大屏、智能設備等）偏向上下結構，上圖下文。
主要目的都是為了方便上下游協作人員等查看和理解。部分項目，還需要把整個流程融合到頁面流程中，就是方便和其他協作人員之間降低溝通成本。
限于篇幅以及自己當前所處行業問題，其他關于埋點側的東西暫不進行闡述。后續會針對電商領域案例有針對的聊聊自己對于埋點的理解！
三、你認為怎樣的交互文檔是優秀的？
一份比較好且規范的交互說明文檔，不僅可以彰顯自己的專業能力，而且還可以幫助團隊提升工作協作效率。那怎樣的文檔才算是一份比較好的交互說明文檔呢？
這個標準我也不是很清楚，只能依據當前和不同團隊協作過程中取得的效果來說說自己的一點點看法。
認知一致的業務目錄我們在輸出交互說明文檔的過程中，盡量不要去變動產品PRD的說明思路，所涉及的交互功能設計方案也盡量與業務流程保持一致，非必要不變動，變動必提前同步同團隊及協作團隊。這樣可以降低上下游的學習和認知成本，目錄的一致也可以給自己做交互文檔有一個清晰的規劃思路。
描述簡潔明了，言簡意賅我們的交互說明不是越多越好，文字多并不代表一定專業。闡述內容時，首重邏輯梳理，其次再是流程節點，最次才是文字描述。而且在這個過程中，還需要明確一點，如果可以用控件元素進行說明的，就不要再贅述一些文字內容了。
模擬真實環境，數據盡量保持邏輯性關于這一點很多人恐怕都會忽略掉，只是交互稿而已，干嘛搞那么麻煩呢？但是對于數據模擬的真實性或起碼保持數據邏輯的真實性，一方面可以將場景盡量還原更加貼近真實環境，另一方面，也可以方便下游開發更快理解頁面邏輯順序，減少溝通協作成本。
公共組件相關的說明，統一說明展示交互說明文檔中會涉及重復的組件模塊，這個時候，如果我們復制粘貼之后，雖然工作量不大，但是會產生兩個方面的后果：
- 對下游人傳遞的信息就會不明確，兩處的說明到底有無不同？
- 如果要進行修改，所有涉及的部分都需要進行更新，會耗費不必要的時間和精力。
為了降低團隊協作成本，所以，涉及多模塊或多頁面公用相同組件的，最好是在一個地方進行統一說明，涉及相關說明的加一個跳轉鏈接進行展示相關的使用細節。
最后的一個小分享，我們在進行初次交互設計評審或者二次交互設計評審之后，依據公司或團隊協作方式的不同，一定要及時將更新后的設計稿同步到上下游，不僅僅是項目協作涉及的同學，必要時如果是郵件就抄送一份各利益相關人上級一份，如果是OA辦公協作軟件，就最好在項目協同群把他拉進群并@他，確保更新后的信息同步到位。
具體緣由，各位應該都是心知肚明的！
本文由 @賺圖記 原創發布于人人都是產品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
這個圖有點看不清
理解是主要的，關于怎么呈現（可視化），每個人都是有差異的。交互文檔對于撰寫人來說是清晰理解的，但是對于其他人來說可能會有疑惑。如何讓交互文檔通俗易懂也是交互設計師及撰寫人一直在思考的問題。
需求說明和業務流程也是設計出??？我很想知道，產品經理在這種角色關系中，到底在做什么？做規劃？跟進？前者看著像領導，后者看著像打雜的。
之前看過一份交互說明文檔，只能說過分高深，不是我這種凡人能看懂的?？戳俗髡叩奈恼?，明白了，并不是我的問題。
讀者看不明，寫了也是浪費，通俗易懂易通才是真的，而不是“炫技”。
作者把交互說明文檔寫的很棒，內容很干貨，相信對交互體驗設計師應該會有很大的啟發。