談談原型設計中配備的原型互動規格說明書（DRD）

編輯導語：在實際專案中，產品經理可以透過原型互動設計文件，即DRD將設計方案與實際需求傳達給其他團隊人員，以降低溝通成本，推動產品後續開發。本篇文章裡，作者總結了原型互動規格說明書（DRD）撰寫的相關問題，一起來看一下。

大家好，上一期我講了“

產品經理應該如何有效地開展原型設計的工作

”，結合上期的內容，這期咱們以“

淺談原型設計中配備的原型互動規格說明書（DRD）

” 為課題來進行探討。

在實際的專案中，設計方案如何傳達給開發人員和視覺人員，如何將一個需求所涉及到的多個頁面以及每個頁面的規則準確地傳遞給相關人員？

在整個開發過程中，如何維護並改進方案，並且將改進過的結果展示給相關人員，保證在後面的迭代過程中都做一個存證？

每個設計方案可能會經過很多次的迭代，也可能會有多個版本，那如何保證在一個文件裡面體現多個版本的迭代呢？

這就引出了原型互動設計文件的概念，

原型互動設計文件也被稱之為DRD（Design Requirement Document）

。

這期我們主要

圍繞淺談原型互動規格說明書（DRD）的規則、原型互動規格說明書（DRD）的結構分析、撰寫原型互動規格說明書（DRD）的注意事項

這三個方面來進行闡述。

一、淺談原型互動規格說明書（DRD）的規則

一個完整的互動設計文件，不只是一個簡單的原型設計文件，而是一套體系、一個完整的產品，所以我們從產品的角度來給大家分析一下互動文件。

互動設計說明書是指用來承載互動設計說明，並交付給前端、測試以及開發工程師參考的文件，是產品經理和互動設計師的一項基本功。它是把抽象的產品需求轉化為具象的線框圖呈現的過程，在互動設計日常工作輸出的最終產物，用來告訴別人「頁面設計細節」的一個說明文件。

在專案中，產品經理或者互動設計師的主要產出物可能依次是：

站點地圖（site maps）、頁面流（flow charts）、線框圖（wireframes）、視覺樣式（screen designs）

。

如果需要對互動設計進行說明，有些產品經理或者互動設計師往往會直接標註線上框圖裡，或者在專案中不斷和前端工程師和開發工程師口口相傳，反覆驗收，不斷迭代修改來確保所有的互動設計意圖最終得以呈現。

然而這樣做可能會浪費很多時間，甚至意圖傳達不夠清楚，以及標註線上框圖裡的說明也不夠清晰（再加上能夠被標註的空間和條件非常有限，所以只能對一些主要或者特殊的功能和資料進行備註，無法做到面面俱到）。

在這樣的情況影響之下，那麼就需要將這些做法給規範一下。

這就需要一份互動稿子，產品經理或者互動設計師的工作雖不只是畫互動稿子，但是好的互動稿不僅能夠完美闡釋產品內容和產品經理或者設計師的設計思路，還能夠在專案各方協調工作中起到重要作用。

保證完整的呈現產品需求和設計思路的互動稿，能夠讓各方工作人員有一致的工作目標，而有良好體驗的互動稿，還能夠便於各方理解，從而提高後期開發對設計的還原度，提高各方工作效率。

全域性頁面說明主要包括Z軸內容層級、X軸和Y軸適配方案、整體跳轉邏輯等，這些均需要在產品研發前期通知前端、視覺等協作同事的。

準確傳達自己的整體產品設計思路，便於他們進行框架搭建或者視覺定義。另外，還可以指導後期複雜需求的互動設計。

全域性互動則是為了元件化設計，不僅保證產品設計的一致性，也能夠提高視覺和開發工作效率。

單頁面文件設計

由於每一個頁面的內容比較豐富且互動邏輯複雜，所以逐漸形成了每一個文件頁面只做一個頁面的設計規則，保證設計文件中的頁面與真實產品中的頁面一一對應，便於互動文件按照產品業務組織和減少協作方查詢內容時間。

單頁面設計其實與一個頁面只講一件事情的設計方法相通，在表述本頁面內的設計內容時要說明清楚每一個與其他頁面關聯的使用者接觸點從哪裡來到哪裡去，保證開發、QA們閱讀互動說明的時候能夠理解當前頁面內容與其他內容的關係。

統一頁面內容佈局

作為互動文件，它的目標使用者比較明顯的主要是與我們協作的前後端開發、QA們、視覺小夥伴，其實我們可以很簡單地就瞭解到他們幾乎90%都在使用公司配置的顯示器，公司配置的顯示器基本尺寸為1920*1080，所以便可以根據顯示器的尺寸定義Web頁面大小、互動說明顯示區域等，這樣便可以儘量保證在首屏內顯示相關內容。

另外，根據對開發的瞭解，他們較為習慣Y軸方向瀏覽資訊（其實感覺大部分人都喜歡Y軸方向瀏覽資訊），因此文件頁面和互動說明佈局以縱向為主，在他們單方向瀏覽時，保證所有互動點都能看到。

主頁面

比如，運營平臺中有需要在表格中橫向顯示十幾項資訊內容。

1。儘量使用灰階色

不少產品經理或者互動設計師做互動稿的時候是非常認真的，會盡量做高保真的設計，有藍色或綠色按鈕、橙色的警告圖示等，有時候還會直接用視覺設計定義的視覺色彩規範去做互動稿，呈現出完美的互動稿。

說實話真的是很漂亮的互動稿，幾乎不需要視覺設計師做什麼修改。這樣完美的互動稿卻在無形中對視覺設計師、開發、QA們造成了困擾。

對於視覺設計師來說，在互動稿中出現的那些彩色其實會對他們做視覺設計造成一定的干擾，表示不同明度的灰色調，其實他們是能夠理解到互動設計師所要表達的意思的。

另外，互動稿中彩色內容還會成為視覺焦點，跟開發和QA們有溝透過，他們表示這會無形中干擾對互動邏輯和細節的關注。

2。統一字號和字型

比如統一使用微軟雅黑，選擇這個字型純屬因為它是無襯線字型，看著簡單，而且微軟雅黑是各瀏覽器適配系統字型時的常用預設字型。

字型中有一個正常頁面文稿唯一可以使用的彩色，即警告色#ff6666（彩色也儘量使用飽和度較低的彩色）。

除了主要定義了自定義灰度色系、字號，還有4px間距、頭像尺寸、品牌色。

3。不同型別的需求應有不同的方法呈現設計

產品需求大致可以分為兩大類：任務型和資訊型需求，針對不同型別的需求要能夠透過一些基本的設計方法去呈現我們的設計。

比如，對於任務型需求，我們可以提供必要的流程圖去幫助開發和QA們更好地理解使用者在完成任務的過程中可能會走到哪裡，有助於他們進行研發設計和測試設計。

那麼對於資訊型需求，則提供資訊結構圖和業務架構圖，讓他們在宏觀上能夠更好地理解需求。

4。互動說明應便於閱讀和查詢

互動說明中儘量字型稍微大一些，互動說明的字型大小我們使用的是16px，比一般字型會大2px，這一方面可以區分互動說明文案內容和頁面內容，另一方面也便於開發和QA們閱讀。

面上內容與互動說明的組織方式可以有很多種，比如，畫上連線線、編號標記等。

我們組目前做的業務需求還是都比較複雜的，考慮到不想讓頁面變成編織網一樣的東西，便採取了實用編號標記的方式去組織互動說明。如果互動說明中出現不同內容的點需要再次寫互動說明的時候，編號採用N-N的形式，互動點中每一條互動內容以中劃線開頭，互動內容中如果再有分級，便可使用無序編號等等，依次類推下去。

如果互動說明中出現與其他頁面的關聯，著重標出來，這樣便於開發和QA們在閱讀的時候能夠很快定位跳轉或回跳頁面，明確本頁面與產品其他部分的關係。

5。互動說明應具有邏輯性

邏輯性或許是每一個設計師的必備屬性，我們使用MECE也好，使用邏輯樹分析法也好，都是讓我們能夠遍歷或窮舉我們想要寫的互動點的各種情況的。

這裡我主要想說的是要真正的具有邏輯性，我接觸的一些設計師，雖然也能對一些使用者接觸點做出詳盡而無遺漏的說明和解釋，卻經常會出現說此言彼的情況，使得互動說明冗雜而不易閱讀。

而真正的具有邏輯性，是能夠清楚自己在每一個使用者接觸點上想要說明的場景和處理方式，儘量減少各個使用者接觸點的交叉說明，保證互動說明思路清晰而內容詳盡。

6。互動流程應具有封裝性

封裝性的概念其實來源於研發中程式碼封裝的概念，說的是如果一個方法被封裝好了，當使用到這個方法時，只需要傳入不同的引數便可以得到想要的結果。

這裡我引用到流程的封裝上，一個全域性性的需求流程可能是不一樣的，定義好變數引數，便可以在不同的模組呼叫這塊邏輯。這是比較符合開發們設計程式碼的主要思路的，所以和研發們解釋起來是非常順暢的，而且能夠減少重複設計。

二、原型互動規格說明書（DRD）的結構分析

那麼，一份好的DRD文件應包含哪些內容呢？以下是我整理的DRD輸出思路，僅供交流或參考。內容源自工作經驗的總結，源自同事的溝通及反饋，源自過往閱讀過的相關文章的總結。

當然，這個互動設計文件模版不是一成不變的，產品經理或者設計師要根據自己產品的需求以及內部設計團隊的實際情況來靈活運用，不要被模版限制了想象力，其實變來變去，就這麼多內容。

文件封面：團隊/專案資訊+版本資訊+時間等。

更新日誌：文件中更新的部分及對應的更新人員，方便他人檢視。

文件圖例：文件中所用圖例的說明及其意義。

設計背景/思路（設計過程/文件說明）：需求分析表結構、產品結構/資訊結構、業務流程/功能流程圖、需求列表。

業務流程：產品的核心業務流程（也可以在互動原型稿中隨頁面流程一同展示，根據實際需要制定）。

全域性通用說明（全域性說明）：包括常用的互動控制元件、全域性可複用的介面、單位的規範、時間規範、預設頁彙總、動效說明、語音說明、安卓說明、打點說明等。

非功能需求說明：為了滿足使用者，業務需求開發要做的事情、如安全、效能等。

頁面互動：文件的主體（包括資訊架構圖、操作流程圖、頁面互動流轉、互動說明等），並根據頁面的層級優先順序，實際情況進行編號命名。

回收站：存檔一些暫時不需要的內容，方便後期呼叫；被稱為是互動文件的“後悔藥”。在改了很多稿的互動稿中你永遠不知道哪一稿才是最終稿，所以，請把你遺棄的稿子放在這裡！萬一老大很喜歡第一稿呢？誰也說不準！

1。設計背景/思路的簡述

下面對原型互動說明書的一些主要的部分進行講解一下，至於文件封面、更新日誌、文件圖例在這裡就不一一敘述了。

1）需求分析表結構

產品名稱：平臺/系統名稱。

專案背景：首先，要明確問題是什麼。產品或者這塊相關的資料出現了什麼問題，或者在核心業務目標上出現了什麼問題，這些都是問題的定義（為什麼要做這個功能）。

其次，明確要解決什麼問題。這裡透過專案背景推匯出業務訴求，也就是業務/產品目標。

最後，產品目標是產品能得到什麼樣的結果，對產品來說可以獲得什麼樣的好處。所以在互動文件的設計中要重點體現出產品目標。透過明確產品目標，可以清晰地指導我們做的互動方案。

使用者物件：透過對現有產品的使用者畫像得出我們的使用者群體，明確為誰而設計。

場景分析：依據使用情景分析（即使用者故事的方式）互動情景。

使用者目標：使用者想要的是什麼？使用者透過這個功能想要達到什麼樣的好處和目的，可以透過使用者畫像等研究方法，大的專案可能需要更多維度的分析才能夠明確使用者目標。

設計目標/設計思路：根據業務目標和使用者目標，推匯出設計的目標，提高使用者活躍度，基於業務升級的視覺體驗（產品架構升級、提升閱讀轉化、促進使用者活躍、視覺品牌升級）。

核心資料：提到的業務目標、使用者目標、那麼跟這幾個目標相關的那些資料能在專案上線後證明目標是不是達到了，他們就是核心資料，在這裡都要明確出來。

專案風險：優化了某些功能很有可能會給其它模組帶來一些負面的影響，這裡要明確出有可能會出現的風險，然後評估一下風險的大小。

若風險可以忽略，那專案就能夠執行下去，若風險的負面影響大於整個專案的收益，那就要另做考慮了。

2）產品結構/資訊結構

在設計初期要畫好的，它們是從不同的維度來梳理產品的。

產品結構圖作用是梳理產品功能點，梳理產品有多少個功能模組。羅列出來各個功能模組下的各個頁面，但不需要羅列頁面中的內容。

資訊結構圖（也就是思維導圖）的作用是梳理具體頁面顯示資訊。羅列產品各個資料元素羅列出來，只需要羅列活的資料，固定在頁面裡的資訊資料不需要羅列。

3）業務流程/功能流程圖

業務流程圖，用於說明整個業務邏輯流向。

功能流程圖，用於確定產品功能設計邏輯。

4）需求列表

用來整理本次需要做的需求進行相關描述，是做哪個埠的哪個頁面及做完之後可能存在的相關影響。

如果每次都將這些元件在原型上面展示出來，不僅給互動文件帶來冗餘，還會增加互動和視覺的工作量以及理解的成本，因此對於一些產品的通用公共控制元件儘量都放在這個目錄的下面。

2。非功能需求說明的簡述

1）安全性相關

身份校驗和許可權：是否確認操作者身份，從而確定該使用者是否具有對某種資源的訪問和使用許可權。

文件加密：是否對文件進行讀寫控制、列印控制、剪下板控制、拖拽、拷屏/截圖控制、和記憶體竊取控制等技術，防止洩漏機密資料。

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

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

2）效能相關

響應時間：是系統最重要的效能指標，直觀地反映了系統的快慢。是否對響應時間有要求，響應時間太長怎麼辦呢？

併發量：單位時間內成功地傳送資料的數量。這一塊與系統併發相關，根據業務量估計，我們的系統需要支援多少併發，確定支撐專案所需要的伺服器配置。

吞吐量：吞吐量是指單位時間內系統能處理的請求數量，體現系統處理請求的能力，這是目前最常用的效能測試指標。

3）使用者體驗相關

資料載入：進入新頁面的時候，資料如何載入，用什麼樣式提示使用者頁面正在載入，需不需要非同步載入來提高使用者體驗等等。

Dialog和toast：各種臨時框和toast的樣式和文案的規範說明等。

統一元件：此時將系統功能模組化，支援靈活配置，有利於減少重複開發量。

網路異常處理：網路異常時、網路切換時（從WiFi狀態到蜂窩狀態）、網路中斷等情況下的互動設計。

4）其他

相容性：產品在不同系統/終端之間和不和諧、融不融洽的意思。

升級策略；強制升級時產品怎麼處理？非強制升級時產品怎麼處理？升級的彈框和文案是怎樣的？是否在URL中預留版本號。

國際化：考慮產品是否需要支援國際化，比如不同語言環境中，是否需要在開發時將產品介面中和提示文案全部寫在一個配置檔案中，根據當前執行的系統語言環境，會自動識別和判斷應該載入那個文案配置檔案來顯示介面文案。

使用者行為分析埋點：是否需要做埋點？是公司自己後臺做統計還是藉助第三方資料統計平臺？

3。頁面互動的簡述

1）互動稿結構怎麼組織

互動稿的結構依賴於產品架構圖，把各個頁面的功能層級表現出來很容易地找到就行，可以從【平臺-功能-頁面-子頁面-子頁面分支】這個維度去搭建樹形結構，結構搭好完後剩下的就是對文件的命名了。

2）每頁互動稿的內容

一般而言，互動頁面顧名思義就是頁面內容、互動說明，那麼具體要包含哪些內容才能把互動頁面說清楚呢？

頁面標題：

告訴別人這個頁面是什麼？導航欄標題，讓頁面標題常駐。

介面標題：

方便互動稿中的互相索引，比如“回到介面B狀態”。

介面內容：

建議尺寸為375*812px，內容黑白灰稿為主，要便於閱讀。

設計說明：

邏輯關係、元素狀態、小微流程，都可放在設計說明中。

流程線：

說明介面間邏輯關係，可使用軟體自帶流程線。

連結：

指向其他頁面，比如，支線流程，開發閱讀起來也會很方便。

3）互動說明

頁面元素

所謂的頁面元素，就是規定頁面內應該存在什麼內容，應用什麼樣的控制元件等，以及規定這些存在內容的樣式。

狀態變化_預設狀態

預設選項（比如常見的《使用者協議》需先勾選才能夠繼續操作，那在預設狀態下是勾選還是未勾選）；預設文案/頭像（比如未填寫個性簽名的使用者給與預設文案）；預設鍵盤（數字鍵盤、拼音鍵盤、英文鍵盤）；預設排序（按最新時間排序，還是按閱讀排序）。

狀態變化_正常狀態

使用者正常使用時，會遇到的狀態，如未登入/登入，未認證/稽核中/認證失敗/認證成功等。

狀態變化_特殊狀態

操作錯誤（當用戶出現操作錯誤時，應該如何提示）；載入失敗（比如淘寶首頁的某張圖片顯示失敗，這時應該如何顯示）；空狀態提示（當沒有資料時應該如何顯示，比如搜尋無結果；頁面重新整理狀態（點選重新整理、自動重新整理、下拉重新整理、上拉重新整理、區域性重新整理）；頁面被刪除、檢測到無網路（WIFI和4G提醒）。

限制條件_資料顯示限制

最小限制、最大限制、極限值、位數限制等。

限制條件_範圍值限制

資料的取值範圍、不滿足時解決方案，提示使用者輸入限制的條件。

使用者操作_操作手勢

常見的手勢操作有單擊、雙擊、左滑、右滑、長按、拖拽、滑動、縮小、放大、按壓、雙指點選、旋轉、按住拖拽、下擊、抬起、夾捏等。

使用者操作_文字框等

獲取焦點、失去焦點（比如APP鍵盤的撥出和隱藏）。

使用者操作_熱區範圍

哪些區域可點選，標註出來，並說明點選範圍是多少。

誤操作極端操作。

反饋效果

觸覺/聽覺/視覺；反饋何時顯示和消失；提示內容（系統對使用者操作的及時反饋，比如，報錯提示（錯誤內容-糾正資訊）、失敗提示、成功提示等）；反饋方式（跳轉形式是新頁面（新頁面或者當前頁面），還是彈出窗，寫清楚標號和頁面名稱）；狀態變化（比如，購物車裡的商品，當商品取消勾選時，立即購買按鈕是不可點選的）；提示形式（提示的控制元件樣式，比如彈出框是否可關閉等）；過渡動畫（轉場方式）。

4）其他

使用者身份：

使用者身份和系統功能頁面緊密相關，遊客使用者（未登入），普通使用者（已登入）；會員和非會員使用者；認證使用者和非認證使用者；某個等級以上使用者。

站內信和推送：

當完成某步操作後，是否需要觸發訊息通知使用者。

新老版本相容問題：

老版本內沒法顯示新版本的某項功能，告知使用者。

鎖屏推送：

比如，APP可能有鎖屏的推送。

資料埋點：

為上線後統計分析提供基礎。