2022-9-2 博博
大部分的設計師應該都沒有見過所謂的“交互設計文檔”吧？在實際工作中，所謂的交互設計文檔是由交互設計師所輸出的，但是大部分的互聯網公司是沒有交互設計師的。交互設計師的工作內容被UI設計師與產品經理相互分攤。那公司為什么不招聘一個交互設計師崗位呢？（boss：呵呵～一個人能完成的任務為什么要兩個人！）
所以本篇文章為了讓我們設計師能夠很好的了解什么是交互說明文檔？它是干嘛的？有什么用？如果制作？有哪些內容等多方面全面了解。（哪里有了解的不到位錯誤的地方，也希望各位大神多多指點相互學習。讓我卷～）
交互文檔，即交互設計說明文檔（英文名“Design Requirement Document”）。又稱“DRD文檔”。用來承載交互說明、交互原型、項目背景等內容，存檔并交互項目相關伙伴的團隊協作文檔。
也許你想到：什么？交互文檔（DRD）我壓根沒見過，這難道不是口頭說說就行嘛？無需交互設計師。（大部分公司的交互文檔是由UI設計師/產品經理來撰寫）但是有的公司產品也分擔著UI設計師的工作.......只要你如果優秀干啥都行，不優秀話語權都沒有。（比如我們這些“小美工”。職位只是對一個工作的劃分不代表對你能力的劃分，只是公司的一種小手段～
回歸正題，作為交互設計師，工作職責起到“對接上下游，承上啟下”的作用，不論是在方案評審的講解，還是日常的工作溝通，都應具備優秀的溝通能力、語言表達和DRD表達能力。而DRD不僅能完美的詮釋出產品的內容和需求，還能夠為產品出一套完整的設計規范，讓產品保持一致性，方便團隊協作減少溝通成本，也方便后期的修改。
DRD是利于團隊協作的媒介，也是產品規范與項目總結的重要輸出文檔。
交互文檔撰寫并不是只有給自己看，最重要的是給：產品經理、UI設計師、開發（最需要）等等。并且作為交互設計師的輸出物，交互文檔是聯系開發流程上下游的重要文件，它需要具備良好的可讀性、唯一性和時效性。
首先不同公司，不同團隊產品經理與UI/UX設計師之間的配合輸出物是不固定的。
1. 大部分公司，產品經理細心點會連交互說明和原型一起出了（包含在PRD文檔里），但是大部分會出現體驗層的漏洞。
2. 如果公司產品是負責傳一句話，有交互設計師的情況下，交互需要從功能規劃、信息架構、原型說明一起搞了。
3. 還有在小公司比較罕見的流程就是產品搞PRD，交互搞交互文檔，彼此之間的邏輯可以互相印證。
作為交互設計師的下游，我們也需要較早的介入需求溝通之中，提早避免后期可能存在的問題出現。
（但是很多時候交互設計師就是我們自己）
開發是最需要看交互文檔的重要成員之一，因為他決定著產品的邏輯以及頁面的跳轉流程、交互方式、動效方式等等。（不過大多數公司只有簡單的PRD文檔，開發也只是簡單看看～）
你習慣用什么工具撰寫交互文檔？PPT、Sketch、AI、Axure … ？
你習慣用什么格式輸出你的交互文檔呢？PPT、PDF、HTML …？
其實使用什么工具都無所謂，只要能夠正確的描述出交互文檔所需要表達的內容和邏輯就行。（就是誰都看得懂）
我比較喜歡使用Axure軟件撰寫交互設計文檔，大家可以根據自身愛好或者公司規定進行選擇（例如sketch、figma、PS等等..都是可以的。
說了這么多，究竟交互文檔包含哪些內容呢？
一般來說，一份最基本的DRD文檔需要包含：DRD封面、更新日志、文檔圖例、產品背景、頁面交互、業務流程圖、交互原型、回收站等模塊。
DRD封面：包括產品/項目名稱、版本編號、撰寫時間、撰寫人等基本信息。按需可增加參與該項目的各方負責人。（如：產品經理，交互設計師，視覺設計師，開發，測試，團隊名稱等）
更新日志，包含具體新增或修改的內容，修改人，修改日期等信息。在實際工作中，方案的修改和優化是不可避免的。更新日志方便項目成員一目了然關注到重點更新的內容，也方便開發找到對應的負責人進行溝通，提升工作效率。
針對你在該文檔所用到的圖例進行說明，輔助閱讀（如：操作/跳轉圖例、標簽圖例、流程圖例以及手勢操作圖例。）。特別適合剛入團隊，首次閱讀你DRD文檔的人來講，是非常有利于團隊成員對你文檔的理解。
可包括一些項目背景、需求分析、用戶調研、競品分析等。用于設計思路的整理和記錄，方便閱讀，方便參與評審會的人理解整個項目背景下的設計思路，也方便日后總結與溝通。但無需將所有的分析內容都放入，結構化整理重點內容放入即可。
業務流程圖的目的就是梳理并分析優化業務流程。我知道很多同學做UI設計師的時候可以完全不管業務，直接做設計，但是作為交互設計師了解產品業務是非常重要的，因為不了解業務你就無法完成交互設計，優化業務場景。
舉個例子：在教育考試系統中一般流程是：教育局出通知→學生報名考試→老師審核→報名通過→老師編排學生考試名單→學生開始考試對號入座→教育局公布成績→學生查詢成績→考試結束，看這一些列的流程，因為關聯特別多，如果對業務不熟悉的話設計起來會非常的不便，如果前期因為業務流程不熟悉而設計出錯誤的交互稿的話，后面就會特別麻煩。
一聽： 先聽客戶/產品介紹。以最簡單的方式了解產品重點，即基本要素中的角色、活動、協作關系梳理出即可。
二溝通： 完成上一步后，就可以進行提問了。主要是沿著流程進行發問，重點放在分支、產物關系上。看看是否存在分支的情況，各協作之間是否有交付物。
三確認： 最后一步就是自己講一遍流程，和客戶代表或者業務產品進行確認是否有理解偏差的地方。
以醫院APP取號業務為例
頁面交互是交互文檔的主要內容可以詳細說明界面中元素的來源，控件的交互方式，數據的樣式，字段的長度規定，頁面元素的狀態變化等。每個交互頁面的內容應該包括：文檔頁面標題、界面標題、界面、設計說明。
文檔頁面標題：一般在每一頁文檔的頂部。寫明當頁內容是屬于哪個模塊或流程的，讓看的人不容易迷失；
界面標題：注意命名，方便交互稿中的互相聯系，如“跳轉【XX頁面】”，“回到【XX界面】狀態”；
界面：界面尺寸建議按實際界面的比例縮小，避免你想當然的設計并不符合規范，也避免一個界面太大影響閱讀效果；
設計說明：邏輯關系、操作流程或反饋、元素狀態、字符限制、異常/特殊狀態 等等，都可以放在設計說明中；
