編輯導讀：交互説明文檔，是交互設計師的輸出物中必不可少的一項，它關係着設計方案能否最大程度的被實現。本文作者依據工作中項目實踐的所思所想，並結合案例等分享了寫交互説明時需要注意的一些問題，希望對你有用。
交互説明，是交互設計師必不可少的‘寫作能力’，它能讓研發同事更加了解你的方案説明、交互想法。
但寫得不好，容易出現流水賬式、邏輯不清楚、文案臃腫等情況，給自己帶來額外的工作量，還影響着與研發同事的對接效率。
所以今天想總結個人對‘交互説明’這塊的知識，讓你和研發同事更加愉快地玩耍~
目錄：
- 技術型交互説明
- 只寫最重要的
- 它只是個‘黑板報’
- 按模塊來展示説明
- 建立交互説明庫
- 真實的數據展示
- 複雜説明另外展示
- 有更改時及時告知
- 好的心態
傳統的交互説明，是根據自己的意識、主觀想法進行描述，但由於每個人的文筆不同、思維方式不一樣，容易出現特別雜亂的説明，相關同事看了表示壓力山大想拔刀…
其實我們可以利用開發熟悉的技術術語、代碼邏輯來闡述交互説明，使開發對交互説明有更加直觀的理解，比如if else邏輯、switch case邏輯、數據庫標識字段。
1. if else一種判斷邏輯，根據判斷條件正確與錯誤來執行對應的操作。它可以更直觀地表達邏輯關係，更利於開發同事的理解。
比如用户登錄的多邏輯説明，可以這麼寫：
一種選擇邏輯，根據選擇項執行對應的操作。比如根據用户投入鈔票的面值，決定可選擇的商品類型。
‘default’是容易疏忽的選項：匹配不存在時做的事情。
比如上面的例子，若是用户投了1元，或者投了一張紙怎麼辦？
這是就需要‘default’的處理了。
3. 用數據庫標識字段另外，一些‘動態參數’用數據庫裏的字段名稱來標記也是一個不錯的選擇。
比如：‘用户’，在數據庫裏的儲存字段是 #UserName#，用它來代替交互説明裏的動態參數，可以提升開發的理解效率。
怎麼知道每個字段對應數據庫的表達?
接口文檔：前端和後台之間用來傳輸信息的文檔，那裏既有數據庫的表達，也有對應的中文描述。
注：以上例子來自-唐韌《產品經理必懂的技術那點事兒》
密密麻麻的文字説明，是早期交互設計師比較常見的‘毛病’。
一是列全所有説明，可以減少被diss‘考慮不周到’的可能；二是間接證明自己的專業能力。
但是！交互説明畢竟是要給人看的，堆積的文字誰看得下去？？
只會帶來額外的閲讀壓力和極高的理解成本，交互設計師修改起來也麻煩。
一倆個頁面還好，多個頁面都是這樣的説明，開發沒約你‘一起去爬山’就不錯了。
所以個人建議，只針對有異常狀態、特殊交互、分支流程、關鍵節點等特殊地方進行説明即可。
對於一些常識性、無異常點的地方就不用寫了。
無特別需交代的地方，寫了只會讓開發產生懷疑：這個地方是不是在特殊交互？
03 它只是個‘黑板報’不要幻想單憑一份交互説明，就能讓開發完全、正確明白你的想法，那幾乎是不可能的事。
在我看來，交互説明只是個和開發傳達內容的黑板報，一個溝通工具。
想讓開發真正理解你的交互説明、方案邏輯等，還是得基於黑板報上的內容，親自與開發溝通對齊。這樣才能確定方案的有效性、實現難度、是否有需要調整的內容等，讓雙方的想法保持對齊。
前期與開發溝通清楚了，後面交互説明可以起到一個‘回顧、確定’的作用。
而對齊的方式可以是交互評審會、工位口述、電話溝通等。只要目的能讓開發理解你的交互稿，對齊形式可自主調整。
04 按模塊來展示説明這個‘模塊’有2層意思：
一是類似於‘內容組件’：對於重複性強、出現頻率高的內容，設置一個模板內容及説明即可。
對於重複出現的地方，直接代替過去就行，能夠大幅度減少交互設計師的工作量，開發也方便理解。
二是分頁面/位置來展示：當整體交互原型較多時，沒必要全都鋪在同一個頁面進行展示説明，會顯得整體頁面很臃腫、瀏覽起來比較費力（尤其是文件很大時）。
可以嘗試：單獨展示某個模塊、分支流程、場景等下的交互稿。小而聚集，內容更精簡、理解更方便。
若各模塊/分支流程/場景中的交互稿存在一定的關聯性，可以先弄成一張總體性的‘概覽圖’，再去單獨展示。
讓開發知道整體方案之間的關係、又能瞭解各個細分方案裏的交互説明。
05 建立交互説明庫像一些常見、使用頻率較高的説明，完全可以建立起一個‘交互説明庫’。
一是方便自己及時調取，節省時間與精力。
二能統一你的交互説明風格，減少開發的理解成本，也能提現出你的專業素養。
想必這個大家都知道，隨便性地舉例、描述數據，會讓開發對內容的真實性、有效性、邏輯關係等產生懷疑。
比如以下哪個‘發文數’，更容易讓人理解與‘啓用數、啓用率’之間的邏輯關係？
為了減少這種誤解，還是用最新、真實合理、上線數據等進行描述。
如果在會議上讓leader、boss對這些數據/內容提出了疑問，就丟大發了，也會讓同事質疑你的基礎能力、責任心。
07 複雜説明另外展示交互稿裏總有一些比較複雜、難以文字來説明的想法，像是一些動效、狀態、流程演示等。
對於這一些比較複雜的説明，完全可以用demo演示、視頻、gif圖等形式來演示你的想法，讓你的説明更加可觀性。
像一些按鈕或功能存在多種狀態時，也可以‘表格/列表’的方式進行展示。
除了以上情況外，若交互原型有了調整（包括交互説明），一定要與團隊成員告知！！並提示修改位置（在哪個頁面）。
否則產品、前端、後台、測試等同事的相關想法、工作會停留在上個交互稿裏。
別因為信息沒對齊而造成了不良影響。就算改了一處小東西，也儘量和同步一下。
09 好的心態最後想説一句，沒有人百分百、完完全全顧慮到所有細節和場景，即使你完全地走查了一遍甚至好幾遍…
但由於不同角色的職業視角、預覽目的、經驗想法等都會提出新的疑問、挑戰你的方案説明。
這是很正常的事~
更何況，在方案沒對齊前，交互稿（包括交互説明）上都存在太多的未知性、待優化點。
即使當前階段確定了所有的細節與場景，隨着方案時間的推進，後續總有新的想法、遺漏點、優化點湧現出來，那些我們覺得的‘完全OK的方案説明’，也都變成了‘過去式’……
我們要做的，必須是多聽聽多方視角的聲音，並尊重、虛心接受他人的意見，而不是抱怨自己為啥考慮不周全、停留在原地鑽牛角尖。
結語好了，以上就是個人平時寫交互説明的一些感悟，完全是處於個人習慣和主觀經驗得來的，可能不太對，請多指教~
#專欄作家#和出此嚴，微信公眾號：和出此嚴，人人都是產品經理專欄作家。一枚在鵝廠成長中的‘90後老幹部’，主產各種接地氣的交互/產品乾貨。以做產品的方式，寫好每一篇文章。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議。