編輯導(dǎo)語：在設(shè)計流程中，交互設(shè)計師需要建立交互設(shè)計文檔（DRD），以清晰地向團(tuán)隊成員展示頁面設(shè)計細(xì)節(jié)與交互設(shè)計輸出，進(jìn)而有效降低溝通成本，推動業(yè)務(wù)進(jìn)程。本篇文章里，作者總結(jié)了交互文檔的常見誤區(qū)與關(guān)鍵要素，一起來看一下。

交互設(shè)計文檔也稱DRD（Design Requirement Document），是交互設(shè)計師把抽象的產(chǎn)品需求轉(zhuǎn)化為具象的線框圖呈現(xiàn)的過程。是交互設(shè)計日常工作輸出的最終產(chǎn)物，用來告訴別人「頁面設(shè)計細(xì)節(jié)」的一個說明文檔。

一般會是交互設(shè)計或UX（體驗設(shè)計師）寫交互文檔，也可能會是產(chǎn)品經(jīng)理寫交互文檔，不同類型或體量的產(chǎn)品團(tuán)隊寫文檔的角色可能會不一樣。

很多在工作了一兩年的同學(xué)依舊會被吐槽交互文檔不規(guī)范、出圖慢，我將從以下幾個方面全面講解，助你高效輸出規(guī)范的交互文檔。

一、交互文檔常見誤區(qū)

1. 所有內(nèi)容平鋪在一個頁面上

剛開始工作的時候，你可能會遇到做一個功能眾多的小應(yīng)用，當(dāng)你想再添加一些特色功能之前，會發(fā)現(xiàn)已經(jīng)被你弄得滿屏幕都是按鈕和信息了。

2. 控件不規(guī)范、不統(tǒng)一

頁面上的某些元素可以幫助你確定正在瀏覽的頁面，其他元素應(yīng)該盡可能清晰一致。

最常見的例子是：“接受”和“取消”按鈕，是放在左邊還是右邊。

按經(jīng)驗來說，當(dāng)你在流程中前進(jìn)時，繼續(xù)的那個按鈕應(yīng)該是綠色的，放在右邊，并且按鈕上有一個文本，解釋它的功能，比如：“同意”，“繼續(xù)”或“購買”。

3. 遺漏頁面或狀態(tài)

很多同學(xué)只輸出正向流程，或者只提供較少的異常情況。這在后續(xù)的工作推進(jìn)過程中會增加很多溝通成本，比如斷網(wǎng)、弱網(wǎng)、服務(wù)異常、加載中……

4. 可讀性差

交互文檔不僅僅是給自己看的，它作為需求轉(zhuǎn)化為具象的線框圖，通常會有開發(fā)、測試、UI、產(chǎn)品、周邊相關(guān)同事甚至領(lǐng)導(dǎo)來閱讀，設(shè)計表述是否完整和清晰顯得至關(guān)重要。

另外頁面對齊、字體大小的把握也是很容易忽視的細(xì)節(jié)問題。

5. 缺少全局說明

交互文檔還有可能交接給其他設(shè)計師來繼續(xù)迭代，但很多同學(xué)根本沒有整理全局設(shè)計規(guī)范和規(guī)則，這會導(dǎo)致下一個接手的同事直接“另起爐灶”，讓整個文檔越來越不統(tǒng)一，開發(fā)成本也會更高。

二、交互文檔7要素

首先應(yīng)該明確交互文檔的意義：

• 個人而言，它可以幫助你理清思路，并記錄下來，便于項目總結(jié)沉淀。
• 工作而言，文檔的作用降低項目里的溝通成本和風(fēng)險、反饋和迭代。文檔很好地解決了記不住、理解錯誤、歷史記錄的問題，所以還是要把所有細(xì)節(jié)記錄在文檔中比較好，這些都是要基于文檔的。
• 團(tuán)隊而言，沉淀的歷史交互文檔可以內(nèi)部共享，互相交流學(xué)習(xí)。團(tuán)隊中統(tǒng)一的交互文檔規(guī)范能提供團(tuán)隊各角色一致的文檔體驗，降低學(xué)習(xí)成本。

1. 文檔封面

就類似書籍的封面，介紹是什么書？出版社和作者是誰？主要是描述書籍的基礎(chǔ)信息。交互文檔的封面也同理，通常包括、Logo、版本號、時間、團(tuán)隊名稱或產(chǎn)品名稱、對接交互人員。

2. 修訂記錄

在實(shí)際項目中要對產(chǎn)品進(jìn)行迭代，我們會把某次迭代的版本、時間、責(zé)任人、內(nèi)容都寫清楚，方便落實(shí)責(zé)任，也方便以后追溯。

3. 項目說明

包含項目背景、需求說明、信息架構(gòu)、業(yè)務(wù)流程。

項目背景分析可以根據(jù)實(shí)際項目的需要，放置一些關(guān)于設(shè)計推導(dǎo)過程、靈感來源的文檔。

比如用研報告、用戶畫像、競品分析報告、用戶體驗地圖等一些分析過程，可以讓交互文檔也更有說服力，團(tuán)隊各角色理解后才能更好地推進(jìn)方案。

需求說明可以記錄各個功能模塊的需求背景和描述，便于后期追溯。

產(chǎn)品結(jié)構(gòu)圖作用是梳理產(chǎn)品功能點(diǎn)，梳理了產(chǎn)品有多少個功能模塊。羅列出來各個功能模塊下的各個頁面，但不需要羅列頁面中的內(nèi)容。

業(yè)務(wù)流程圖，用于說明整個業(yè)務(wù)邏輯流向；功能流程圖，用于確定產(chǎn)品功能設(shè)計邏輯。

4. 全局說明

通常包含界面標(biāo)記說明、通用控件說明。

界面標(biāo)記說明是指在整個文檔中廣泛存在的標(biāo)識元素，幫助閱讀者快速了解文檔的專用標(biāo)識和術(shù)語。

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

常用的控件比如按鈕、列表框、導(dǎo)航欄、標(biāo)簽欄以及一些網(wǎng)絡(luò)異常界面、空白頁、對話框的文案規(guī)范說明、加載方式等。

5. 交互頁面

一般而言，交互頁面顧名思義就是頁面流程、頁面內(nèi)容、交互說明，那么具體要包含哪些內(nèi)容才能把交互頁面說清楚呢？

下圖是交互文檔的局部截圖：

• 頁面標(biāo)題：告訴別人這個頁面是什么？導(dǎo)航欄標(biāo)題，讓頁面標(biāo)題常駐。
• 界面標(biāo)題：方便交互稿中的互相索引，比如“回到界面B狀態(tài)”。
• 界面內(nèi)容：建議尺寸為375*667px，內(nèi)容黑白灰稿為主，要便于閱讀。
• 交互說明：邏輯關(guān)系、元素狀態(tài)、小微流程，都可放在設(shè)計說明中。
• 流程線：說明界面間邏輯關(guān)系，可使用軟件自帶流程線。

交互說明寫什么？

交互說明中不寫什么：

• 商業(yè)邏輯相關(guān)：不寫為什么要實(shí)現(xiàn)這個功能，解決了什么問題等一些在交互說明里與產(chǎn)品實(shí)現(xiàn)無關(guān)的內(nèi)容，這是需求分析階段該做的。
• 視覺規(guī)范相關(guān)：不寫視覺規(guī)范規(guī)格標(biāo)注，各司其職專心做自己的事情，術(shù)業(yè)有專攻。
• 研發(fā)代碼相關(guān)：不寫功能代碼實(shí)現(xiàn)邏輯和規(guī)則等。

6. 廢紙簍

是指需求變動或者其他原因?qū)е履阕龅慕M件和頁面用不上了，需要將其整個優(yōu)化或者刪掉，但是不排除以后又會改回來。

你只需要將你的組件或者頁面放到回收站，標(biāo)記好相應(yīng)的名稱（為了方便下次查詢），如以后需要可直接復(fù)制到相應(yīng)的頁面。

7. 交互自查表

建立交互走查表首先需要熟悉產(chǎn)品業(yè)務(wù)邏輯，走查表是建立在產(chǎn)品功能之上，每個產(chǎn)品的交互走查表都不一樣。

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

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

三、總結(jié)

如果按照上述的7個要素來制作交互文檔并長期堅持下來，你的交互文檔規(guī)范性能夠得到大幅度提升。

以上內(nèi)容便是本文的上半部分內(nèi)容，包含了「交互文檔常見誤區(qū)」和「交互文檔7要素」，剩下的兩章：「提升輸出效率的3種方式」和「提升設(shè)計質(zhì)量的3種方式」（下篇）》中為大家奉上，敬請期待~

文中觀點(diǎn)有什么不合適的地方歡迎大家指正交流~~

本文由 @Rinoa?原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議