如何寫出一份會說話的交互文檔
前言
交互文檔是交互設計師或者用戶體驗設計師與其他伙伴溝通的方式，交互文檔往往能表現設計師的專業度。那交互文檔如何有更好的表達呢？那接下來會將我們之前的文檔架構進行過分享，如果有錯誤指數請指正。
什么是交互文檔
交互文檔是一份用來與其他伙伴解釋功能優化時候的交互方式，內容優化，交互規則的文檔，日常也叫做DRD( Design Requirement Document )。
一般場景是分為大型項目和小型項目，如果是遇到大型的項目的的話需要詳細的從商業需求到最后的數據埋點驗證都要做好并且和伙伴們都要做好溝通。遇到簡單小型的項或者小迭代，基本只要連線圖就足以表達交互的設計方案，寫太多的注釋會影響到觀看者的理解成本。
交互文檔的價值
對于設計師來講能體現自己的交互的專業性，能夠體現交互工作的承上啟下的重要性。
對于上游交接的產品和項目經歷來說，會查看交互設計師方案是否符合產品的規劃和商業需求，以及方案是否有實施的可行性。
對于下游對接的UI設計師來講，要根據交互文檔里面的面的內容來繪制高保真還原圖，等繪制完高保真頁面之后并依次為根據落地。
與PRD的差異
PRD（產品需求文檔）與DRD是團隊項目中常見的文檔，而PRD出自產品經理DRD出自交互設計師。這兩個文檔是極其相似的，因為里面的內容及其相似，而且會有交叉的部分。所以新入職的團隊伙伴的理解成本比較高。
兩者本質的差異來自于兩個不同的職能崗位對一個功能優化的不同理解，產品經理主要是對一個功能的邏輯，原型圖主要是為了解釋新增或者是優化功能本身。而交互設計師主要是根據用戶場景與商業利益之間尋求一個平衡點進行合理的交互設計， 這里有個有很神奇的比喻“帶著腳鏈跳舞”。
PRD一般會順帶在原先的稿子或者是在標注中會帶有交互的元素，這種“順帶”會帶來一種錯覺就是交互應該是由產品經理來做。但是在一份有效的PRD上，交互設計一定不是核心，核心知識將新增/優化的功能進行說明，這些往往是產品經理不會涉及到的范圍。這些往往是交給UE/UI/UX設計師來完善交互方案。
查看的伙伴
業務
這里一般指的是產品或者是運營，大部分指的是產品。針對產品的部分主要是展示業務邏輯，DRD需要展示業務邏輯與用戶需求結合，從中找出設計方案。
UI設計師
這里一般指的是UI設計師，UI更注重的是要做哪些頁面？頁面之間的跳轉邏輯？報錯場景怎么處理？特殊情況怎么處理？
開發人員
這里主要分為實現工程師的和測試工程師
實現工程師：前端以及后端伙伴更關注多少個頁面/如何實現頁面？以及頁面之間如何跳轉？異常情況下什么條件下跳轉到什么頁面？
測試工程師（QA）：測試同學會根據DRD梳理測試用例，基本要覆蓋所有的交互場景和異常場景處理。
判斷好壞的標準
價值場景明確
設計本質就是了解決問題，所以在DRD中要標注出商業價值和每個頁面的用戶場景和用戶需求，降低每個協同同學的理解成本和溝通成本。
RCBC原則
窮盡原則，DRD要細致的展現出所有場景下的細節都要全部展現出來。
結構清晰
DRD常見的機構是：是什么，為什么，怎么做，結果如何。4個部分逐步進行推進減少團隊中下一步接手伙伴的理解成本，同時也讓每個同伴了解到能帶來什么商業利益（在之后的面試中也可以講這些）。
圖文并茂
DRD如果寫得像文章或者純圖片展示的話理解成本會比較高，而且在后續的查看中同學的立即的成本比較高，會增加后續要詢問的溝通陳本（雖然說后續開發人員一般看不懂不看會直接來問，但是還要減少）。
修改記錄留存
每個版本以及每次優化交互設計的記錄，都要記錄在文檔里面方便之后迭代時候方便查詢以及比對，放置重復迭代帶來的資源浪費。
唯一
DRD必須保證文檔是獨一份的，否則在后期會出現2分以及多份不同的文檔，對后期的溝通會造成比較大的分歧。
文檔架構
交互說明
封面
通常是產品的通常包括產品的名稱、Logo、所屬部門、參與人員。
文檔說明（版本說明）
一般標記當前版本和和當前版本的優化的重點
更新記錄（修訂記錄）
更新記錄是文檔中必要的部分，找那個更新記錄包含了從項目立項到現有版本的所有的改版記錄，用于團隊人員查詢和比較功能模塊的增/刪/優化在哪個時間以及優化了什么的。常見的部分有：時間，類型，內容，頁面。
時間：一般指的是上傳到協同平臺的時間，比如：藍湖，mastergo
類型：常見分為3類：新增、刪除、優化。項目中優化的場景占大多數，新增和刪除的刪除的場景很少，一般在一個階段確定之后就打上不同的標簽，之后在查看的時候就可以更直觀的看到當前版本的類型。
內容：將更新的內容（優化的功能點）全部列舉出來，分別以圖片和文件簡述形式進行描述，方便之后回溯版本的時候方便做管理。
頁面：一般是講更新的頁面對應不同的交互頁面，很少有開發同學會有耐心看完大量的文檔，直接告訴版本號即可。
閱前通知
一般指的使用DRD文檔的之前的注意事項，一些文件中包含了特殊的指導方式和關鍵詞
通用標識
泛指整個DRD文檔中常見的元素進行說明，幫助閱讀者能夠快速了解到項目的專業術語。
通用組件
一般指的是常用的交互設計師常用的控件庫，這里的理解可以參考UI的控件庫。
業務說明
產品介紹
產品介紹一般一份有效的DRD只要一個產品介紹，而且長期不用更新。產品同學提供鏟平介紹的文案。
用戶角色
這個要涉及到每個優化的部分使用的B端的角色，通常分為管理者或者是執行，往下按照只為細分可以分為：高層主管，中層主管，底層執行（具體的要看公司和行業怎么稱呼）。主要是需要讓協同伙伴了解到這個功能涉及到的那些用戶角色。
用戶場景
主要描述用戶的使用場景，方便設計師與產品同學討論時候確認這個優化的唯一性以及后續做設計的時候能夠更加符合用戶的利益。
業務需求
這一塊主要是產品對于這一次功能優化的原因，方便協同伙伴了解到背后的商業原因，從而有個更好的配合。
交互設計
設計思路
需要設計師提前跟其他伙伴講述一下業務需求以及用戶，從而引導出自己的設計理念。否則只是評審頁面的合適度，并沒有什么意義。
通用規則
展現交互設計中的共性元素進行整理，方便閱讀者整體理解。
非功能性需求文檔
為了滿足用戶需求而必備的屬性，為了其他協同伙伴了解所以要做這個部分
交互稿件
通過拖拽交互組件來展現產出物的設計方案，設計師可以根據自己的想法進行增刪。
連線的注意點：
連接的頁面不要舍近求遠
不要忘記把交互方式與交互說明忘記
連線2頭要保持不一致：觸發頁面用圓頭，到達頁面用箭頭表示，不用的話可能會邏輯混亂
盡量減少連線的交叉
交互說明導航
在進行大的優化中會有比較多頁的改變，為了方便協同伙伴查看，會將所有的說明整理出一個導航方便閱讀者點擊進行查看。
回收站
回收站是一個非常必要的部分，設計稿是一個不斷優化的過程，廢棄的稿子先別急著刪。可以把沒有用的稿子放到回收站這里，急找稿子的時候會有驚喜。
設計驗證
回收站交互走查表
針對需求和設計原則進行統一的規范，在設計完成之后要逐一進行檢查防止有疏漏。
數據埋點表
設計的數據埋點和產品的數據埋點不同，產品埋點一般針對功能使用的頻率，設計埋點針對的是用戶體驗方向（例如：操作時長，操作效率是否提高）。通常要要向開發提供針對埋點
字段和表格，并給開發講述為什么要埋這些點，以及要多長時間的數據。
文檔規范
字體
在實際工作中每個人電腦上的字體不同，導致了同樣的文件在書寫和打開的時候會有字體的差異，在后期的查看的時候一些字體甚至于識別不出來會造成亂碼從而造成閱讀困難。
在表格內的字體首行要注意加粗，不要讓表格排序過于雜亂。
編號
常見的在工作中針對編號是直接往下寫編號，但是有的時候格式刷會造成失誤，導致級別錯誤甚至于重新復制之后編號沒有更新。
文檔目錄
文檔目錄需要及時更新，有的時候著急做手里的任務會導致忘記更新，導致后面查看的時候邏輯會亂掉。
錯別字
這個是常會犯的錯誤，在輸入法拼寫的時候那面會出現錯別字，一旦出現出錯別字就會給設計師的其他伙伴一個粗心和非常不認真的印象，極大地影響到了印象分。
書面表達
在內容用詞時候，盡可能的書面化，要表達簡潔易懂還有避免歧義用詞即可。
未完成時
在未完成的時候習慣性給個標注，最好是能給的能快速定位到的標簽，方便后續完成時候快速找到。
較長文檔場景
如果遇到較長的文檔建議做一下頁碼。
一點點總結
交互文檔是交互設計師的工作產物之一，要根據項目的規模和團隊的規模進行選擇。有沒有發現我通篇沒有講設計工具？設計工具其實是并不是很重要，核心還是交互設計師自己的理念。這一篇將是我短時間內設計偏向文章的最后一個，后面會出一個設計的要懂得代碼系列，來補充大部分設計師針對前端到底是干嘛進行補一些知識，降低溝通成本和提升線上還原度。
轉載請在文章開頭和結尾顯眼處標注：作者、出處和鏈接。不按規范轉載侵權必究。
未經授權嚴禁轉載，授權事宜請聯系作者本人，侵權必究。
本文禁止轉載，侵權必究。
授權事宜請至數英微信公眾號(ID: digitaling) 后臺授權，侵權必究。
評論
評論
推薦評論
暫無評論哦，快來評論一下吧！
全部評論（0條）