如何寫產品交互文檔，一份好的交互文檔應該包括哪些方面內容？

01-07

如題，作為交互設計師應該完成的交互設計文檔，它應該包括哪些內容，其中哪些內容是比較重要的，寫交互文檔的流程是怎樣的？

先上幾張14年夏天在Amazon做智能手錶app的交互文檔圖（那時候Apple Watch還只是個謠言，Android Wear是同年夏天我快離職的時候正式發布的...）這個項目在14年11月正式發布的，所以現在可以貼一些當時的設計原稿出來~（現在回過頭看看當時有很多地方做的還是不夠好。。。）

以下總結一下經驗：

我覺得首先應該明確你做交互設計文檔的目的是什麼，是做給誰看的。

通常交互設計文檔的目標受眾是：

大老闆、領導決策層（CEO、產品VP）——絕大多數情況下，他們不太關心交互細節，他們更關心的是這個項目是什麼，有哪些功能，他們通常看一個典型的用戶使用流程也就夠了（人是視覺化的動物，很多老闆更願意用設計師做的交互設計文檔去理解產品方向，這是設計師向上傳達設計理念和你想要推動產品方向的好機會！）
產品經理——你的交互設計文檔通常是產品經理手中的「產品需求文檔」(PRD)的具體化、可視化的表現。你的交互設計文檔反映了你對產品的理解，是一份非常重要的「溝通文檔」。同樣是「篩選列表」一詞，產品經理和你的腦中想像出來的畫面可能就有很大的差別。通過你在交互設計文檔中視覺化的表達，產品需求會變得更加明確和具體。
工程師——對具體實現你的設計的工程師來說，他們最看重的是產品交互邏輯。他們往往希望你的文檔能夠涵蓋到所有特殊狀態（空缺數據點、空白狀態、邊界極限狀態等等、失敗狀態）。在絕大多數情況下，設計師幾乎不可能在一開始就考慮到所有這些狀態，你需要和工程師一起慢慢補齊這份文檔。準確、清晰地標註交互流程和視覺元素會讓工程師愛上你！實際上，工程師很可能是看這份文檔看的時間最久，最仔細、最認真的觀眾了。
你的直屬老闆和設計師同事們——相比於一張張靜止的界面設計，用交互設計文檔也許可以更好地幫助你向你的老闆和同事收集反饋和意見，因為你的老闆和同事可以有一個更全局的視角來看待你的設計細節。

我整理了一下我之前做過的交互設計文檔的結構（加入了幾個我當時並沒有做，但我現在回過頭覺得應該放的東西）：

1. 項目背景——宏觀層面上的介紹為什麼要做這個項目（外鏈到產品經歷的PRD，應該包含有更為具體的市場和競品分析）

2. 平台概覽（Optional）——以下設計是針對哪幾個平台的

3. 設計、技術限制——這點很容易被忽略，但我覺得很重要，能夠幫助Stakeholder理解你在後面的設計中做的一些「看起來奇怪的決定」

4. 用戶研究發現概述——只需要非常概要的描述，可以有外鏈到具體報告

5. 產品使用場景

6. 主交互流程（主要功能）——建議同時使用流程圖和原型設計（prototype）來表達

7. 支線交互流程（次要功能）

8. 特殊狀態（空白狀態、邊界狀態、缺失數據、失敗狀態等）——我感覺這是區分剛剛初級設計師和資深設計師的一個重要一環

9. 設計標註

10. 附錄——這裡我放上了在設計過程中覺得比較有競爭力的Design Alternatives以防老闆們想看一些備案。還放上了一些針對產品未來方向的概念性設計。

回到最開始的目標受眾的討論，大老闆一般只會看這份文檔的1 – 6節（通常大約只佔整個文檔的一半不到），產品經理當然會跟你討論所有章節，而工程師會著重看6 – 9 節，一份文檔可以滿足不同受眾的需求。

@諶斌答案中引用的那篇文章非常有價值。不過，文中提及的一個 PRD 文檔需要包含的內容，更加側重產品需求而不僅僅是「交互設計」。如果題主問的是由交互設計師產出的交互設計文檔，我推薦 @MoonMonster 在另一個問題中做出的回答：

交互設計師的產出物是什麼？是 WORD 文檔描述？是很細緻的各種狀態下的 UE 原型圖？還是其它工具做的東東？

謝邀，

不敢贊同1樓的答案。我看了下內容，裡邊的流程圖不是UDC該做的吧，就是設計流程圖嘛，這是產品經理做需求時候基本的內容吧。

標準軟體工程生命周期中沒有提到用戶交互設計，其中產出為《需求說明書》，《詳細設計說明書》，《使用說明書》。

大學時候學習UDC，單純談交互設計，它的出發點是人體工程學。

用戶的一切感知，都算互動式設計的內容。

1.產品使用流程，用戶交互設計師首先揣摩需求，並模擬使用流程，提出不合理的地方或者違反使用邏輯的地方。更多的時候是針對產品流程設計用戶使用流程。這倆不一樣，比如《爐石傳說》載入遊戲時候很耗費時間，但是用戶且不覺得有等待的焦躁感。原因就是再如遊戲時候的動畫保證了用戶使用的連續性。老闆讓你提升下遊戲的體驗，你能想到這些嗎？

2.產品的整體布局，UDC設計者會列出多個產品布局方案，並對當前產品需要與用戶體驗結合，選擇最適宜的布局方案。

比如：知乎的搜索條做的項提問欄，這就是UDC的鍋。知乎的「提問」按鈕默默隱藏在右上角，這也是UDC的鍋。

3.適應用戶需求，服務型業務對交互體驗要求很高。我們用IOS系統舉例，哪些功能應該被隱藏，那些功能應該暴露出來，以什麼樣的方式暴露給用戶？那些功能必須流暢？

俗話說：有鋼用在刀刃上。對與用戶來說，UDC就是找刀刃的人。

4.引領用戶需求，IOS設計不僅是適應需求找刀刃那麼簡單，人家還製造刀刃。弱者等待時機，強者創造時機，老喬沒有坐著等待觸摸式設備時代的到來，而是掀起並引領了觸摸式設備的興起。這種獨到的眼光簡直就是用戶互動式設計的典範！

隨著穿戴式設備開始興起，必然又有許多交互設計師鋒芒畢露，脫穎而出。

標準交互文檔是什麼我沒能力回答，畢竟不是干這個的。

但就我個人覺得是帶有各種設計細節的說明書，並且附上原因。

很多人在寫交互文檔時，其實糅合了MRD和PRD兩種文檔的內容，導致篇幅較長，一般而言，PRD文檔是寫給UI、研發、測試看的，那些市場分析、數據分析、產品需求、產品背景介紹等等前期準備工作還是通過MRD或者PPT來完成，針對PRD文檔，針對的對象很簡單，就是指導UI設計和開發團隊研發和測試，既然如此，那麼框架很簡單：

1.目錄（這個不用說）

2.修改記錄（為了追蹤整個產品形成的過程）

3.設計風格、要求（主要針對界面設計）

3.功能說明（便於了解產品架構）

4.操作說明（這裡要重點說明，一定要詳細寫明，不同操作狀態下的顯示、提示、轉場是什麼樣的，都要詳細說明，不然留下的後果就是開發人員按照自己的程序語言來表達，導致啼笑皆非的事都有，後面你要優化個沒完沒了，還不如剛開始提交PRD文檔時就面面俱到。

我是嘗盡了這方面的教訓，由於為空、錯誤提示語沒有寫明，結果開發就用自己語言提示給用戶「The xxx is null,錯誤提示還用代碼語言展現給用戶，真是頭大了。把用戶當做機器來對待，你受得了嗎？所以自己能想到的盡量自己詳細寫明，別指望開發人員幫你想得周到。

總之一句話，PRD文檔一定要針對面向的閱讀對象以及產品設計要求來書寫。

這裡的產品交互文檔應該是指給視覺、開發和測試同事看的（如果是給領導層看的，一般都是概要性的PPT彙報，包含用戶調研分析、產品設計方向和產品架構設計等等）。一般來說，這三類合作對象關注的點不太一樣：視覺同事更關注各個界面的功能和元素布局；開發同事更關注整體邏輯架構和各頁面交互流程；測試同事更關注各個狀態下的交互說明，細緻到一句文案。在項目開始之前，確保各方經過交流，目標達成一致；項目進行中時，確保有一個良好及時的溝通環境，保證目標不偏離（最好小組坐在一起）。

翻看了下個人的幾個項目交互文檔，內容可歸納為以下幾塊：

項目背景：人員組成、產品目標描述等
修改記錄：每次的修改點和原因
信息架構：整體架構
核心流程：主要用戶使用流程
交互分支1/2/3…：中高保真原型（功能和元素布局等）、詳盡交互說明（空狀態、錯誤提示、網路相關等等）
場景關聯：應用外部的關聯場景，硬體相關（低電使用、物理鍵操作等等），軟體相關（通知打斷、應用調用等等）
應用一致性梳理：彈框、toast、文案、設置列表、操作手勢等等聚類梳理，主要是自我核查。（如有時間，會協助視覺同事把所有圖標聚類梳理）

當然，文檔撰寫前有很多前期工作，例如用戶研究、需求分析、溝通/評審/修改/確認、可用性測試等等。文檔交付之後，還需要溝通/修改/補充/確認、開發核對、輔助測試等等。

從佔用時間來看，文檔撰寫只是交互設計師工作中的一小環。我們不只是寫文檔的or畫線框圖的。

在敏捷開發的時候，沒有那麼多時間去寫文檔。特別困擾的是邏輯沒有想全，同時給開發設計和測試看的文檔缺少較好的可讀性和完整性，導致評審也不具備足夠的審核力。

私以為能讓大家看的懂的應該有個完整的框架，這個框架用戶xmind就可以很好的表達。然後細節展示基於AXURE即可，Axure中包含功能前置頁面，當前頁面，後續頁面。以及各個頁面的功能跳轉的呈現。最終文檔其實把AXURE導出成word作為留存。

如果非新功能，那麼還需要增加老邏輯內容與現在新功能的對比，有效解決溝通問題

大家都寫的很多了，一句話總結一下，能正確的體現產品的需求，能讓開發直觀的看懂，並且測試能夠準確的驗證。

Marty Cagan 在《啟示錄》中寫道：

產品說明文檔應該滿足以下要求：描述需求，描述用戶體驗，描述軟體的行為，以直觀的方式描述，文檔應該可修改。只有一種形式的產品說明文檔可以滿足以上所有要求，那就是高保真產品原型。為了獲得接近真實的用戶體驗，甚至應該模擬後台處理流程和某些數據。