編輯導語：交互說明文檔是提交給需求評審會成員審核時需要用到的，而交互說明文檔又需要具體問題具體分析，那麼我們該如何編寫一份友好的交互說明文檔呢？我們一起來看看吧。

最近有設計小夥伴咨詢，怎麼樣的交互說明才是最好的，是大家都喜歡的。最近他寫的交互說明文檔提交給需求評審會的成員審核時，大家都建議他再寫的合理些，這讓他傷透了腦筋。

我告訴他：

第一，崗位對象不同：沒有一份十全十美的交互說明可以打動所有人，讓所有人為之驚歎。

畢竟，由于閱讀交互說明文檔的對象不同，他們會對交互說明文檔有不同的要求，這是崗位屬性導緻的結果。例如前端開發希望詳細到字段、初始默認值、數據調取接口等，而領導隻要看保證業務方向沒有錯誤的大交互鍊路。

第二，同崗位不同認知：同一崗位不同成員的認知、從業經曆、個人喜好、性格脾性等也會導緻不可能有完美适配所有人的交互說明文檔。

例如在一個行業已經深耕多年的前端工程師，即使你的交互說明文檔寫的沒有那麼詳細，他也可以從你現有的文字中推敲出其他方面，同時還能幫你補充完善。

而針對剛入行的前端工程師，你要是寫的不詳細，他就會抓狂，項目時間緊急的時候還會自己腦補交互細節。之後你走查時候也會抓狂，但是沒用呀，誰讓自己沒有寫明白交互細節，遺漏了呢。

第三，使用場合不同：不同場合需要的交互說明文檔也不同。

例如與對方面對面溝通，交互說明文檔可以少寫點；但是通過線上工具與對方溝通，就需要寫的盡可能詳細；如果是會議型的評審，那就要方方面面都做足功課了。

簡單來說就像準備一份ppt：針對同一個主題的ppt，在外部演講和在公司内部演講，同一份ppt會需要設計兩個版本，一個是内部版，一個是外部版，原因在于使用場合不同。

第四，産品階段不同：交互說明文檔闡述的是一個産品的交互，而不是闡述其他的。

如果産品所處階段為成熟期，那往往産品的交互文檔已經沉澱了很多通用法則，可以被複用，那麼現在的交互說明文檔少寫點，問題也不大；但産品處于探索期或成長期，通常來說可複用性的交互資産是不存在的，那交互說明文檔就需要準備的相對完善。

有些設計小夥伴就說了，既然不可能滿足所有人，那我就按照自己的想法随意寫好了。這可不行哦，畢竟我們的主要工作有一部分是撰寫交互說明文檔，這就必須要有認真、嚴謹、專業的工作态度，把這部分工作做好。那我們來看看。

一、什麼是交互說明文檔？

交互說明文檔是用來告訴參與産品研發的團隊成員頁面交互相關細節的一個說明文檔，包括頁面間的邏輯跳轉、頁面内模塊的交互、頁面功能的狀态等。交互說明文檔寫的越詳細越有利于參與産品研發各方的正确執行。

二、有待改進的交互說明文檔

我彙總了一些日常工作中有待改進的交互說明文檔形式，看看都存在哪些問題。

1. 文字密密麻麻，無結構

幾乎所有剛初入職場的設計師，在編寫交互文檔時，會怕自己寫少了别人覺得自己不專業，怕寫的不全沒辦法表達頁面細節，導緻交互文檔密密麻麻都是文字，這讓閱讀者幾乎無法閱讀，找不到視覺落腳點。

2. 描述簡單，不完整

有幾年工作經驗的設計師，由于很多通用交互法則已了然于心，他們在編寫交互說明文檔時就比較簡單，一些交互就沒有寫在文檔上，這導緻開發在開發時，忽略了某些交互。

3. 數據太假，沒有邏輯

交互稿數據沒有邏輯，是很多設計師經常會出現的問題，一部分原因可能在于産品經理沒有理順産品邏輯和細節就提交設計師畫圖了，另一部分原因可能在于設計時間緊張，來不及對交互稿中所有的數據都做到邏輯合理。

曾經遇到過的情況有，關聯數值關聯不上，表格中字段對應的值對不上，表單填寫的數據和實際情況不符。

建議大家在時間允許或有條件反推産品經理協助完善數據的情況下，盡量數據展現的真實與符合邏輯，如此有助于開發及相關閱讀者高效理解。

4. 圖文太遠，找不到

有幾次我注意到設計師提交上來的交互說明會标注“見圖X”這樣的文字。也就是一段說明讀完了，還得去頁面的某個角落尋找對應的圖，這種體驗非常不好。

在交互設計原則中有一項為“足不出戶”。“足不出戶”的意思是指能在當前頁面解決的事情，不要去其他頁面；能在就近完成的事情，不要距離過遠。頻繁的切換和跳轉會導緻用戶心流被打斷，容易引起用戶思緒中斷、思考不劉暢，甚至可能對産品産生反感。

同理，我們交互說明文檔中的圖文也應盡量相鄰，通過一眼文字一眼圖，讓用戶看的順暢、舒适，理解的快速。

5. 零散，東一句西一句

東一句西一句是指交互說明文檔中本該成為一體去描述的文字，被分成了好幾個部分去闡述，這對看文檔的人來說簡直是災難，他需要自己重新梳理交互思路，将交互規則串聯起來。

我們自己在編寫交互說明文檔時，盡量規避上述常見的問題。

三、什麼是好的交互說明文檔

對于什麼是好的交互說明文檔，網上一搜一大把，這裡我根據自己的經驗，和大家分享下什麼是好的交互說明文檔。

首先我們來明确下，什麼是好，有了好的标準以後，再來談談如何做到好。

1. 什麼是好

• 通常情況下，交互文檔會給産品經理看，用來評審設計方案是否滿足需求；
• 給視覺設計師看，用來指導視覺方案的呈現；
• 給前後端開發人員看，用來指導開發邏輯；
• 給測試工程師看，用來協助測試編寫測試用例。

基于此，好的交互說明文檔關系着設計方案是否可被最大程度的實現。并且如果交互文檔文字冗長、邏輯不清晰，不僅看的人吃力，還會需要增加額外的時間來和開發工程師溝通。好的交互文檔，我認為至少需要具備以下7點：

1. 明确價值
2. 考慮全面
3. 通俗易懂
4. 結構清晰
5. 圖文并茂
6. 僅此一份
7. 修訂記錄

2. 如何做到好

為了讓大家一邊學習一遍實踐，我使用“表單校驗”的交互案例給大家進行講解。

（1）明确價值

能協助項目成員通過文檔更順利地完成工作任務，能幫助用戶解決問題，能達成産品目标，則是好的交互說明文檔。文檔對各方有價值，是一份好的交互說明文檔的起點。那麼，如何編寫才能達到上述結果呢？

一方面是将此次文檔的價值寫清楚，包括寫明此次交互設計的背景與需求來源、需求清單，标明交互設計的理論依據，可以給用戶帶來的價值等。另一方面要和成員宣導這些内容，讓成員感受自己要做的工作是有價值的。

“表單校驗”上場：

（2）考慮全面

抛開文檔閱讀對象等相關影響因素，通常來說交互需要考慮到以下幾方面：

a. 整體交互流程

整體交互流程是指産品頁面與頁面之間的交互邏輯。

b. 頁面模塊交互說明

頁面模塊交互說明是指模塊自身的交互說明，或同頁面内獨立模塊之間的交互邏輯，或不同頁面模塊之間的交互邏輯。例如點擊導航樹節點會聯動右側表格内容刷新；點擊banner跳轉到對應的商品詳情頁，且定位到頁面1/2位置。

c. 頁面功能交互說明

頁面功能交互說明是指單個功能的各種情況闡述。例如搜索框内輸入文字，通過enter觸發對應頁面跳轉。

d. 盡量真實的數據展示

雖然是交互說明，我們也盡量做到模拟真實數據，否則很容易讓閱讀者産生錯誤判斷。并不是所有人都會一字一句的去閱讀文檔，因此，盡量真實的數據，有利于閱讀者更有效的了解。

e. 特殊情況額外補充說明

很多情況下，會因為某些原因出現極端交互情況，此時也需要補充完整。

f. 通用交互一處即可

建議交互團隊為産品建立通用型交互說明庫，遇到類似的情況，直接調取即可。

實際上我們在編寫交互說明的時候，不太會分得那麼細，很多說明是混合在一起表達的。

“表單校驗”上場：

（3）通俗易懂

通俗易懂是指要讓文字、語言、圖片等做到讓受衆易于理解和感知，從而在信息傳遞過程中盡量少的出現損耗，這一點同時也與人類的理解能力有關。

百度百科是這麼解釋理解能力的：

“理解能力是指一個人對事物乃至對知識的理解的一種記憶能力。

理解，有三級水平：

• 低級水平的理解是指：知覺水平的理解，就是能辨認和識别對象，并且能對對象命名，知道它“是什麼”；
• 中級水平的理解是：在知覺水平理解的基礎上，對事物的本質與内在聯系的揭露，主要表現為能夠理解概念、原理和法則的内涵，知道它是“怎麼樣”；
• 高級水平的理解屬于間接理解，是指：在概念理解的基礎上，進一步達到系統化和具體化，重新建立或者調整認知結構，達到知識的融會貫通，并使知識得到廣泛的遷移，知道它是“為什麼”。

當我們了解了人類的理解能力水平是參差不齊後，我們就要盡量在工作中将專業知識化繁為簡（也可以針對人群化繁為簡），增強溝通效果，最終達到完成團隊目标的結果。

交互文檔盡量做到講人話，不要講一堆專業術語。記得之前有個交互設計師在會議上闡述自己的交互方案時，提到用了“提供邀請”原則。由于與會成員是開發工程師和産品經理，他們問到什麼是“提供邀請”原則，并且在這個問題上大家讨論了很久。

由此可見，表達通俗易懂，是很必要的。

（4）結構清晰

交互說明文檔除了要表達通俗易懂外，還需要結構清晰。

結構清晰的内容不僅使閱讀者一目了然、理解成本低，還可以讓閱讀者了解撰寫者的意圖。要做到文檔結構清晰，除了需要遵守一些規則外，也不能脫離當前文檔的實際情況。

“表單校驗”上場（把文字進行分段處理，并取出關鍵詞）：

（5）圖文并茂

圖片和文字相得益彰可以加深閱讀者對文字的理解，同時避免閱讀者去想象文字對應的結果。由于人們對同一段文字的理解不完全相同，因此建議設計師盡量安排交互說明對應圖解。

“表單校驗”上場（左圖右文）：

（6）僅此一份

僅此一份是說交付給團隊交互說明文檔的時候不要多份。之前我們的前端小夥伴拿到了兩份交互文檔，一份是純原型交互文檔，一份是視覺稿交互文檔，兩者描述的信息大同小異。

此時，建議交互文檔的信息做合并，隻提交一份完整的給前端小夥伴，讓前端小夥伴能專心緻志理解一份。

（7）修訂記錄

建議交互說明文檔留存修訂記錄，一方面可以了解交互文檔的變更曆史，另一方面有利于回溯和查找信息。修訂記錄一般包括修訂人、修訂時間和修訂内容。

四、總結

由于項目進度、業務複雜程度等不同，我們不可能每次都能寫出一份最好的交互說明文檔，但我們可以想辦法寫出一份相對可讀性高、可理解性高的友好的交互說明文檔。我們常說自己是做用戶體驗的，那交互說明文檔就是體現我們交互能力一個方面。

除了完成交互說明文檔，想要讓開發小夥伴真正理解交互說明，還需親自和開發溝通，千萬不要認為我寫的很詳細了，他怎麼還是實現的有偏差。

事實上，就如開篇所說：同一崗位不同人的認知理解、從業經曆、個人喜好、性格脾性等也會導緻理解不同。特别是對于一些我們非常創新的、特殊的交互點，需要重點和開發說明。

并且，交互說明文檔基于業務的發展，也會不斷的叠代，我們要抱着多聽、多想、多思考、多接受的态度去不斷優化我們的文檔，盡力寫出一份友好的交互說明文檔。

#專欄作家#

知果，公衆号：知果日記，人人都是産品經理專欄作家。浙江工商大學品牌設計專業碩士，《B端思維-産品經理的自我修煉》作者。在産品設計流程、産品設計原則、産品設計方法、産品設計規範方面均有豐富經驗。

本文原創發布于人人都是産品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部