編輯導(dǎo)語：交互設(shè)計(jì)文檔一般指交互設(shè)計(jì)說明文檔，又稱DRD，工作中一般稱之為“交互設(shè)計(jì)文檔”。產(chǎn)品經(jīng)理也需要學(xué)會撰寫交互設(shè)計(jì)文檔，那么，一份專業(yè)的交互設(shè)計(jì)文檔應(yīng)該如何撰寫呢？

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

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

一、為什么要寫交互文檔？

個人而言，它可以幫助你理清思路，并記錄下來，便于項(xiàng)目總結(jié)沉淀。

工作而言，文檔的作用降低項(xiàng)目里的溝通成本和風(fēng)險(xiǎn)、反饋和迭代。文檔很好地解決了記不住、理解錯誤、歷史記錄的問題，所以呀還是要把所有細(xì)節(jié)記錄在文檔中比較好，這些都是要基于文檔的。

團(tuán)隊(duì)而言，沉淀的歷史交互文檔可以內(nèi)部共享，互相交流學(xué)習(xí)。團(tuán)隊(duì)中統(tǒng)一的交互文檔規(guī)范能提供團(tuán)隊(duì)各角色一致的文檔體驗(yàn)，降低學(xué)習(xí)成本。

二、交互文檔輸出內(nèi)容是什么？

上面扯了有點(diǎn)多了，來點(diǎn)實(shí)際的吧，這是我整理交互文檔（DRD）的一個目錄，包含7點(diǎn)內(nèi)容：文檔封面、更新日志、設(shè)計(jì)過程（需求分析、信息架構(gòu)、業(yè)務(wù)流程需求列表）、全局說明、非功能需求說明、交互規(guī)范說明；廢紙簍。

當(dāng)然，這個交互設(shè)計(jì)文檔模版不是一成不變的，設(shè)計(jì)師要根據(jù)自己產(chǎn)品的需求以及內(nèi)部設(shè)計(jì)團(tuán)隊(duì)實(shí)際情況靈活運(yùn)用，不要被模版限制了想象力。

1. 文檔封面

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

2. 更新日志

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

3. 需求分析

在呈現(xiàn)交互方案前，交代清楚方案背景、具體的設(shè)計(jì)內(nèi)容；產(chǎn)品的目標(biāo)是什么，讓團(tuán)隊(duì)成員通過需求分析模塊了解這次交互設(shè)計(jì)的一些基本情況。

需求分析時，可以根據(jù)實(shí)際項(xiàng)目的需要，放置一些關(guān)于設(shè)計(jì)推導(dǎo)過程、靈感來源的文檔。比如用研報(bào)告、用戶畫像、競品分析報(bào)告、用戶體驗(yàn)地圖等一些分析過程，可以讓交互文檔也更有說服力，團(tuán)隊(duì)各角色理解后才能更好地推進(jìn)方案。

4.?產(chǎn)品結(jié)構(gòu)/信息結(jié)構(gòu)

這兩個是產(chǎn)品經(jīng)理在設(shè)計(jì)初期要畫好的，了解下就好了，他們是從兩個不同的維度來梳理產(chǎn)品的。

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

信息結(jié)構(gòu)圖作用是梳理具體頁面顯示信息。羅列產(chǎn)品各個數(shù)據(jù)元素羅列出來，只需要羅列活的數(shù)據(jù)，固定在頁面里的信息數(shù)據(jù)不需要羅列。

5.?業(yè)務(wù)流程圖/功能流程圖

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

6. 需求列表

用來整理本次需要做的需求進(jìn)行相關(guān)描述，是做哪個端口的哪個頁面及做完之后可能存在的相關(guān)影響。

7. 全局通用說明

交互設(shè)計(jì)師在輸出交互文檔的過程中，或多或少會存在的一些通用頁面、組件或說明等。如果每次都將這些組件在原型上面展示出來，不僅給交互文檔帶來冗余，還會增加交互和視覺的工作量以及理解的成本，因此對于一些產(chǎn)品的通用公共控件我都會放在這個目錄下。

1）界面復(fù)用

顧名思義就是全局可復(fù)用的一些內(nèi)頁，比如分享頁、缺省頁、搜索頁、相冊等。

2）常用組件/控件的復(fù)用

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

3）單位

規(guī)范產(chǎn)品中涉及到的所有單位，例如里程用“公里”，時間用“2021年01月14日或2021-01-14”的形式，金額用“元”或“￥”等等。以時間單位為例：

4）字符控制

每個項(xiàng)目不同，需要限制的字符名稱也不同，根據(jù)實(shí)際情況而定。

8. 非功能性需求

簡而言之就是，為了滿足用戶、業(yè)務(wù)需求開發(fā)需要考慮的需求稱為非功能性需求，這個可能會偏向技術(shù)一些具體需要前期和開發(fā)同學(xué)溝通清楚，避免后期互相扯皮，如：性能、安全等。

1）安全性相關(guān)

身份校驗(yàn)和權(quán)限：是否確認(rèn)操作者身份，從而確定該用戶是否具有對某種資源的訪問和使用權(quán)限。

文檔加密：是否對文檔進(jìn)行讀寫控制、打印控制、剪切板控制、拖拽、拷屏/截屏控制、和內(nèi)存竊取控制等技術(shù)，防止泄漏機(jī)密數(shù)據(jù)。

表單驗(yàn)證：是否要考慮表單驗(yàn)證呢？一般后端為了安全性必須校驗(yàn)，前端驗(yàn)證可以提升用戶體驗(yàn)（及時反饋狀態(tài)），減少無意義的請求，可以選擇性驗(yàn)證。

防攻擊策略：針對惡意操作是否需要IP限制、是否需要高頻訪問限制等等的考慮。

2）性能相關(guān)

響應(yīng)時間：是系統(tǒng)最重要的性能指標(biāo)，直觀的反映了系統(tǒng)的快慢。是否對響應(yīng)時間有要求，響應(yīng)時間太長怎么辦呢？

并發(fā)量：單位時間內(nèi)成功地傳送數(shù)據(jù)的數(shù)量。這一塊與系統(tǒng)并發(fā)相關(guān)，根據(jù)業(yè)務(wù)量估計(jì)，我們的系統(tǒng)需要支持多少并發(fā)，確定支撐項(xiàng)目所需要的服務(wù)器配置。

吞吐量：吞吐量是指單位時間內(nèi)系統(tǒng)能處理的請求數(shù)量，體現(xiàn)系統(tǒng)處理請求的能力，這是目前最常用的性能測試指標(biāo)。

3）用戶體驗(yàn)相關(guān)

數(shù)據(jù)加載：進(jìn)入新頁面的時候，數(shù)據(jù)如何加載，用什么樣式提示用戶頁面正在加載，需不需要異步加載來提高用戶體驗(yàn)等等。

Dialog和toast：各種臨時框和toast的樣式和文案的規(guī)范說明等。

統(tǒng)一組件：此時將系統(tǒng)功能模塊化，支持靈活配置，有利于減少重復(fù)開發(fā)量。

網(wǎng)絡(luò)異常處理：網(wǎng)絡(luò)異常時、網(wǎng)絡(luò)切換時（從WiFi狀態(tài)到蜂窩狀態(tài)）、網(wǎng)絡(luò)中斷等情況下的交互設(shè)計(jì)。

4）其他

兼容性：產(chǎn)品在不同系統(tǒng)/終端之間和不和諧、融不融洽的意思。

升級策略；強(qiáng)制升級時產(chǎn)品怎么處理？非強(qiáng)制升級時產(chǎn)品怎么處理？升級的彈框和文案是怎樣的？是否在URL中預(yù)留版本號。

國際化：考慮產(chǎn)品是否需要支持國際化，比如不同語言環(huán)境中，是否需要在開發(fā)時將產(chǎn)品界面中和提示文案全部寫在一個配置文件中，根據(jù)當(dāng)前運(yùn)行的系統(tǒng)語言環(huán)境，會自動識別和判斷應(yīng)該加載那個文案配置文件來顯示界面文案。

用戶行為分析埋點(diǎn)：是否需要做埋點(diǎn)？是公司自己后臺做統(tǒng)計(jì)還是借助第三方數(shù)據(jù)統(tǒng)計(jì)平臺？

9. 頁面交互流程圖

1）交互稿結(jié)構(gòu)怎么組織

交互稿的結(jié)構(gòu)依賴于產(chǎn)品架構(gòu)圖，把各個頁面的功能層級表現(xiàn)出來很容易地找到就行，可以從【平臺-功能-頁面-子頁面-子頁面分支】這個維度去搭建樹形結(jié)構(gòu)，結(jié)構(gòu)搭好完后剩下的就是對文檔的命名了。

2）每頁交互稿的內(nèi)容

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

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

3）交互說明寫什么？

接下來就要開始我們交互文檔最為關(guān)鍵的部分了，如何書寫交互說明呢？

記得剛開始寫交互說明的時候不知道要寫些什么，寫完之后總感覺哪里不對勁，卻又發(fā)現(xiàn)不了問題在哪里，能咋辦呢？就是很絕望呀！后面就請教同事要怎么寫交互說明才不會被懟呢，然后他就直接發(fā)給我的一份交互說明自查表，這里也做了一些整理供參考。

另外我們交互說明應(yīng)該盡量寫得詳細(xì)些，這樣最終的驗(yàn)收效果也會比較好。

4）交互說明中不寫什么

• 商業(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ī)則等。

10. 廢紙簍

廢紙簍，被稱為是交互文檔的“后悔藥”。在改了很多稿的交互稿中你永遠(yuǎn)不知道哪一稿才是最終稿，所以，請把你遺棄的稿子放這里！萬一老大很喜歡第一稿呢…

三、綜上所述寫文檔需要注意什么

• 文檔規(guī)范化：交互稿目錄命名規(guī)范、頁面布局規(guī)范、交互說明的精簡、使用黑白灰稿，這對于提高交互文檔的易讀性至關(guān)重要；
• 數(shù)據(jù)真實(shí)化：頁面的展示元素要還原真實(shí)的場景，有代入感才能發(fā)現(xiàn)交互文檔中更微妙的細(xì)節(jié)；
• 任務(wù)流程化：一個頁面一個任務(wù)，一個任務(wù)從開始到結(jié)束要邏輯清晰、有閉環(huán)；
• 交互組件化：建立起自己的交互組件庫，組件不在多在于精，要持續(xù)更新；
• 方案明確化：很忌諱臨時更改交互文檔或文檔中的說明含糊不清，如果不可避免也要及時通知相關(guān)人員。

四、后記

不管用什么形式或工具撰寫交互設(shè)計(jì)文檔，只要能提高效率、降低溝通成本、設(shè)計(jì)方案是否滿足用戶需求就能體現(xiàn)文檔的價值了。

另外，在交互文檔中并不是說交互稿畫的多美觀就很專業(yè)，說明文字信息的層級清晰能看懂就行，更重要的是基于你輸出內(nèi)容的背后思考。

以上為小編在實(shí)際工作中寫交互文檔的一些粗略總結(jié)。

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

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