最新資訊：

交互文檔該怎樣寫呢？這個問題不只是新手在問，在工作中要負責交互問題的產物司理、設計師，都在糾結這個問題。本篇文章就從根基熟悉、東西選擇和建造進程這三部門內容來為大師講授交互文檔要怎樣寫，快來看看吧。

2023-07-22 要分享的，是后臺和社群里幾近天天都有人問的交互文檔該怎樣寫的問題。不只是想要往交互設計師標的目的成長的新手，還有工作中要負責交互問題的產物司理、設計師，都對它存在年夜量的疑問。

所以我們在2023-07-22 這篇分享里完成一次深切的掃盲。

1、交互文檔的根基熟悉1. 交互文檔是甚么

交互文檔，是一份用來注釋項目交互體例、內容、法則的申明文檔，也叫 DRD ( Design Requirement Document )。

在曩昔的分享中，我們有注釋過，B端項目會包括年夜量的交互內容，需要前期繪制交互原型來展現和確認交互方案。

假如是比力簡單的小型項目，或成熟產物的小迭代，那末如許的連線圖確切就足以表達交互的意圖和方案了，寫太多注釋文字反而會弄巧成拙提高不雅看者的認知本錢。

可是，假如項目和展現的流程內容，邏輯很是復雜，包括很是多的選項和狀況，那末單靠原型和連線是絕對不敷的，添加更多的圖文申明就變得很是有需要了。

同時在團隊協作場景中，就需要將這些內容建造成一份規范的 “文檔”，用來進行同一的展現、備份、歸檔。

所以做交互光靠畫交互原型是不敷的，“文檔” 就成為需要的輸出功效。

2. 它和產物文檔的區分

在產物側（非開辟），文檔就有好幾類：

貿易需求文檔：BRD,Business Requirement Document市場需求文檔：MRD,Market Requirement Document產物需求文檔：PRD,Product Requirement Document交互申明文檔：DRD,Design Requirement Document設計規范文檔：DGD,Design Guidline Document

BRD 和 MRD 是一個產物司理行業內部也在頻頻科普會商的工具，和我們沒多年夜關系可以臨時疏忽。設計規范文檔 DGD 大師應當也有概念，比力輕易辨識，也不需要在這里強調。

而產物需求文檔 PRD，是和交互文檔最撞臉的文檔類型。它們的文檔規格、樣式幾近一致，還包括年夜量邊界恍惚、彼此交叉的內容范圍，會對新手的理解造成很年夜的未便。

要理解產物文檔和交互文檔的焦點差別，就得從他們各自的工作本能機能說起，產物司理的首要產出是注釋產物要做的功能和邏輯，所有的原型和連線的方針都是為領會釋功能自己。

部門產物司理會 “順帶” 在這個根本上增添交互的元素，和相干的申明。這恰好是問題的要害地點，由于產物司理建造產物原型的進程是可以籠蓋一部門交互信息的，所以良多設計師也無邪的認為交互內容是應當由產物來出的。

這傍邊必然要存眷里面的 “順帶”，由于一份有用的 PRD 大旨必然不是以交互為焦點的，在面臨需要年夜量圖例、連線、方案、注釋的交互問題下面，產物司理常常選擇直接跳過，只把功能描寫清晰，剩下的就交給交互設計師仍是 UI 設計師來完成具體的交互方案。

所以，交互文檔就是在產物文檔的根本上，進行交互內容的彌補，專注于注釋項目標交互內容，讓設計師和前端開辟可以更直不雅得理解后續的工作內容。

來自 UEDART 的付費文檔，案例地址：http://vip.uedart.com/interactive.html

交互文檔和產物文檔是彼此自力和彌補的，當產物文檔沒法完成對產物交互的有用注釋時，我們就應當選擇輸出自力的交互文檔，來晉升項目協作的效力。

2、交互文檔的東西選擇1. 主流的交互文檔東西申明

主流的交互文檔輸出有三種體例：

Axure/墨刀 導出一般文檔建造線上 Wiki 記實

Axure 和墨刀是用來建造產物原型的軟件東西，也是今朝在產物司理、交互設計行業中利用最普遍的原型東西。

它的首要優勢，在于可以比力便利的建造可交互的組件、連線、導出。

固然，光建造原型圖其實不能叫交互文檔，它們還供給了比力周全的內容標注、文本記實、圖形繪制的功能。

這便可以讓我們完成原型繪制今后，連系頁面布局的治理，添加交互文檔所需的其它信息，并終究輸出文件。

而在一些比力傳統的行業或外包范疇，利用的記實文檔常常要利用 Word 或 PPT（便利開會演示或要打?。?。這就要在原型完成今后，導出原型圖例，并利用這些文檔軟件進行文字的記實和連線。

受限于 Word、PPT 的結構限制（強行分頁），利用它們做交互文檔長短常難熬難過的，而且這些文檔需要保留到當地，存在各類文檔版本治理的問題。

所以還有另外一部門也但愿利用通俗文檔格局記實，并知足云端同步、備份、版本治理的團隊，就會利用 Wiki 類的東西來建造交互文檔。如語雀、飛書、Confluence、Notion 等東西。

假如只是一些比力小的項目迭代、一次性利用的交互文檔，利用前兩種方式都可以勝任。而真正年夜型、系統性的交互文檔，常常都利用團隊內部的 Wiki 進行建立和治理。和設計稿分歧，這些利用了內部賬號或需要內網拜候的文檔資料，是不會沒事發到網上來分享的，這也是在網上找不到完全交互文檔的首要緣由。

2. B端設計師的交互文檔東西建議

和你們網上可以找到的年夜大都交互設計干貨分歧，我即不保舉你們利用 Axure/墨刀 來畫原型，也不保舉用它們或通俗文檔、Wiki 的情勢來輸出交互文檔。由于：

—— 太低效了！

產物司理和交互設計師的首要產出物就是文檔，天然可以花費比力多的精神和時候去建造原型和編寫內容。而 UI 設計師的首要工作必定是終究的視覺界面和交付，所以用最復雜的方式去建造交互文檔，明顯是不公道的。

同時還要提一句，Axure/墨刀 等軟件用來建造一般的線框圖原型，效力其實是太低了。且絕年夜大都環境下的頁面跳轉、交互都是可以疏忽不做的。并且隨頁面增添，它的左邊導航層級、數目會很是重大，致使查找和閱讀的效力進一步下降。

我始終都建議直接利用你們正在用的云端 UI 設計軟件直接繪制產物、交互原型并輸出文檔，如即時設計或 Figma。緣由包括：

速度快：能用 Axure 五分之一的時候完成所有原型繪制可復用：做好的原型便利復用，并且可以直接在原型上完成后續設計交互性：對表達交互流程所需的根本跳轉和動效都能知足更自由：一些需要復雜圖文連系的申明體例不再遭到通俗文檔結構限制

好比下面如許的原型案例，便可以經由過程一個簡單的鏈接快速分享出去，或添加團隊成員自由查看。

在我曩昔持久的實踐體味中，這類體例是優勢最較著、效力最高、最易懂，也合適 UI 設計師工作需要的。假如項目中有其它身分要求，你們也能夠選擇前面的體例輸出。

任何文檔的方針都是為了書面記實和讓看的人更輕易理解我們要表達的信息，不要被固定的方式局限住，要盡力去摸索合適團隊當前場景的體例。

3、交互文檔的建造進程1. 文檔框架布局制訂

前面把根基的信息聊完了，這里就來具體講講交互文檔應當若何進行輸出。

固然，輸出交互文檔前需要先理解交互是甚么，交互設計的具體設計內容和步調。交互文檔是對你已設計出來的方案的書面記實，你不克不及在對交互全無所聞的環境下強行編寫文檔。

交互文檔建造起首要確認文檔的記實內容和文檔布局。

記實內容指的是你在該文檔預備放哪些交互內容進去，其實不是每次項目設計都要把項目所有頁面和流程交互都重做一遍。

好比一次中等范圍的迭代，新增幾個通用的列表頁面，調劑了一些細節字段，增添了一個功能流程。那末文檔重點記實內容必定就是流程而不是所有頁面。究竟通用的列表頁和細節更改，在產物需求評審階段便可以完全的注釋，而功能流程則不可。

假如是全新的項目，包括數十上百個頁面。把所有流程、頁面的交互內容全數表示出來的工作量是頂不住的，在繪制原型的進程中，你就會發現有年夜量的反復頁面、流程和交互。所以建造文檔就要有目標性的對反復的內容進行歸并，和只保存主要的頁面和流程。

具體該放甚么要斟酌項目標現實環境，需要設計師本身評估。除此之外，尺度的交互文檔里面會包括布景介紹、編纂日記、文字圖例、營業流程、名詞注釋、頁面布局等等。

這些 “文縐縐” 的細節，其實不是必備的，你可以按照當前場景本身決議需要加哪些。好比項目、營業布景前面的產物需求已講清晰了，營業流程、名詞注釋團隊成員也都洞若觀火的時辰，那末這些頁面模塊就完全沒有放的需要。

而且，基于前面臨放置內容的斟酌，布局的挨次其實不必然要近似下方案例，完全依照產物的導航目次來走。

所以，按照一個中等范圍的迭代項目，我會制訂一個如許的一級文檔布局：

根基信息：項目標簡單信息，快速目次，介入人信息等根基組件：觸及的相干組件展現和交互法則申明原型一覽：本次迭代觸及的所有頁面原型和連線一覽流程介紹1：流程1的所有頁面、狀況、申明展現流程介紹2：流程2的所有頁面、狀況、申明展現流程介紹3：流程3的所有頁面、狀況、申明展現

每一個1級文檔布局對應 UI 軟件中的 Page 目次，力圖所需的 Page 數目越少越好，而不是像 Axure 的做法一樣密密層層的。

布局可以按照復雜水平做進一步的細分，它像寫文章的綱領一樣，幫忙我們提早計劃好后續完成文檔所需的內容和工作量。

2. 關于連線和標注信息

有告終構，就要在對應的 Page 中填充內容了。此中一般的文字介紹、流程圖、思惟導圖，只要正常輸入或將導出的圖例黏貼進來便可以。

而針對具體的交互內容，流程注釋上，則重點處置連線和標注申明。好比下面是我本身在課程演示中的一個簡單的交互流程演示案例。

在 UI 軟件中，建造連線實際上是很簡單的工作，只要畫出一個直線，再設置箭頭和尾部圖形、描邊色采和粗細便可。

然后，將該線段的圖層放置在畫布以外，出發點放置在觸發交互的區域當中，終點尖頭則緊貼方針畫布的邊沿（不消特地延長進畫布內）。假如利用程度、垂直的體例毗連兩個畫布，那便可以雙擊進去添加錨點建造 90 度的折角。

連線的利用長短常簡單的操作，不要舍本逐末經由過程插件或是其它的一些功能來實現。而除此以外，我在文檔中添加的注釋性文本首要有兩種，交互事務和交互法則。

交互事務代表了連線的兩個頁面是若何被觸發跳轉的，所以我會在線段中帖一個文字卡片，注釋觸發的前提和交互操作是甚么。

然后，就是頁面或流程中的交互細則，包括兩個部門，數字標簽和對應文字注釋。它們都是用 Auto layout 可以快速建造出來的組件，每次要做備注的時辰，只要復制標簽到頁面上，設置對應的數值，再將右邊的文字卡片復制到頁面旁邊，再加上對應的數字、內容信息便可。

在設計軟件中，畫布的自由度極高，你想要怎樣備注和添加內容都不妨，只要在內容翔實的根本上包管 —— 團隊成員能看懂，就是一份優異的交互文檔。多在繪制進程中和同事溝通，優化展現的做法，可以免良多會呈現的問題，進一步加快我們的建造效力。

3. 文檔的團隊協作利用

將文檔全數做完今后，終究就是關于交付和協作的問題了。

既然我們利用線上的 UI 軟件來完成交互文檔的建造，那末文件設置公然拜候權限，再分享鏈接天然是最簡單的法子。

但每次項目分享個網頁鏈接，或并行有好幾個項目，需要其它成員本身去保藏網址，也是挺麻煩的。所以盡可能充實利用軟件中的團隊協作功能，經由過程建立一個團隊，添加成員，讓他們自行查看當前文件目次中的交互文檔。

查看進程中，團隊其它成員可以經由過程評論的功能對交互內容進行糾錯、發問、建議，便利我們進行優化改良。

經由過程這類簡單高效的文檔協作模式，我們可以很是快得完成整體交互內容的定稿，并最先后續的工作。

再回到前面的話題，我們是 UI 設計師，不是全職交互設計。原型文檔輸出完了，下一步可是要做視覺界面的，所以交互文檔便可以不消管了嘛？

交互文檔的最好狀況是 —— 利用終究界面圖例注釋交互內容。

也就是當我們把所有頁面內容設計完成后，強烈建議將界面的展現和交互文檔進行整合。除前端和產物可以看到終究的交互落地結果外（有時辰終究設計和前面的交互紛歧致），還可以直接經由過程這個文檔查看界面數值標注，而不消來回于交互和設計文檔往返切換，這才能讓文檔感化最年夜化。

4、結尾

以上就是關于交互文檔的相干注釋，下一篇，我們集聚焦在和表單有關的交互干貨分享。

我們下篇再會。