如何寫一份全面易讀的交互說明文檔？

 　　交互說明文檔，是交互設計師 的輸出物中必不可少的一項，它關系著設計方案能否最大程度的被實現。交互新人，大多會煩惱如何寫交互文檔，今天來聊聊這個話題。

　　交互文檔，寫給誰看

　　交互文檔可以看做交互設計師 輸出的”產品”，它面向的”用戶”是下游的同事——視覺設計師、測試工程師、開發工程師。他們會根據文檔中的線框圖、交互細節說明等等，來輸出視覺設計稿、寫測試用例、用代碼實現產品設計方案，並以此為依據完成驗收測試等工作。

　　交互文檔，寫什麼內容

　　最初寫交互文檔時，很多人會有疑惑該寫些什麼內容。我的看法是，開發同事在寫代碼時需要考慮的與界面顯示邏輯、用戶操作相關的內容，幾乎都要在交互文檔中體現，建議越全面越好。

　　如果有遺漏的內容，開發可能會找你討論，也可能懶得費時間溝通直接按照自己的理解去實現。最終，驗收測試的效果不如意，你也不能全賴開發。所以盡量將交互文檔寫的全面些，別消費開發同事對你的信賴值。

　　那麼，到底交互文檔中，需要寫哪些內容呢?

　　1、頁面流程(界面之間)

　　頁面流程圖，可以表達產品的整體結構，幫助同事了解界面之間的關系。在撰寫交互文檔時，也可以以任務、子任務為模塊來詳細介紹界面如何跳轉、何時跳轉。

　　2、內容布局(界面內)

　　正在加載狀態、加載完成有內容的狀態、加載完成無內容的空狀態、失敗狀態(比如網絡異常/權限未開啟)、不同角色的用戶看到的內容是否一樣、不同狀態的文案圖標變化

　　內容的加載方式，何時加載、何時顯示、何時刷新

　　其他 …

　　3、交互操作與反饋(界面內)

　　根據用戶與界面之間發生的交互操作，提供相應的反饋，可能是提示內容，也可能是界面內或界面之間的跳轉。

　　剛入門的交互新人，喜歡把重心放在界面之間的跳轉，而遺漏了界面內的內容布局和交互操作。對此，我的小技巧是，先整體看界面全局，再review界面上的每一個元素，思考各種不同場景下這些元素是否變化、如何變化。

　　以登錄界面為例，看看怎麼寫交互細節說明

　　下圖，是一個簡單的登錄界面，我們試著先整體後部分的方式，看看這個界面的交互說明需要考慮哪些方面。

　　1、登錄界面的跳轉流程

　　什麼情況下，從哪些界面可以進入登錄界面

　　登錄成功後進入哪個界面

　　取消登錄後回到哪裡

　　界面轉場方式，比如從下向上進入界面，從上往下離開界面

　　2、賬號輸入框

　　字段格式要求，字段長度、字段類別(漢子、字母、數字、手機號)

　　是否有默認提示文案，如果上次登錄過是否顯示上次的賬號

　　光標是否置入此輸入框，鍵盤是否顯示，鍵盤用哪種視圖

　　何時檢測用戶填寫的是否正確，填寫正確的提示，填寫錯誤的提示，反饋提示何時顯示、何時消失

　　輸入框中的內容是否支持一鍵清除

　　3、密碼輸入框

　　字段格式要求

　　何時檢測格式是否符合

　　光標置入後顯示鍵盤的哪種視圖

　　輸入框中的內容是否支持一鍵清除

　　是否支持密碼可見、如何切換可見狀態

　　4、登錄按鈕

　　按鈕是否有可用不可用之分，何時可用狀態、何時不可用狀態

　　點擊按鈕之後提示正在登錄的方式

　　登錄成功如何提示、跳轉進入哪個界面

　　有哪幾種登錄失敗的場景(比如賬號未注冊、網絡異常等)，不同失敗的情況下如何提示

　　多次登錄失敗提示方式是否變化

　　5、注冊按鈕

　　點擊進入哪個界面

　　界面的轉場方式是怎樣的

　　6、關閉按鈕

　　點擊進入哪個界面

　　界面的轉場方式是怎樣的

　　以上只是拋磚引玉，給大家打開思路。雖然只是幾個輸入框，但其細節比大多數界面都要復雜。你可以找一款優秀的APP，去研究它如何設計這些細節，是否還有我沒有提到的點，研究透了下次自己設計才能做到更加全面。

　　當然，交互細節說明，只是方案的表述，每一個小點都有好幾種設計方案。如何權衡選擇體驗更優的方案，才最是考驗交互設計 師的能力。你可以對比研究幾款優秀產品，看它們在細節設計有何不同，分析其中的緣由，想想是否有更好的方案，學無止盡。

　　如何提升交互文檔的浏覽體驗

　　交互設計 師的目標是提升產品的體驗，我們輸出的文檔本身也應該有上佳的浏覽體驗。為了達到這個目標，我也在不斷優化文檔的撰寫方式和排版。下面聊聊我嘗試過的幾種方式。

　　方式1：一頁紙表示所有的線框圖，配上箭頭+簡單的文字說明

　　網上流傳著很多這種風格的圖，最初覺得這樣的圖很有范兒，以為這就是他們輸出的全部交互文檔，所以按照這種模式產出。等到自己做的多了會發現這類圖大多只表達了某個界面的正常狀態，並沒有詳細的交互說明來體現界面的內容布局和交互操作反饋。

　　方式2：一頁一個界面，每個界面建一個交互說明文件夾，分功能模塊寫交互說明(Web產品)

　　工具: Axure

　　Web產品的特點是，層級復雜，每個界面比較大而且內容很豐富。通常會組織好頁面層級，再畫每個界面的原型，待幾輪討論過後界面布局和內容基本確定之後，再為每個界面撰寫各自的交互說明。

　　考慮到每個界面中的內容模塊和功能點不少，我沒有在確定好的界面上直接標注交互說明，而是將這個界面劃分為幾個功能模塊，並給每個功能模塊新建一個頁面用來寫交互說明。

　　如下圖，分別是 Axure的文檔目錄(左)、某個功能模塊的交互說明(右)

　　方式3：一頁顯示一個大功能點的所有界面和交互說明(App 產品)

　　工具: Axure

　　App相比Web界面內容簡潔很多，很多人輸出App的交互文檔都是一頁展示很多個界面，上下左右排滿了。設計師大多是大屏電腦，這樣設計起來確實比較連貫流暢。

　　但是開發大多用MacBook，沒有外接的大屏顯示器，一屏看不到幾個界面。雖然我會按照橫向主流程豎向次要或分支流程的規律排列，但是他們對這些規律並不熟悉，左右拖拽上下滾動幾次就容易犯暈，可能一會兒就找不到剛看過的界面了。

　　如下圖，界面右側配上對應的交互說明(通常情況，交互原型應該以黑白灰顏色為主，不過因為我們的APP處於迭代優化的階段，已經確定了視覺風格，而且某些狀態需要用顏色來區分對錯，所以會有一些配色。)

　　期間優化過這種方式，將大功能點拆分，按照以往設計Web 產品的方式來組織。對此開發同事仍然覺得不夠好，所以有了後面ppt/keynote演示文稿的方式。

　　方式4：一頁介紹一個子任務，每頁最多4個界面，輸出PDF格式(App 產品)

　　工具: Axure 畫原型，Keynote 寫交互說明

　　為什麼采用這種方式呢?源於開發同事看到產品老大介紹需求用的幻燈片，覺得一張圖配一個表格的方式很清晰，強烈建議用這種方式來寫交互文檔。

　　我覺得用幻燈片輸出PDF 的方式確實可取，易於浏覽。不過一頁一個圖太零散，界面之間、界面內容的不同狀態關鍵性很強，放在一起介紹更直觀。

　　於是，我想到了以前 yoyo 在騰訊CDC 官方博客上分享的交互文檔撰寫方式：《如何制作實用美觀的設計文檔》 。以前嘗試過用他推薦的indesign寫文檔，但對這個工具不那麼習慣以至於效率並不高，嘗試過寫完一個產品的交互文檔之後就沒再用了。不過 yoyo 推薦的將大故事拆分為一個個小故事來寫交互說明的方法讓我記憶猶新。

　　就這樣，嘗試了這種新的搭配方式，Axure 畫原型，Keynote 寫交互說明。

　　Keynote縮略圖預覽如下圖，為每個功能模塊建立一個任務/子任務的目錄結構，按照劃分的結構依次介紹各個子任務。每個頁面最多介紹四個界面，頁面底部作為固定的區域用來寫交互說明。

　　測試、開發同事反饋這種方式不錯，一方面是因為每頁文檔的結構大小一致，滑動浏覽的體驗也更好;另一方面是因為他們寫代碼也是按照這樣的方式一個小模塊一種場景依次往下走，更容易專注看當前寫的這個模塊的交互說明。

　　雖然有同事的肯定，但這種方式還有優化的空間。因為采用了兩個工具，一個畫原型一個寫文檔，如果Axure原型有改動，需要復制到keynote，兩處都要更新顯然影響效率。所以我還在考慮是否切換到某一個工具搞定這兩件事，比如用sketch 。除此之外，文檔模板也可以改進優化。

　　就像前面說的，交互說明文檔，就像是交互設計師輸出的產品，既要根據場景的變化不斷調整，又要聽取用戶的意見，持續優化提升體驗。

　　歡迎關注妹子的微信公眾號：