起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識編寫一份友好的交互說明文檔要注意哪些
編輯導語：交互說明文檔是提交給需求評審會成員審核時需要用到的，而交互說明文檔又需要具體問題具體分析，那么我們該如何編寫一份友好的交互說明文檔呢？我們一起來看看吧。
最近有設計小伙伴咨詢，怎么樣的交互說明才是最好的，是大家都喜歡的。最近他寫的交互說明文檔提交給需求評審會的成員審核時，大家都建議他再寫的合理些，這讓他傷透了腦筋。
我告訴他：
第一，崗位對象不同：沒有一份十全十美的交互說明可以打動所有人，讓所有人為之驚嘆。
畢竟，由于閱讀交互說明文檔的對象不同，他們會對交互說明文檔有不同的要求，這是崗位屬性導致的結果。例如前端開發希望詳細到字段、初始默認值、數據調取接口等，而領導只要看保證業務方向沒有錯誤的大交互鏈路。
第二，同崗位不同認知：同一崗位不同成員的認知、從業經歷、個人喜好、性格脾性等也會導致不可能有完美適配所有人的交互說明文檔。
例如在一個行業已經深耕多年的前端工程師，即使你的交互說明文檔寫的沒有那么詳細，他也可以從你現有的文字中推敲出其他方面，同時還能幫你補充完善。
而針對剛入行的前端工程師，你要是寫的不詳細，他就會抓狂，項目時間緊急的時候還會自己腦補交互細節。之后你走查時候也會抓狂，但是沒用呀，誰讓自己沒有寫明白交互細節，遺漏了呢。
第三，使用場合不同：不同場合需要的交互說明文檔也不同。
例如與對方面對面溝通，交互說明文檔可以少寫點；但是通過線上工具與對方溝通，就需要寫的盡可能詳細；如果是會議型的評審，那就要方方面面都做足功課了。
簡單來說就像準備一份ppt：針對同一個主題的ppt，在外部演講和在公司內部演講，同一份ppt會需要設計兩個版本，一個是內部版，一個是外部版，原因在于使用場合不同。
第四，產品階段不同：交互說明文檔闡述的是一個產品的交互，而不是闡述其他的。
如果產品所處階段為成熟期，那往往產品的交互文檔已經沉淀了很多通用法則，可以被復用，那么現在的交互說明文檔少寫點，問題也不大；但產品處于探索期或成長期，通常來說可復用性的交互資產是不存在的，那交互說明文檔就需要準備的相對完善。
有些設計小伙伴就說了，既然不可能滿足所有人，那我就按照自己的想法隨意寫好了。這可不行哦，畢竟我們的主要工作有一部分是撰寫交互說明文檔，這就必須要有認真、嚴謹、專業的工作態度，把這部分工作做好。那我們來看看。
一、什么是交互說明文檔？
交互說明文檔是用來告訴參與產品研發的團隊成員頁面交互相關細節的一個說明文檔，包括頁面間的邏輯跳轉、頁面內模塊的交互、頁面功能的狀態等。交互說明文檔寫的越詳細越有利于參與產品研發各方的正確執行。
二、有待改進的交互說明文檔
我匯總了一些日常工作中有待改進的交互說明文檔形式，看看都存在哪些問題。
1. 文字密密麻麻，無結構
幾乎所有剛初入職場的設計師，在編寫交互文檔時，會怕自己寫少了別人覺得自己不專業，怕寫的不全沒辦法表達頁面細節，導致交互文檔密密麻麻都是文字，這讓閱讀者幾乎無法閱讀，找不到視覺落腳點。
2. 描述簡單，不完整
有幾年工作經驗的設計師，由于很多通用交互法則已了然于心，他們在編寫交互說明文檔時就比較簡單，一些交互就沒有寫在文檔上，這導致開發在開發時，忽略了某些交互。
3. 數據太假，沒有邏輯
交互稿數據沒有邏輯，是很多設計師經常會出現的問題，一部分原因可能在于產品經理沒有理順產品邏輯和細節就提交設計師畫圖了，另一部分原因可能在于設計時間緊張，來不及對交互稿中所有的數據都做到邏輯合理。
曾經遇到過的情況有，關聯數值關聯不上，表格中字段對應的值對不上，表單填寫的數據和實際情況不符。
建議大家在時間允許或有條件反推產品經理協助完善數據的情況下，盡量數據展現的真實與符合邏輯，如此有助于開發及相關閱讀者高效理解。
4. 圖文太遠，找不到
有幾次我注意到設計師提交上來的交互說明會標注“見圖X”這樣的文字。也就是一段說明讀完了，還得去頁面的某個角落尋找對應的圖，這種體驗非常不好。
在交互設計原則中有一項為“足不出戶”?！白悴怀鰬簟钡囊馑际侵改茉诋斍绊撁娼鉀Q的事情，不要去其他頁面；能在就近完成的事情，不要距離過遠。頻繁的切換和跳轉會導致用戶心流被打斷，容易引起用戶思緒中斷、思考不劉暢，甚至可能對產品產生反感。
同理，我們交互說明文檔中的圖文也應盡量相鄰，通過一眼文字一眼圖，讓用戶看的順暢、舒適，理解的快速。
5. 零散，東一句西一句
東一句西一句是指交互說明文檔中本該成為一體去描述的文字，被分成了好幾個部分去闡述，這對看文檔的人來說簡直是災難，他需要自己重新梳理交互思路，將交互規則串聯起來。
我們自己在編寫交互說明文檔時，盡量規避上述常見的問題。
三、什么是好的交互說明文檔
對于什么是好的交互說明文檔，網上一搜一大把，這里我根據自己的經驗，和大家分享下什么是好的交互說明文檔。
首先我們來明確下，什么是好，有了好的標準以后，再來談談如何做到好。
1. 什么是好
- 通常情況下，交互文檔會給產品經理看，用來評審設計方案是否滿足需求；
- 給視覺設計師看，用來指導視覺方案的呈現；
- 給前后端開發人員看，用來指導開發邏輯；
- 給測試工程師看，用來協助測試編寫測試用例。
基于此，好的交互說明文檔關系著設計方案是否可被最大程度的實現。并且如果交互文檔文字冗長、邏輯不清晰，不僅看的人吃力，還會需要增加額外的時間來和開發工程師溝通。好的交互文檔，我認為至少需要具備以下7點：
- 明確價值
- 考慮全面
- 通俗易懂
- 結構清晰
- 圖文并茂
- 僅此一份
- 修訂記錄
2. 如何做到好
為了讓大家一邊學習一遍實踐，我使用“表單校驗”的交互案例給大家進行講解。
（1）明確價值
能協助項目成員通過文檔更順利地完成工作任務，能幫助用戶解決問題，能達成產品目標，則是好的交互說明文檔。文檔對各方有價值，是一份好的交互說明文檔的起點。那么，如何編寫才能達到上述結果呢？
一方面是將此次文檔的價值寫清楚，包括寫明此次交互設計的背景與需求來源、需求清單，標明交互設計的理論依據，可以給用戶帶來的價值等。另一方面要和成員宣導這些內容，讓成員感受自己要做的工作是有價值的。
“表單校驗”上場：
（2）考慮全面
拋開文檔閱讀對象等相關影響因素，通常來說交互需要考慮到以下幾方面：
a. 整體交互流程
整體交互流程是指產品頁面與頁面之間的交互邏輯。
b. 頁面模塊交互說明
頁面模塊交互說明是指模塊自身的交互說明，或同頁面內獨立模塊之間的交互邏輯，或不同頁面模塊之間的交互邏輯。例如點擊導航樹節點會聯動右側表格內容刷新；點擊banner跳轉到對應的商品詳情頁，且定位到頁面1/2位置。
c. 頁面功能交互說明
頁面功能交互說明是指單個功能的各種情況闡述。例如搜索框內輸入文字，通過enter觸發對應頁面跳轉。
d. 盡量真實的數據展示
雖然是交互說明，我們也盡量做到模擬真實數據，否則很容易讓閱讀者產生錯誤判斷。并不是所有人都會一字一句的去閱讀文檔，因此，盡量真實的數據，有利于閱讀者更有效的了解。
e. 特殊情況額外補充說明
很多情況下，會因為某些原因出現極端交互情況，此時也需要補充完整。
f. 通用交互一處即可
建議交互團隊為產品建立通用型交互說明庫，遇到類似的情況，直接調取即可。
實際上我們在編寫交互說明的時候，不太會分得那么細，很多說明是混合在一起表達的。
“表單校驗”上場：
（3）通俗易懂
通俗易懂是指要讓文字、語言、圖片等做到讓受眾易于理解和感知，從而在信息傳遞過程中盡量少的出現損耗，這一點同時也與人類的理解能力有關。
百度百科是這么解釋理解能力的：
“理解能力是指一個人對事物乃至對知識的理解的一種記憶能力。
理解，有三級水平：
- 低級水平的理解是指：知覺水平的理解，就是能辨認和識別對象，并且能對對象命名，知道它“是什么”；
- 中級水平的理解是：在知覺水平理解的基礎上，對事物的本質與內在聯系的揭露，主要表現為能夠理解概念、原理和法則的內涵，知道它是“怎么樣”；
- 高級水平的理解屬于間接理解，是指：在概念理解的基礎上，進一步達到系統化和具體化，重新建立或者調整認知結構，達到知識的融會貫通，并使知識得到廣泛的遷移，知道它是“為什么”。
當我們了解了人類的理解能力水平是參差不齊后，我們就要盡量在工作中將專業知識化繁為簡（也可以針對人群化繁為簡），增強溝通效果，最終達到完成團隊目標的結果。
交互文檔盡量做到講人話，不要講一堆專業術語。記得之前有個交互設計師在會議上闡述自己的交互方案時，提到用了“提供邀請”原則。由于與會成員是開發工程師和產品經理，他們問到什么是“提供邀請”原則，并且在這個問題上大家討論了很久。
由此可見，表達通俗易懂，是很必要的。
（4）結構清晰
交互說明文檔除了要表達通俗易懂外，還需要結構清晰。
結構清晰的內容不僅使閱讀者一目了然、理解成本低，還可以讓閱讀者了解撰寫者的意圖。要做到文檔結構清晰，除了需要遵守一些規則外，也不能脫離當前文檔的實際情況。
“表單校驗”上場（把文字進行分段處理，并取出關鍵詞）：
（5）圖文并茂
圖片和文字相得益彰可以加深閱讀者對文字的理解，同時避免閱讀者去想象文字對應的結果。由于人們對同一段文字的理解不完全相同，因此建議設計師盡量安排交互說明對應圖解。
“表單校驗”上場（左圖右文）：
（6）僅此一份
僅此一份是說交付給團隊交互說明文檔的時候不要多份。之前我們的前端小伙伴拿到了兩份交互文檔，一份是純原型交互文檔，一份是視覺稿交互文檔，兩者描述的信息大同小異。
此時，建議交互文檔的信息做合并，只提交一份完整的給前端小伙伴，讓前端小伙伴能專心致志理解一份。
（7）修訂記錄
建議交互說明文檔留存修訂記錄，一方面可以了解交互文檔的變更歷史，另一方面有利于回溯和查找信息。修訂記錄一般包括修訂人、修訂時間和修訂內容。
四、總結
由于項目進度、業務復雜程度等不同，我們不可能每次都能寫出一份最好的交互說明文檔，但我們可以想辦法寫出一份相對可讀性高、可理解性高的友好的交互說明文檔。我們常說自己是做用戶體驗的，那交互說明文檔就是體現我們交互能力一個方面。
除了完成交互說明文檔，想要讓開發小伙伴真正理解交互說明，還需親自和開發溝通，千萬不要認為我寫的很詳細了，他怎么還是實現的有偏差。
事實上，就如開篇所說：同一崗位不同人的認知理解、從業經歷、個人喜好、性格脾性等也會導致理解不同。特別是對于一些我們非常創新的、特殊的交互點，需要重點和開發說明。
并且，交互說明文檔基于業務的發展，也會不斷的迭代，我們要抱著多聽、多想、多思考、多接受的態度去不斷優化我們的文檔，盡力寫出一份友好的交互說明文檔。
#專欄作家#
知果，公眾號：知果日記，人人都是產品經理專欄作家。浙江工商大學品牌設計專業碩士，《B端思維-產品經理的自我修煉》作者。在產品設計流程、產品設計原則、產品設計方法、產品設計規范方面均有豐富經驗。
本文原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
贊
就是要寫的細致全面一點，寫的很不錯，贊????
嗯嗯，精益求精