如何講解交互設計?在設計流程中，設計者需要建立交互說明文檔，通過它清晰地向團隊成員展示場景的梳理和頁面交互行為，進而有效降低溝通成本，推動業務進程本篇文章裡，作者從交互說明文檔觀看者、交互文檔包含内容、優秀的交互文檔是怎樣的三個方面，全面闡述了交互說明文檔，不妨來看一下，今天小編就來說說關于如何講解交互設計?下面更多詳細答案一起來看看吧!
在設計流程中，設計者需要建立交互說明文檔，通過它清晰地向團隊成員展示場景的梳理和頁面交互行為，進而有效降低溝通成本，推動業務進程。本篇文章裡，作者從交互說明文檔觀看者、交互文檔包含内容、優秀的交互文檔是怎樣的三個方面，全面闡述了交互說明文檔，不妨來看一下。
交互說明文檔是體驗設計師連接上遊産品經理，對接下遊UI（如有區分交互和UI）和開發的重要資料，是對功能需求涉及場景的梳理和頁面交互行為的說明。
一般團隊僅需要靜态交互說明文檔，部分場景下也需要可操作的交互demo。具體需要依據團隊或功能需求進行及靈活處理。
所以，一份足夠完整和詳細的交互說明文檔可以減少溝通成本及信息不對稱。
一、誰需要看交互說明文檔？首先不同公司，不同團隊産品經理與交互設計師或UE設計師之間的配合輸出物是不固定的。
有的公司産品經理輸出比較仔細會連帶原型及說明一起出了，找交互開會更多是想要從體驗層發覺存在的可能問題；
有的存在各種原因情況下，可能就是一句話給到交互，交互需要從功能規劃、信息架構、原型說明一起搞了。
還有比較正常的流程就是産品搞PRD，交互搞交互文檔，彼此之間的邏輯可以互相印證。
不同公司團隊，崗位名稱不同或職責不同，需要輸出UI界面稿的可能是UI也可以是視覺設計師。
作為交互設計師的下遊，他們有時候也需要較早的介入需求溝通之中，提早避免後期可能存在的問題出現。
前端團隊如果不看交互說明文檔，那一般就需要以PRD文檔為主，這個的話，需要看公司團隊的流程是怎樣的！
一般而言，還是建議前端團隊看交互文檔，畢竟頁面實現和相關規則取值，交互文檔一般都會涉及。
二、交互文檔包括哪幾部分？修訂記錄的目的不僅僅是讓我們的交互說明文檔顯得更為專業，更為緊要的是幫助團隊或其他協作人員了解你修改的模塊是什麼，避免浪費時間一個個去确認細節的調整點。所以，建議輸出說明文檔的時候，建議保留。
需求說明的目的在于解釋當前交互設計的業務背景，闡述交互或體驗設計師需要關注解決的痛點是什麼。同時，也可以減少其他協作設計師不必要的溝通，提升協作效率。
業務流程涉及當前需求或當前功能模塊的業務操作閉環。分任務分環節的梳理清晰用戶的操作細節。（業務流程圖：用來描述業務流程的，通過一些特定的符号和連線來表示具體某個業務的實際處理步驟和過程，詳細地描述任務的流程走向）
頁面層級之間的信息連接關系。這個部分的信息内容可以在進行交互方案設計過程中，同步進行。
（案例來源網絡，侵删）
1）原型交互展示整體邏輯
2）頁面交互說明方式
依據設備端的不同，交互設計文檔輸出展示也略有差異。一般移動端（手機、手表、AR)交互設計說明偏向左右結構，左圖右文的方式；而WEB端（客戶端、大屏、智能設備等）偏向上下結構，上圖下文。
主要目的都是為了方便上下遊協作人員等查看和理解。部分項目，還需要把整個流程融合到頁面流程中，就是方便和其他協作人員之間降低溝通成本。
限于篇幅以及自己當前所處行業問題，其他關于埋點側的東西暫不進行闡述。後續會針對電商領域案例有針對的聊聊自己對于埋點的理解！
三、你認為怎樣的交互文檔是優秀的？一份比較好且規範的交互說明文檔，不僅可以彰顯自己的專業能力，而且還可以幫助團隊提升工作協作效率。那怎樣的文檔才算是一份比較好的交互說明文檔呢？
這個标準我也不是很清楚，隻能依據當前和不同團隊協作過程中取得的效果來說說自己的一點點看法。
認知一緻的業務目錄我們在輸出交互說明文檔的過程中，盡量不要去變動産品PRD的說明思路，所涉及的交互功能設計方案也盡量與業務流程保持一緻，非必要不變動，變動必提前同步同團隊及協作團隊。這樣可以降低上下遊的學習和認知成本，目錄的一緻也可以給自己做交互文檔有一個清晰的規劃思路。
描述簡潔明了，言簡意赅我們的交互說明不是越多越好，文字多并不代表一定專業。闡述内容時，首重邏輯梳理，其次再是流程節點，最次才是文字描述。而且在這個過程中，還需要明确一點，如果可以用控件元素進行說明的，就不要再贅述一些文字内容了。
模拟真實環境，數據盡量保持邏輯性關于這一點很多人恐怕都會忽略掉，隻是交互稿而已，幹嘛搞那麼麻煩呢？但是對于數據模拟的真實性或起碼保持數據邏輯的真實性，一方面可以将場景盡量還原更加貼近真實環境，另一方面，也可以方便下遊開發更快理解頁面邏輯順序，減少溝通協作成本。
公共組件相關的說明，統一說明展示交互說明文檔中會涉及重複的組件模塊，這個時候，如果我們複制粘貼之後，雖然工作量不大，但是會産生兩個方面的後果：
對下遊人傳遞的信息就會不明确，兩處的說明到底有無不同？
如果要進行修改，所有涉及的部分都需要進行更新，會耗費不必要的時間和精力。
為了降低團隊協作成本，所以，涉及多模塊或多頁面公用相同組件的，最好是在一個地方進行統一說明，涉及相關說明的加一個跳轉鍊接進行展示相關的使用細節。
最後的一個小分享，我們在進行初次交互設計評審或者二次交互設計評審之後，依據公司或團隊協作方式的不同，一定要及時将更新後的設計稿同步到上下遊，不僅僅是項目協作涉及的同學，必要時如果是郵件就抄送一份各利益相關人上級一份，如果是OA辦公協作軟件，就最好在項目協同群把他拉進群并@他，确保更新後的信息同步到位。
具體緣由，各位應該都是心知肚明的！
本文由 @賺圖記 原創發布于人人都是産品經理，未經許可，禁止轉載
題圖來自 Unsplash，基于 CC0 協議
更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!
zpostcode 
Recruit 
weather 
mreligion 
Yellowpages 
sport 
constellation 
shopping 
name 
game 
directory 
literature 
Word 
tour 
furnish 
Lottery 
tftnews 
lyrics 
News 
digital 
car 
dir 
Edu 
Finance 
