正式開始閱讀前，我必須要告知讀者朋友們，此文是我工作以來的一些經驗總結和對工具的使用體驗，不代表這就是交互文檔的寫作範式。交互文檔可以根據自己公司和團隊的需求進行歸納，我在這裏僅分享一下我的經驗。

Axure 和藍湖是我平常工作中最常用的兩個軟件，一個是設計生產力工具，一個是在線協同工具，兩者搭配幹活不累。

本文分為兩部分，第一部分是分享我個人在工作中如何用 Axure 製作交互文檔，第二部分是如何用藍湖與產品經理、視覺設計師、客戶，以及運營等其他人協同。本文基於個人有限的工作經驗和知識積累，若有不足之處，敬請指出，互相學習交流。

如何輸出規範的交互文檔

1. 分清產品需求的層級，部分更新和正式產品

在撰寫文檔的時候，你應該知道此次的需求是一個完整的項目，還是對已有項目的完善和優化。如果是一個新的項目，那你需要在文檔中描述產品介紹，並且用簡短的語句描述出產品功能和目標用戶。但是如果是更新和優化，則只需要描述項目名稱和更新的功能概要就好。

2. 交互文檔的要素

文檔說明（版本說明、使用平台）

文檔說明是相當於文檔的封面，文檔說明中應該簡短的介紹該文檔涉及的產品、平台、版本以及參与人員。

更新日誌

更新日誌是文檔中必不可少的部分，更新日誌包含了一個項目從第一個版本開始，到截止開發上線的最後一個版本的概要，方便自己和其他協作人員能快速找到優化的部分，在哪一次的文檔中增加、刪除或者優化的。

我自己製作的更新日誌頁面，包含以下幾個基本要素：

• 時間：時間是指該文檔經過優化以後，上傳至協作平台（比如藍湖）的時間，可以明確文檔變更的具體時間。
• 更新內容：更新內容是指將文檔變更的功能點一一列出，分別用文字作簡單的描述，更新內容是更新日誌中非常重要的一環，如果沒有文字的說明，那麼回溯文檔版本的時候，就沒法進行快速地檢查和瀏覽了，對於後期維護將是一場災難。
• 更新頁面：更新頁面是指將更新的內容分別對應不同的交互頁面，有助於開發或者其他小夥伴快速準確的找到更新內容。開發沒時間一一翻閱大量的文檔，因此版本更新只需要告訴他們哪裡改變了即可。
• 更新類型：更新類型分為三種，新增、刪除、優化。我將每一次的版本更新打上不同的標籤，該標籤可以更加直觀的說明當前版本更新的類型是新增還是優化。

另外可以根據自己的需求增加修改人、版本號等要素，由於在實際項目中，只有我一個人在維護文檔，再加上做 SaaS 版本規劃不是很明確，我的文檔中就不涉及這兩點。

閱前須知

閱前須知是指文檔的使用者在閱讀之前應該要瀏覽的注意事項，否則無法理解文檔中的一些特殊示意。

閱前須知我分為：通用標識說明和通用組件說明。

通用標識說明，是指在整個文檔中廣泛存在的標識元素進行說明，幫助閱讀者快速了解文檔的專用標識和術語。

通用組件說明，是指在開發一個全新的產品時，建立的一套簡化版的設計規範，該設計規範指定了當前文檔中一些組件的樣式、交互以及特殊情況。

結構圖、流程圖、思維導圖

結構圖，一般我在文檔全部更新完畢上傳的時候，會用 Axure 的生成流程圖功能將全部的頁面生成一個樹形的結構圖。點擊結構圖中的模塊可以很方便地跳轉至相應的頁面，這樣開發在查看文檔的時候不用一個個去翻閱文檔，可以直接打開文檔結構頁面，整個文檔的結構一目瞭然，點擊模塊就可以直接跳轉至相應的頁面，方便又快速。

流程圖，是指業務相關的流程圖，將業務邏輯用流程圖進行描述，一般對於複雜業務。流程圖不但有利於自己構建完善的業務流程，同時也有利於開發梳理業務的邏輯。

思維導圖是根據文檔的需要將產品的功能，用思維導圖的形式羅列出來，開發可以窮盡每一個類目下面的子級，從而獲得一個完整的結構。

以上三種都是輔助文檔使用者和撰寫者理解文檔的圖示，因此是非必須的，可以根據業務的需求進行繪製相關的圖示。Axure 本身沒有對流程圖和思維導圖有很好的支持，因此你只需要在第三方軟件做好圖以後，複製到 Axure 界面即可。

交互頁面

交互頁面是整個文檔中最重要的一部分了，也是整個文檔的主體、每個行業每個產品的交互文檔都不一樣，儘管各有不同，但是也能總結一些通用的規範。

文檔結構要清晰合理：交互文檔的層級劃分清晰明確，通過產品的結構進行頁面的劃分，分清頁面的主次。

用詞準確且無歧義：首先，在對文檔進行描述的時候，用詞一定要準確無歧義，如果專業術語解釋不清楚，可在後面舉個例子。文檔的目的是讓閱讀的人能看懂，無論他是開發還是產品，因此用通俗的語言描述你的文檔，適當的時候舉例子進行補充說明。

其次，你的文檔對應的產品目標用戶，是否能理解你的描述也很重要。舉個例子，在後台產品中，使用者並不一定是知識水平非常高的人，如果你用「閾值」等專業術語並不加解釋的話，用戶很難去理解產品的功能。

流程完善且無缺漏：一般來說，交互文檔在交付的時候總會因為各種原因而有所遺漏，要麼是因為不熟悉業務而導致部分功能沒有涉及到，要麼是因為不了解技術而缺失了某些特殊場景。在這個時候，我們需要通過交互走查和評審來發現相關的問題，走查是撰寫者自己對照走查表梳理頁面的缺漏，評審則是通過他人的角度來發現問題，因此一個好的流程是不斷迭代和完善的，你需要做的就是盡可能將交互文檔做得完善且無缺漏。

文檔模擬數據盡量還原真實數據：很多人在設計的時候，都會填充大量的模擬數據用以支撐頁面的內容。sketch 有很多自動填充的插件，比如頭像、圖片、文本、姓名甚至是地址等，這樣的插件方便了我們的工作，但是有些時候文本的填充並不會貼合我們的業務，甚至可能完全無關。但是 Axure 沒有這樣的插件，因此在設計的時候，我們盡量去還原真實的場景，比如商品名稱，就寫真實的商品名稱，地址就寫真實的地址，如果你填充的是毫無邏輯的文本，那麼閱讀者在主觀上很難融入產品的使用場景。

當然，每條數據都用不同的真實文本填充將會耗費我們大量的時間，你也可以採取一些比較討巧的方式，比如，一個列表，第一行用真實文本，其餘的都複製第一行的即可，但是如果涉及到不同的狀態，還是要加以區分並說明。

極限情況和缺省狀態要注意：很多新手可能經常會被開發問：「這個文本框字符最多可以填多少個？」這是由於對極限值沒有在文檔中進行說明而造成的疑問，除了指定「最多」情況，也需要指定「最少」的情況。

那麼問題來了，我們該如何去判斷用戶應該輸入的字符範圍呢？首先，這是由兩個因素決定的。

第一個因素，所輸入的字段，在通用的業務場景下，一般都是多少個字符。比如商品名稱，我們可以去查看下淘寶等平台的商品名稱，再結合我們的業務進行字段的限制。

第二個因素，所輸入的字段，在你的業務場景下，显示在什麼區域，該區域允許显示的字符是多少。如果你的前台列表頁中只給該字段預留了一行，那麼你應該在視覺上判斷下大致需要显示的字符數量，如果只能显示一行，那麼就要設定截斷規則，一般都用「…」代替，在點開詳情頁的時候显示全部的字符。

類似的極限情況太多了，比如斷網情況、流程中斷、數量範圍等，業務、場景不同，極限情況也不同，在這裏就不一一枚舉了。

另一個需要注意的就是缺省狀態，即默認狀態。我們在設計界面的時候，是在設計一個頁面內容滿載的狀態，而非一個產品的初始狀態。如果設計初始狀態，那麼我們的設計稿就一片空白了，因此我們在設計完產品的時候，也需要梳理下頁面的缺省狀態，比如個人中心的訂單沒有訂單的情況，後台商品列表中沒有商品的情況，以及查詢為空的狀態等。

文檔標註需要清晰且明確：在交互文檔中，除了交互頁面的設計，其中最重要的就是標註說明了，很大一部分的操作交互除了直觀的界面展示以外，就是通過標註說明來闡釋的。在我的工作流程中，我將其分為了四個類型：全局說明、帶標記線的說明、局部說明以及交互說明，分別是針對整個頁面的說明、帶有視覺引導的說明、局部功能的提示性說明以及操作說明。可以使開發能夠迅速準確的定位並理解標註內容。

第三視角看文檔：把自己當成該文檔的使用者，把自己當成該產品的用戶，把自己當成該文檔的審核人，通過這個角度，你會明白哪些地方用語不太明確，邏輯有些混亂。在對頁面進行窮盡式梳理的時候，盡量別偷懶，把你能想到的情況都一一說明。

文檔附件

交互文檔存在的意義是將產品需求用可視化的線框圖展示給相關人員，因此需要輔助的文檔來完善整個文檔的功能。這些文檔附件包括且不限於導出字段的表格、上傳的表格、產品需求表，以及用其他軟件製作的輔助文檔等。通常承載於 Excel 表格、Word 文檔、PDF 文檔以及圖片等文件中。由於 Axure 中並沒有可以直接上傳其他文件類型（除了圖片和文字）的功能，因此我們通常用雲端協作軟件來上傳，比如藍湖的資源庫功能。通常，要在文檔中需要的頁面添加相關說明，表示有相關文檔附件的存在。

回收站功能

回收站是指需求變動或者其他原因導致你做的組件和頁面用不上了，需要將其整個優化或者刪掉，但是不排除以後又會改回來，你只需要將你的組件或者頁面放到回收站，標記好相應的名稱（為了方便下次查詢），如以後需要可直接複製到相應的頁面。

交互走查表

建立交互走查表首先需要熟悉產品業務邏輯，走查表是建立在產品功能之上，每個產品的交互走查表都不一樣。其中，平台的差異是比較大的，比如，移動端 app 和 web 平台的差異性導致了其頁面實現的邏輯不一致，因此容易遺漏的點也不一致。web 端是基於瀏覽器的實現邏輯，而 app 則需要根據每個平台的差異（iOS和安卓），建立不同的走查表，但是這隻是針對平台規範的走查，主要的業務邏輯的走查都是相通的。

基礎邏輯走查：

業務邏輯走查：

建立走查表是一個不斷完善迭代的過程，只要不偷懶，一般都會建立一個很好的規避措施。

3. 其他問題

設計組件的整理和製作

在開始一個項目之前，如果是一個全新的項目，那我建議你為這個項目打造一個組件庫，或許這將花費你很多時間，但是在後續設計的時候你將會感受到它的便利性。同時，建立好規範的組件庫以後，你也無需時時去查看尺寸大小等細節規範，只需要將其拖到界面合適的位置，加以改動即可，這樣既保持了整個文檔的統一性，又能提高設計文檔的效率。

另外，如果你的產品有自己的一套設計體系，但是並沒有做成組件，我建議還是做成一套組件引入到自己的 Axure 中，這將在後續的更新和維護上給你帶來巨大的便利。

同時，你也可以使用第三方的設計組件，比如螞蟻金服推出的 Ant Design。

高保真、低保真該選哪個？

有些視覺出身的交互設計師可能糾結於交互文檔是否要做的跟設計稿一樣，增加很多的交互操作和動態效果。關於高保真和低保真該選哪個，唯一的參照依據就是，你的交互文檔使用場景是什麼，目標用戶是誰。

如果你的使用場景是在公司內部開發使用，目標用戶是和你合作的前後端開發人員以及產品、UI，那麼你的文檔是為了提高開發效率而存在的，這時你不需要做成跟視覺稿一樣的，你只需要用黑白灰的線框圖做好產品的原型即可，這樣做的好處有四個：

• 設計效率極高，能快速完成產品原型設計；
• 修改方便，在原型階段，交互稿的改動是非常頻繁的，因此如果你做的跟視覺稿一樣，加了很多交互操作，那改動簡直會要了設計師的命；
• 適合開發拋開細節快速查看，頁面有很多 UI 元素的時候，會影響開發（後端）梳理邏輯，因為這些細節會誤導他，更何況 UI 界面的元素本身是多變且不確定的，開發在開始時只需要梳理業務邏輯即可。至於 UI，那是視覺設計稿和前端的事，在交互階段並不存在這個問題；
• 可以讓 UI 充分發揮自己的設計感，設計出更加出彩的界面。我們作為交互設計師，只需要關注頁面的交互和業務的邏輯，無需關心元素的圓角和陰影的大小。如果你的交互稿做的跟 UI 視覺稿一樣，會在主觀上影響 UI 設計師的判斷，甚至可能會引發同事之間的矛盾。

如果你的使用場景是項目演示，目標用戶是沒有軟件開發相關知識的老闆、甲方（客戶）、測試用戶，你就需要根據你們自己的需求，建立一套可點擊、可跳轉的高保真原型 demo，用以在項目演示的時候給客戶或老闆進行演示操作，給他們一個直觀生動的印象。如果他們擁有絕大部分的決策權，會有很大的幾率通過方案。

因此，關於高保真和低保真的爭論沒有必要，選擇哪一個完全看交互原型的使用場景和目標用戶。就我個人來講，一般工作場景下，我是不建議將交互文檔做成視覺稿的。

Axure+藍湖打造產品開發協同工具

1. Axure上傳至藍湖，建立好文檔

在藍湖建立好相應的項目，拉入相關的參与人，用藍湖軟件將 Axure 文檔直接上傳至藍湖平台，通過其他通訊軟件告知參与各方，文檔已上傳。

2. 將附件文檔上傳至資源庫

若你的交互文檔有附帶的其他類型的文檔，可以上傳至資源庫，並在交互文檔的相關頁面進行說明。

3. 查看歷史版本功能

開發人員在查看的時候可以點擊相關的歷史版本進行對比查看，也可以快速跳轉至文檔改動的頁面。

4. 交互文檔關聯設計稿

如果你的設計稿和交互文檔的頁面用了同一個名稱，藍湖會自動將你的設計稿和交互稿關聯在一起，可以直接從交互稿跳轉至相應的設計稿，這對於前端開發來說，非常方便。但是目前沒有手動關聯的功能，大多數情況下，自動關聯並不是很好用，只能說是一個有甚於無的雞肋功能了，希望後續能手動關聯。

團隊內部人員協同，標記並通知

如果需要特彆強調某個功能，可以直接在原型中添加評論並@參与人員。藍湖的標註功能已經很好用了，但是唯一的缺憾是，如果有改動，我無法在一個軟件中同時完成修改頁面和修改說明的操作，因此如果在 Axure 中修改了頁面，再去修改藍湖中的標註說明，對我來說效率太低了，因此我的標註說明都是做在當前頁面中，既方便導出使用，也方便線上協作。

用鏈接密碼分享文件原型

如果你的項目需要給第三方的人看，但他並不想註冊藍湖的賬號，比如甲方、客戶、參与測試的用戶等，你可以將鏈接和密碼發給相關人員，方便且高效。

總結

此文到這裏就告一段落，當然一份交互文檔不僅僅包含這些內容，根據不同的需求和業務場景，交互文檔的範式也不一而足。因此，總結出適合自己以及適合自己團隊使用的交互文檔是協同的最佳方式。

在我個人看來，交互文檔雖然在規範化上面臨着挑戰，即怎樣才能輸出讓他人易於理解的文檔，但最重要的是，如何在業務需求的基礎上輸出合理的解決方案，達成業務需求和技術實現方面的平衡。

歡迎關注作者的微信公眾號：「星野隨記」

未经-摩登3注册-摩登3测速官网-允许不得转载：摩登3注册-摩登3测速官网 » 無極五平台首頁_如何打造高效協同的交互文檔？來看高手的經驗總結！