正式開始閱讀前，我必須要告知讀者朋友們，此文是我工作以來的一些經(jīng)驗(yàn)總結(jié)和對(duì)工具的使用體驗(yàn)，不代表這就是交互文檔的寫作范式。交互文檔可以根據(jù)自己公司和團(tuán)隊(duì)的需求進(jìn)行歸納，我在這里僅分享一下我的經(jīng)驗(yàn)。

Axure 和藍(lán)湖是我平常工作中最常用的兩個(gè)軟件，一個(gè)是設(shè)計(jì)生產(chǎn)力工具，一個(gè)是在線協(xié)同工具，兩者搭配干活不累。

本文分為兩部分，第一部分是分享我個(gè)人在工作中如何用 Axure 制作交互文檔，第二部分是如何用藍(lán)湖與產(chǎn)品經(jīng)理、視覺設(shè)計(jì)師、客戶，以及運(yùn)營(yíng)等其他人協(xié)同。本文基于個(gè)人有限的工作經(jīng)驗(yàn)和知識(shí)積累，若有不足之處，敬請(qǐng)指出，互相學(xué)習(xí)交流。

如何輸出規(guī)范的交互文檔

1. 分清產(chǎn)品需求的層級(jí)，部分更新和正式產(chǎn)品

在撰寫文檔的時(shí)候，你應(yīng)該知道此次的需求是一個(gè)完整的項(xiàng)目，還是對(duì)已有項(xiàng)目的完善和優(yōu)化。如果是一個(gè)新的項(xiàng)目，那你需要在文檔中描述產(chǎn)品介紹，并且用簡(jiǎn)短的語句描述出產(chǎn)品功能和目標(biāo)用戶。但是如果是更新和優(yōu)化，則只需要描述項(xiàng)目名稱和更新的功能概要就好。

2. 交互文檔的要素

文檔說明（版本說明、使用平臺(tái)）

文檔說明是相當(dāng)于文檔的封面，文檔說明中應(yīng)該簡(jiǎn)短的介紹該文檔涉及的產(chǎn)品、平臺(tái)、版本以及參與人員。

更新日志

更新日志是文檔中必不可少的部分，更新日志包含了一個(gè)項(xiàng)目從第一個(gè)版本開始，到截止開發(fā)上線的最后一個(gè)版本的概要，方便自己和其他協(xié)作人員能快速找到優(yōu)化的部分，在哪一次的文檔中增加、刪除或者優(yōu)化的。

我自己制作的更新日志頁面，包含以下幾個(gè)基本要素：

• 時(shí)間：時(shí)間是指該文檔經(jīng)過優(yōu)化以后，上傳至協(xié)作平臺(tái)（比如藍(lán)湖）的時(shí)間，可以明確文檔變更的具體時(shí)間。
• 更新內(nèi)容：更新內(nèi)容是指將文檔變更的功能點(diǎn)一一列出，分別用文字作簡(jiǎn)單的描述，更新內(nèi)容是更新日志中非常重要的一環(huán)，如果沒有文字的說明，那么回溯文檔版本的時(shí)候，就沒法進(jìn)行快速地檢查和瀏覽了，對(duì)于后期維護(hù)將是一場(chǎng)災(zāi)難。
• 更新頁面：更新頁面是指將更新的內(nèi)容分別對(duì)應(yīng)不同的交互頁面，有助于開發(fā)或者其他小伙伴快速準(zhǔn)確的找到更新內(nèi)容。開發(fā)沒時(shí)間一一翻閱大量的文檔，因此版本更新只需要告訴他們哪里改變了即可。
• 更新類型：更新類型分為三種，新增、刪除、優(yōu)化。我將每一次的版本更新打上不同的標(biāo)簽，該標(biāo)簽可以更加直觀的說明當(dāng)前版本更新的類型是新增還是優(yōu)化。

另外可以根據(jù)自己的需求增加修改人、版本號(hào)等要素，由于在實(shí)際項(xiàng)目中，只有我一個(gè)人在維護(hù)文檔，再加上做 SaaS 版本規(guī)劃不是很明確，我的文檔中就不涉及這兩點(diǎn)。

閱前須知

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

閱前須知我分為：通用標(biāo)識(shí)說明和通用組件說明。

通用標(biāo)識(shí)說明，是指在整個(gè)文檔中廣泛存在的標(biāo)識(shí)元素進(jìn)行說明，幫助閱讀者快速了解文檔的專用標(biāo)識(shí)和術(shù)語。

通用組件說明，是指在開發(fā)一個(gè)全新的產(chǎn)品時(shí)，建立的一套簡(jiǎn)化版的設(shè)計(jì)規(guī)范，該設(shè)計(jì)規(guī)范指定了當(dāng)前文檔中一些組件的樣式、交互以及特殊情況。

結(jié)構(gòu)圖、流程圖、思維導(dǎo)圖

結(jié)構(gòu)圖，一般我在文檔全部更新完畢上傳的時(shí)候，會(huì)用 Axure 的生成流程圖功能將全部的頁面生成一個(gè)樹形的結(jié)構(gòu)圖。點(diǎn)擊結(jié)構(gòu)圖中的模塊可以很方便地跳轉(zhuǎn)至相應(yīng)的頁面，這樣開發(fā)在查看文檔的時(shí)候不用一個(gè)個(gè)去翻閱文檔，可以直接打開文檔結(jié)構(gòu)頁面，整個(gè)文檔的結(jié)構(gòu)一目了然，點(diǎn)擊模塊就可以直接跳轉(zhuǎn)至相應(yīng)的頁面，方便又快速。

流程圖，是指業(yè)務(wù)相關(guān)的流程圖，將業(yè)務(wù)邏輯用流程圖進(jìn)行描述，一般對(duì)于復(fù)雜業(yè)務(wù)。流程圖不但有利于自己構(gòu)建完善的業(yè)務(wù)流程，同時(shí)也有利于開發(fā)梳理業(yè)務(wù)的邏輯。

思維導(dǎo)圖是根據(jù)文檔的需要將產(chǎn)品的功能，用思維導(dǎo)圖的形式羅列出來，開發(fā)可以窮盡每一個(gè)類目下面的子級(jí)，從而獲得一個(gè)完整的結(jié)構(gòu)。

以上三種都是輔助文檔使用者和撰寫者理解文檔的圖示，因此是非必須的，可以根據(jù)業(yè)務(wù)的需求進(jìn)行繪制相關(guān)的圖示。Axure 本身沒有對(duì)流程圖和思維導(dǎo)圖有很好的支持，因此你只需要在第三方軟件做好圖以后，復(fù)制到 Axure 界面即可。

交互頁面

交互頁面是整個(gè)文檔中最重要的一部分了，也是整個(gè)文檔的主體、每個(gè)行業(yè)每個(gè)產(chǎn)品的交互文檔都不一樣，盡管各有不同，但是也能總結(jié)一些通用的規(guī)范。

文檔結(jié)構(gòu)要清晰合理：交互文檔的層級(jí)劃分清晰明確，通過產(chǎn)品的結(jié)構(gòu)進(jìn)行頁面的劃分，分清頁面的主次。

用詞準(zhǔn)確且無歧義：首先，在對(duì)文檔進(jìn)行描述的時(shí)候，用詞一定要準(zhǔn)確無歧義，如果專業(yè)術(shù)語解釋不清楚，可在后面舉個(gè)例子。文檔的目的是讓閱讀的人能看懂，無論他是開發(fā)還是產(chǎn)品，因此用通俗的語言描述你的文檔，適當(dāng)?shù)臅r(shí)候舉例子進(jìn)行補(bǔ)充說明。

其次，你的文檔對(duì)應(yīng)的產(chǎn)品目標(biāo)用戶，是否能理解你的描述也很重要。舉個(gè)例子，在后臺(tái)產(chǎn)品中，使用者并不一定是知識(shí)水平非常高的人，如果你用「閾值」等專業(yè)術(shù)語并不加解釋的話，用戶很難去理解產(chǎn)品的功能。

流程完善且無缺漏：一般來說，交互文檔在交付的時(shí)候總會(huì)因?yàn)楦鞣N原因而有所遺漏，要么是因?yàn)椴皇煜I(yè)務(wù)而導(dǎo)致部分功能沒有涉及到，要么是因?yàn)椴涣私饧夹g(shù)而缺失了某些特殊場(chǎng)景。在這個(gè)時(shí)候，我們需要通過交互走查和評(píng)審來發(fā)現(xiàn)相關(guān)的問題，走查是撰寫者自己對(duì)照走查表梳理頁面的缺漏，評(píng)審則是通過他人的角度來發(fā)現(xiàn)問題，因此一個(gè)好的流程是不斷迭代和完善的，你需要做的就是盡可能將交互文檔做得完善且無缺漏。

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

當(dāng)然，每條數(shù)據(jù)都用不同的真實(shí)文本填充將會(huì)耗費(fèi)我們大量的時(shí)間，你也可以采取一些比較討巧的方式，比如，一個(gè)列表，第一行用真實(shí)文本，其余的都復(fù)制第一行的即可，但是如果涉及到不同的狀態(tài)，還是要加以區(qū)分并說明。

極限情況和缺省狀態(tài)要注意：很多新手可能經(jīng)常會(huì)被開發(fā)問：「這個(gè)文本框字符最多可以填多少個(gè)？」這是由于對(duì)極限值沒有在文檔中進(jìn)行說明而造成的疑問，除了指定「最多」情況，也需要指定「最少」的情況。

那么問題來了，我們?cè)撊绾稳ヅ袛嘤脩魬?yīng)該輸入的字符范圍呢？首先，這是由兩個(gè)因素決定的。

第一個(gè)因素，所輸入的字段，在通用的業(yè)務(wù)場(chǎng)景下，一般都是多少個(gè)字符。比如商品名稱，我們可以去查看下淘寶等平臺(tái)的商品名稱，再結(jié)合我們的業(yè)務(wù)進(jìn)行字段的限制。

第二個(gè)因素，所輸入的字段，在你的業(yè)務(wù)場(chǎng)景下，顯示在什么區(qū)域，該區(qū)域允許顯示的字符是多少。如果你的前臺(tái)列表頁中只給該字段預(yù)留了一行，那么你應(yīng)該在視覺上判斷下大致需要顯示的字符數(shù)量，如果只能顯示一行，那么就要設(shè)定截?cái)嘁?guī)則，一般都用「…」代替，在點(diǎn)開詳情頁的時(shí)候顯示全部的字符。

類似的極限情況太多了，比如斷網(wǎng)情況、流程中斷、數(shù)量范圍等，業(yè)務(wù)、場(chǎng)景不同，極限情況也不同，在這里就不一一枚舉了。

另一個(gè)需要注意的就是缺省狀態(tài)，即默認(rèn)狀態(tài)。我們?cè)谠O(shè)計(jì)界面的時(shí)候，是在設(shè)計(jì)一個(gè)頁面內(nèi)容滿載的狀態(tài)，而非一個(gè)產(chǎn)品的初始狀態(tài)。如果設(shè)計(jì)初始狀態(tài)，那么我們的設(shè)計(jì)稿就一片空白了，因此我們?cè)谠O(shè)計(jì)完產(chǎn)品的時(shí)候，也需要梳理下頁面的缺省狀態(tài)，比如個(gè)人中心的訂單沒有訂單的情況，后臺(tái)商品列表中沒有商品的情況，以及查詢?yōu)榭盏臓顟B(tài)等。

文檔標(biāo)注需要清晰且明確：在交互文檔中，除了交互頁面的設(shè)計(jì)，其中最重要的就是標(biāo)注說明了，很大一部分的操作交互除了直觀的界面展示以外，就是通過標(biāo)注說明來闡釋的。在我的工作流程中，我將其分為了四個(gè)類型：全局說明、帶標(biāo)記線的說明、局部說明以及交互說明，分別是針對(duì)整個(gè)頁面的說明、帶有視覺引導(dǎo)的說明、局部功能的提示性說明以及操作說明?？梢允归_發(fā)能夠迅速準(zhǔn)確的定位并理解標(biāo)注內(nèi)容。

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

文檔附件

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

回收站功能

回收站是指需求變動(dòng)或者其他原因?qū)е履阕龅慕M件和頁面用不上了，需要將其整個(gè)優(yōu)化或者刪掉，但是不排除以后又會(huì)改回來，你只需要將你的組件或者頁面放到回收站，標(biāo)記好相應(yīng)的名稱（為了方便下次查詢），如以后需要可直接復(fù)制到相應(yīng)的頁面。

交互走查表

建立交互走查表首先需要熟悉產(chǎn)品業(yè)務(wù)邏輯，走查表是建立在產(chǎn)品功能之上，每個(gè)產(chǎn)品的交互走查表都不一樣。其中，平臺(tái)的差異是比較大的，比如，移動(dòng)端 app 和 web 平臺(tái)的差異性導(dǎo)致了其頁面實(shí)現(xiàn)的邏輯不一致，因此容易遺漏的點(diǎn)也不一致。web 端是基于瀏覽器的實(shí)現(xiàn)邏輯，而 app 則需要根據(jù)每個(gè)平臺(tái)的差異（iOS和安卓），建立不同的走查表，但是這只是針對(duì)平臺(tái)規(guī)范的走查，主要的業(yè)務(wù)邏輯的走查都是相通的。

基礎(chǔ)邏輯走查：

業(yè)務(wù)邏輯走查：

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

3. 其他問題

設(shè)計(jì)組件的整理和制作

在開始一個(gè)項(xiàng)目之前，如果是一個(gè)全新的項(xiàng)目，那我建議你為這個(gè)項(xiàng)目打造一個(gè)組件庫，或許這將花費(fèi)你很多時(shí)間，但是在后續(xù)設(shè)計(jì)的時(shí)候你將會(huì)感受到它的便利性。同時(shí)，建立好規(guī)范的組件庫以后，你也無需時(shí)時(shí)去查看尺寸大小等細(xì)節(jié)規(guī)范，只需要將其拖到界面合適的位置，加以改動(dòng)即可，這樣既保持了整個(gè)文檔的統(tǒng)一性，又能提高設(shè)計(jì)文檔的效率。

另外，如果你的產(chǎn)品有自己的一套設(shè)計(jì)體系，但是并沒有做成組件，我建議還是做成一套組件引入到自己的 Axure 中，這將在后續(xù)的更新和維護(hù)上給你帶來巨大的便利。

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

高保真、低保真該選哪個(gè)？

有些視覺出身的交互設(shè)計(jì)師可能糾結(jié)于交互文檔是否要做的跟設(shè)計(jì)稿一樣，增加很多的交互操作和動(dòng)態(tài)效果。關(guān)于高保真和低保真該選哪個(gè)，唯一的參照依據(jù)就是，你的交互文檔使用場(chǎng)景是什么，目標(biāo)用戶是誰。

如果你的使用場(chǎng)景是在公司內(nèi)部開發(fā)使用，目標(biāo)用戶是和你合作的前后端開發(fā)人員以及產(chǎn)品、UI，那么你的文檔是為了提高開發(fā)效率而存在的，這時(shí)你不需要做成跟視覺稿一樣的，你只需要用黑白灰的線框圖做好產(chǎn)品的原型即可，這樣做的好處有四個(gè)：

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

如果你的使用場(chǎng)景是項(xiàng)目演示，目標(biāo)用戶是沒有軟件開發(fā)相關(guān)知識(shí)的老板、甲方（客戶）、測(cè)試用戶，你就需要根據(jù)你們自己的需求，建立一套可點(diǎn)擊、可跳轉(zhuǎn)的高保真原型 demo，用以在項(xiàng)目演示的時(shí)候給客戶或老板進(jìn)行演示操作，給他們一個(gè)直觀生動(dòng)的印象。如果他們擁有絕大部分的決策權(quán)，會(huì)有很大的幾率通過方案。

因此，關(guān)于高保真和低保真的爭(zhēng)論沒有必要，選擇哪一個(gè)完全看交互原型的使用場(chǎng)景和目標(biāo)用戶。就我個(gè)人來講，一般工作場(chǎng)景下，我是不建議將交互文檔做成視覺稿的。

Axure+藍(lán)湖打造產(chǎn)品開發(fā)協(xié)同工具

1. Axure上傳至藍(lán)湖，建立好文檔

在藍(lán)湖建立好相應(yīng)的項(xiàng)目，拉入相關(guān)的參與人，用藍(lán)湖軟件將 Axure 文檔直接上傳至藍(lán)湖平臺(tái)，通過其他通訊軟件告知參與各方，文檔已上傳。

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

若你的交互文檔有附帶的其他類型的文檔，可以上傳至資源庫，并在交互文檔的相關(guān)頁面進(jìn)行說明。

3. 查看歷史版本功能

開發(fā)人員在查看的時(shí)候可以點(diǎn)擊相關(guān)的歷史版本進(jìn)行對(duì)比查看，也可以快速跳轉(zhuǎn)至文檔改動(dòng)的頁面。

4. 交互文檔關(guān)聯(lián)設(shè)計(jì)稿

如果你的設(shè)計(jì)稿和交互文檔的頁面用了同一個(gè)名稱，藍(lán)湖會(huì)自動(dòng)將你的設(shè)計(jì)稿和交互稿關(guān)聯(lián)在一起，可以直接從交互稿跳轉(zhuǎn)至相應(yīng)的設(shè)計(jì)稿，這對(duì)于前端開發(fā)來說，非常方便。但是目前沒有手動(dòng)關(guān)聯(lián)的功能，大多數(shù)情況下，自動(dòng)關(guān)聯(lián)并不是很好用，只能說是一個(gè)有甚于無的雞肋功能了，希望后續(xù)能手動(dòng)關(guān)聯(lián)。

團(tuán)隊(duì)內(nèi)部人員協(xié)同，標(biāo)記并通知

如果需要特別強(qiáng)調(diào)某個(gè)功能，可以直接在原型中添加評(píng)論并@參與人員。藍(lán)湖的標(biāo)注功能已經(jīng)很好用了，但是唯一的缺憾是，如果有改動(dòng)，我無法在一個(gè)軟件中同時(shí)完成修改頁面和修改說明的操作，因此如果在 Axure 中修改了頁面，再去修改藍(lán)湖中的標(biāo)注說明，對(duì)我來說效率太低了，因此我的標(biāo)注說明都是做在當(dāng)前頁面中，既方便導(dǎo)出使用，也方便線上協(xié)作。

用鏈接密碼分享文件原型

如果你的項(xiàng)目需要給第三方的人看，但他并不想注冊(cè)藍(lán)湖的賬號(hào)，比如甲方、客戶、參與測(cè)試的用戶等，你可以將鏈接和密碼發(fā)給相關(guān)人員，方便且高效。

總結(jié)

此文到這里就告一段落，當(dāng)然一份交互文檔不僅僅包含這些內(nèi)容，根據(jù)不同的需求和業(yè)務(wù)場(chǎng)景，交互文檔的范式也不一而足。因此，總結(jié)出適合自己以及適合自己團(tuán)隊(duì)使用的交互文檔是協(xié)同的最佳方式。

在我個(gè)人看來，交互文檔雖然在規(guī)范化上面臨著挑戰(zhàn)，即怎樣才能輸出讓他人易于理解的文檔，但最重要的是，如何在業(yè)務(wù)需求的基礎(chǔ)上輸出合理的解決方案，達(dá)成業(yè)務(wù)需求和技術(shù)實(shí)現(xiàn)方面的平衡。

歡迎關(guān)注作者的微信公眾號(hào)：「星野隨記」