如何寫一份易懂的交互文檔？

12-27

各位大大我是一個初入行的交互設計師，不知道怎麼編寫一份交互文檔，我所傳遞的交互圖是下圖圖一工程師反饋說有些不明確、看不懂然後我去翻閱資料感覺自己傳遞的像PD傳遞的粗略線框圖，交互說明較少，我看到好多人用下圖圖二的方式傳遞交互文檔，但是我想問這種交互圖是否可以很好的表現流程？起始與結果是不是不夠明確？我現在很矛盾不知道用那種形式，各位一份簡單的，易懂的交互文檔是什麼樣子的，可否給我一份參看287646797@qq.com 附圖，請各位為我解答，謝謝。

交互文檔本身也是一個交互設計，交互的對象就是文檔和對接的開發工程師、設計師。理想的交互文檔用一份應當是不夠的，而原型我個人認為只適合展示，是不能用來充當交互文檔交付給工程師的。

題主圖一的內容肯定是不充分的，如果我是工程師，我先來隨便問幾個問題：

1.請問最上面的界面是打開 App 後的第一個界面嗎？前一個頁面是什麼，如何引導過來？

2.請問電話號碼輸入錯誤如何反饋？電話號碼和本機號碼是否需要驗證？驗證碼輸入錯誤如何反饋？重發成功如何反饋？

3.過渡的轉菊花是模態還是單純的矩形窗口？停留的時間是多少？網路不通暢失敗了如何反饋？

4.幾個頁面之間返回跳轉如何操作？返回後重新進入信息是否保存？頭像上傳入口？剪切圖片規則？

相關的問題可以有很多，我相信題主也只是截個圖表個意，更多細緻的信息還有額外的表達。但是要記住，交互是一個很複雜的工作，如果你表述的內容不充分，導致的結果可能是開發同學靠自覺完成或者他不知道怎麼做還要繼續來和你溝通。如果是前者，開發同學的自覺靠譜固然是好，那至少產品是可用的，但是文檔是不完備的；如果是後者，大量的溝通時間就等著被浪費掉了。

第二張圖的交互方式我經常看到，我猜測除了這張圖以外，還會有很多的頁面跳轉規則在裡面，因為交互不可能只單純說明一個頁面的內容而不管其他頁面之間的邏輯關係。不同的公司、不同的團隊做法肯定是不同的，不同的同事也有不同的習慣，具體問題需要具體適應，我來從交互文檔的形式上介紹一下我個人做產品設計、交互設計的幾個要點，具體產品設計的內容就不展開了。

當然，個人意見僅供參考，不適用與具體團隊也是很正常的。

第一，採用平鋪展示結構。

平鋪展示的結構比可交互原型要實用。可交互原型更適合用於展示，比如你如果給工程師看這樣一個文件：

其附近的頁面是什麼，工程師要猜，哪些地方點擊出現什麼內容完全是意外，而且一個頁面里的動態效果、極限操作、反饋通知都很難用一個交互原型說明清楚。當然你可以用 QC 或者 Form 做一個超高保真的頁面，那我只能說真的成本太高了。

才用平鋪的展示結構會清晰很多，比如下圖這樣：

工程師通過拖動、縮放可以比較清洗地看到整體的頁面結構和邏輯，做交互文檔追求逼格是不行的，還是要實用主義，合作過的幾個工程師都比較青睞平鋪的展示方式，而這樣也給其他內容的填充留下了空間。

第二，配合引導線和備註文檔。

引導線的作用是表述頁面之間的關係，哪個按鈕通往哪個頁面、如何返回、哪些頁面構成循環，都需要通過引導線來說明。值得注意的是，引導線過多過密的話看起來是很蛋疼的，所以這也是第三點的原因，具體再說。備註文檔是很重要的，配合文字信息才可能把你要表達的信息都傳遞出去，交互的細節、反饋傳遞的方式，都可以在主界面邊上放置幾個狀態界面，再配合備註說明清楚，具體可以是這樣：

第三，一個具體的功能模塊放到一個單獨的文件里。

具體功能模塊分放到單獨文件的好處有三個。首先，工程師工作或你交接內容的時候重點可以更突出，指示信息或者界面更加容易，關注某一個當前工作的中心即可；其次，防止引導線和備註文檔過於密集，一張超大的圖從頭拖到尾都要拖半天，要找一個具體的頁面更是超級困難，而且版面受限的話很多細節中的細節就很難突出了；再次，防止 PS 或者 Sketch 這種軟體工程太大的時候經常性崩潰，別笑，這是真的經驗之談。

第四，工具推薦。

（Sketch || PhotoShop）（Quartz Composer || Form）是一個很好的選擇，我個人是使用 Sketch 和 Form 這個搭配的。在使用插件的條件下，Sketch 可以自動進行標註、切圖，還可以生成帶文檔版面的畫板，如果有誰開發一個引導線插件那就完美了。Form 目前免費，iOS 設備模擬優秀，前景看好，可以看我的這個答案：交互原型設計工具 Form 的體驗如何？ - 知乎用戶的回答

第五，酌情使用原型說明細節問題。

特別細節的問題是需要使用高保真原型來表述的。之前做產品的時候有一個下拉通知欄，大概是這樣的：

這個藍色條狀通知欄以什麼形式從什麼位置如何落下，通過文字很難表達，這就可以單獨針對這個頁面的這個效果做一個高保真原型，開發一看就明白了。

不要奢望用原型工具把整個產品全部做出來，這是不可能的，一般不會有人這麼乾的。記住只模擬需要的具體的頁面，效果好，成本低。

最後，溝通、反饋和迭代。

文檔的一大作用是用於溝通、反饋和迭代。也許你們口頭把某些問題談妥了，但是下個月來了個新的開發怎麼辦？他看你的文檔發現某個問題沒有說明或者還是按照有問題的方式去表述，這就不好了。所以記得所有細節都要體現在文檔中，即便是一個小的改動也不要漏了，因為說不定改天你也不在了，這產品還得繼續做不是。

有了用戶反饋就需要對產品進行迭代，把某次迭代的版本、時間、責任人、內容都寫清楚，方便落實責任，也方便以後追溯。

回答比較晚了，依然希望對題主和其他朋友有所幫助，個人才疏學淺，有不妥之處也歡迎指出，一起討論。

先針對題主貼出的交互文檔給一些建議：

這個交互文檔最大的問題是：只是一個「理想化」的「故事板」，沒有對交互具體流程做出到位的拆解。工程師看到，必然會迷茫，或者只能天馬行空按照自己的想法來實現。

1. 首先界面本身的問題：導航關係不明確，缺少必要的導航和標題。不僅工程師不知道界面之間的關係，恐怕用戶看到這個頁面也要困惑。

2. 交互邏輯缺失：點擊註冊之後，信息一定能成功提交么？如果有信息缺失，或者格式不符合要求，怎麼處理？密碼不一致怎麼辦？如果這個手機號已經被註冊了怎麼處理？出錯信息是實時反饋，還是點擊「註冊」按鈕後反饋？如何顯示？驗證碼超時之後會怎樣？這些全沒有體現出來。

3. 交互細節缺失：用戶的真實使用場景中，會有「彈出鍵盤（數字鍵盤還是字母鍵盤？）」、「切換到下一個輸入框」、「收起鍵盤」、「查收簡訊驗證碼」等很多操作流程，這些在交互稿里都沒有體現。

4. 文檔組織欠缺考慮：a. 流程圖缺乏良好組織。舉例來說，三個箭頭分別是：向右、向下、向左。從邏輯上實際都是向前推進的。如果一個流程從左邊開始，右邊結束，那麼這三個界面的關係應該是從左向右依次排列，才更符合邏輯。b. 不同頁面，以及相同頁面的不同狀態，應該標註下頁面標題，方便引用以及討論。總的來說，設計師需要從文檔讀者的角度去組織文檔，這也是設計考驗的一部分呢。

一個完備的交互文檔，應該是流程和細節說明結合的，題主給出的下圖，可以結合邏輯清晰的流程圖，就能避免你擔心的不能很好「表現流程」的問題。對於移動端產品，詳細說明和流程圖可以很方便的放在一張大畫布里。如果是桌面端產品，有時候我會先提供一個概覽性質的邏輯流程圖，上面標註頁面編號，然後再在單頁里給出每個頁面的詳細說明。

附一個我做過的移動端登錄註冊交互文檔（小圖）示意：

這裡我也是偷懶了。因為合作的工程師很熟悉，自身水平也很高，所以我只是把關鍵步驟畫清楚，也節省了很多溝通說明的時間。

工欲善其事，必先利其器。想要省時省力地產出高品質交互文檔，需要根據你使用的設計工具，收集一些常用的線框圖組件。

（先去吃個飯，回來補充一些可能對題主有幫助的資料……）

就醬。題主加油。

交互設計師的輸出物中，交互說明文檔是必不可少的一項，它關係著設計方案能否最大程度的被實現。交互新人，大多會煩惱如何寫交互文檔，所以我來聊聊如何寫一份全面、易讀的交互說明文檔。

交互文檔，寫給誰看

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

交互文檔，寫什麼內容

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

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

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

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 。除此之外，文檔模板也可以改進優化。

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

========================2016/1/14更新===========================
百度大UE推出的課程講的比我好，而且更細緻，推薦觀看【系列】交互設計入門
========================原答案=================================
互聯網從業者都知道做出來的產品要滿足用戶在情境下的需求，不知道交互設計師是否意識到——交互設計說明也是你的一個產品，這個產品的用戶是研發工程師和UI設計師。在寫交互設計說明的時候，不妨思考一下你的用戶是在什麼樣的情境下看到這份說明？他們又對這份說明有著什麼樣的需求？

個人工作總結了一些寫交互設計說明的要點，歡迎拍磚、交流和點贊O(∩_∩)O~~

要點一：交互設計說明不能代替口頭溝通
大多數互聯網產品都遵循小步迭代、快速驗證以便超越競品、搶佔市場先機，如果寫個交互說明要花五六個小時，無疑非常影響產品開發效率，因此建議中小企業的交互設計師畫好線框圖；寫明複雜的邏輯要點即可，其他均可和研發工程師口頭溝通，提高效率。完整詳細的交互說明可以在開發後再補上。

要點二：簡潔的介紹背景信息
所謂背景信息即需求發起人是誰？設計目標是什麼？設計思路要點等信息。有經驗的研發工程師和UI設計師可以根據設計目標和設計思路等信息動態調整一些程序架構或者界面細節，以便達到更好的效果。而且團隊成員知識背景和看問題的角度不一樣，能根據設計目標幫助你找到一些設計盲區，以此改進出更棒的設計方案。

要點三：使用橫排A4大小的頁面撰寫交互設計說明
首先非常不建議把所有界面、流程都畫在一個大圖裡。像下圖這樣，

看上去逼格很高，但研發工程師和UI設計師得不停的放大縮小拖動著看，非常不方便，而且圖片里的文字也不能複製，研發工程師還得去手動再輸入一遍文案，浪費了時間。工作中發現，研發工程師比較喜歡看PDF文檔或者網頁，因此大小與文檔和網頁相當比較好。為什麼用橫排A4而不是常見的直排A4呢，因為交互設計說明裡圖示多於文字，直排A4比較適合文字多的文檔，橫著只能放一兩張圖，不方便畫界面流程。這裡可能有人擔心規定了頁面大小，畫圖大小會不會有限制，這點完全不用擔心，在Axure的列印預覽導出PDF可以選擇「鋪滿整頁」，無論之前畫的界面有多大，都會自動縮放塞到橫排A4內。

要點四：基於用戶使用流程將內容分頁
每頁說明寫出一個場景或流程，或者一個複雜的交互邏輯說明。建議從用戶使用產品最開始的地方開始寫（就像是在講故事，講一個用戶使用產品過程的故事），這點我是參考了華為設計總監 @尤文文的方案（傳送門：如何製作實用美觀的設計文檔），這麼寫好處有二：1.配合背景信息從頭到尾看完可以順暢的了解整個設計方案和設計思路。2.配合橫排A4無論是在台式機、筆記本、iPad、PPT、列印都可以獲得非常好的展示效果。

要點五：提供修改記錄和帶鏈接的目錄
項目越大提供修改記錄和帶鏈接的目錄就越重要，方便大家了解更新記錄和負責開發不同模塊的工程師也方便的在文檔間跳轉。

基於如上要點，我將題主的交互設計說明改進如下
（ps：題主這個設計本身有些邏輯和細節問題，這裡假設題主的設計都沒問題）
PDF文檔和Axure源文件下載地址：知乎答題練習_免費高速下載

對於新手而言切記：不要馬上畫頁面原型！！！
首先得有完整的業務流程圖，你從哪裡開始，到哪裡結束，中間遇到什麼，每一步之後的可能情況都列出來，每一步之後其實有很多分支，而不是一路到底的，對於一個頁面，要分析所有的出口和入口；
有完成的流程以後才是頁面的的說明，當前頁面的元素點擊以後的反饋效果要說明清楚，是進入下個頁面還是輸入還是什麼的，輸入是什麼限制，傳圖片是什麼限制等……
還有就是一些特殊情況的說明，比如伺服器問題，斷網問題，限制規則問題等……
不過如果團隊合作時間很長了，大家都很熟悉，只要給出一個清晰的主幹邏輯就可以了，其他的東西技術有問題會和你溝通的~面對面更清楚些~

好的交互稿並沒有什麼規則，達到兩個目的就OK了：
1、能包含所有場景的流程和說明，盡量不遺漏，特別是一些異常情況的場景；但是交互設計師並不是測試和開發，有些異常就算再認真、仔細也發現不了，所以只能盡最大努力思考全面；
2、能讓視覺和開發看的懂，這個需要團隊之間不斷的磨合；寫的太多，文檔複雜的就提高了，不易閱讀；寫的太少，容易漏掉場景；所以，哪些地方就算不寫開發也知道，哪些地方必須每次強調，這些都是需要不斷磨合的，沒有統一的規範。

最後強調下，文檔不是目的，只是交流的手段，達到效果即可。

為什麼要用寫的？直接用axure穿起來不就得了？

再好的交互文檔也不能缺少溝通。

同為初級交互，給點兒小小的建議供參考
首先，要明確交互的概念，交互C端更偏重於用戶體驗，B端更偏重於功能，而對於樓主的圖1的註冊頁面來說。
目前很多BAT企業的UED團隊已經給出很多案例表明，「重複密碼」是沒有意義的,而在驗證碼輸入框的按鈕，應該是獲取驗證碼/重新獲取，樓主的30s很難讓人理解，可以用其他方式表示；同時對齊方式建議修正
而如果僅僅只支持手機號碼，那麼在帳號區域可以加一個「+86」簡單提示，當然這些都只是UI上，或者說頁面視覺上，那麼在流程上需要有

手機號碼位數不足時，是否直接提示？還是點註冊後提示？
手機號碼已經被註冊時如何提示？是提示已註冊就Over了，還是告知用戶可以找回密碼？或者聯繫客服進行處理？
手機號碼輸入錯誤時，如何處理？同時如何提示，流程是如何的？（如果可以，最好自動讀取本機號碼）
驗證碼獲取不到時，如何操作？讓用戶放棄註冊？簡訊網關和手機簡訊的黑名單是你無法去改變和掌控的
驗證碼失效時間是多少？簡訊里是否提示？提示的文字該如何描述？失效後你的註冊頁面會如何提示？是點擊註冊提示還是輸入驗證碼時提示？
註冊成功後進入填寫資料頁面，那麼年齡的區域是文本框還是直接選擇？用戶名更換成昵稱是不是更容易讓用戶理解？

站在一個初級交互的角度上，僅此建議，供參考。而對於樓主說的如何進行交互說明，我現在一直是用的交互文檔去描述的，而給UI的交付文檔則是頁面統計

1.相信我，有樹狀的結構的交互文檔才可能成為閱讀體驗良好的文檔；
2.另外我建議盡量不要輸出一個十幾個頁面的大圖，雖然那很美，準備作品集時會很有自信，但是在實際工作中對 PM，RD，QA 同學是一種摧殘，尤其在需求的不確定性是一種常態時，也會摧殘自己；
3.如果沒有 wiki 或者其他文檔管理工具，axure是當前最好的交互文檔輸出工具，但是很致命的問題是丑，丑，丑！
4.不是方案中的所有東西都需要輸出，口頭溝通也是一種有效的方案輸出方式，只是那個度得把握好；

另外，把交互文檔當做一個產品去設計，很多東西就很清晰了。回想一下交互文檔的用戶，客戶（比如領導），場景，路徑，信息流，情感感受等

試試這個: Fluid UI - fast and friendly mobile prototyping.

根據你們的合作模式而定。如何足夠小組話，開發就在你旁邊，那麼用1就夠了。如果開發屬於公共資源，要和其他組搶資源，那麼可以考慮2，盡量寫清楚，因為這種情況下，你和開發溝通有限，他們也不只干你的活，不清楚的可能都懶得問。

不管怎麼樣，開發之前先溝通，開發中不斷檢查，這樣才能確保質量。

Ps:記得我剛入職的時候，經常把交互的demo做好，然後給大家試用。

首先，針對題主的交互設計圖說一說，題主只是把註冊場景中最簡單的一個小流程表現了出來。但未涉及到的點還有很多：

是否有錯誤提示？
沒有收到驗證碼用戶該怎樣進行操作？
在哪輸入手機號？
密碼輸入的規則與限制是什麼？
具體的loading效果應該是怎樣的？
錯別字「收入」；

交互設計不僅僅是把一個流程告訴研發，並且需要把正確的流程所需要滿足的各種條件以及各種條件未被滿足時的流程整理出來，這樣研發在做的時候是按圖索驥而不是自由發揮。

其次，回歸問題說到怎樣寫一份易懂的文檔，每個團隊有不同的習慣，我個人的建議是關鍵路徑以流程圖的形式表現出來，每一個流程涵蓋哪些頁面標註清楚，再按流程劃分去單獨描述頁面。重點就在頁面中的每一個元素：

怎樣進來怎樣離開？
每一個按鈕怎樣懸停，會有怎樣跳轉？
每一個label的文字是否是經過斟酌？
滿足的條件和不滿足的條件
輸入框的聚焦和離焦
......

這些「點」在剛開始的時候是很容易遺忘的，但是隨著經驗的不斷增加，相信作為一名合格的交互設計師是能夠儘可能的考慮全面。

最後說一句，遇到遺漏也不必過於完美主義而產生自責啊愧疚啊（我原來就是！），補好細節做好迭代的記錄，及時和團隊進行溝通和交流也是很棒的。

不是做UI的但是經常和UI的人合作，我的建議是：

首先，題主的交互文檔中有錯別字，請立即改過來。

其次，動作承接不鮮明，步驟請加上步驟序號，比如1、2、3，便於開發考慮驗證邏輯等。並且把每個UI界面上用戶的交互行為列出來。

最後，建議在動作按鍵處附加上動作圖，比如在註冊按鍵出畫出一個手指表明動作。

其實最重要的是，題主你做的是交互，不是單純的UI設計，每個原型圖起碼要附上交互的行為，才能讓開發理解你的設計的意圖。

1、頁面流程（界面之間）

2、內容布局（界面內）

正在載入狀態、載入完成有內容的狀態、載入完成無內容的空狀態、失敗狀態（比如網路異常/許可權未開啟）、不同角色的用戶看到的內容是否一樣、不同狀態的文案圖標變化
內容的載入方式，何時載入、何時顯示、何時刷新
其他 …

3、交互操作與反饋（界面內）

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

我覺得這位同學的問題不在「如何寫」，而在「寫什麼」。「如何寫」其實就是文檔形式，你所舉例的那兩幅圖，都是可以的，但缺信息。

關於「寫什麼」，我在一篇文章里有仔細分析，可以戳【交互基本功】如何避免漏掉交互細節。

另附一張《設計之下》里的劇照供參考：

加油！

個人覺得重要的不是界面地圖，重要的是交互行為的標註，附上一張圖，我們準備把文檔升級到這樣：

另外這個是我們現在做的：

多寫規則和場景描述，只有圖的話講著講著就忘記了。

交互設計剛入門，最近同樣糾結這個問題，有些感悟可以一起分享一下。
1，第一是溝通，視覺前端開發同樣是你的用戶，他們不一定會明白這個產品的邏輯是什麼樣的，所以他們更需要一份清晰明了的交互說明，在完成第一份交互稿的時候不斷地與他們溝通，發現不足及時更正完善；
2，第二是要有自己的交互說明文檔規範，第一眼他們能識別這是你的交互文檔，然後就能瞬間明白怎麼去看你的交互說明文檔；如何整理自己的規範，先是自己做去思考去總結，然後是請教部門裡的前輩他們是怎麼做的（網上也能找到優秀的規範），而自己要在每一個項目中不斷去總結整理，慢慢就有自己的交互規範了；
3，做設計不能急，認真做好每一個細節，自己想明白了，寫好一份交互文檔就是水到渠成的事了，要不然做的東西不僅讓別人看不懂，同時也是在折磨自己（正處於這種狀態中%&>_&<%）

我也經常畫你說的圖2的那種，原因是圖1的形式沒那麼直觀，因為在同一界面下會有不同的交互，重複性會很高，都列一遍再單獨指出，會顯得有些冗餘反而干擾視線，也不容易讓看的人找出兩者的區別。但是ps:我是PM。