起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識交互文檔怎么寫，才比較科學易讀？
本文將著重介紹交互設計師的輸出物–交互文檔的相關細節，enjoy~
在經歷了互聯網行業飛速發展的今天，行業步伐逐步減慢，互聯網公司的架構和開發流程也隨之日益完善，產品開發工作也變得具有了中國IT行業的獨有特色和特有流程。
從以前只有Leader+UI設計師+開發人員的扁平式開發流程，到現在的需求方+產品方+交互設計師（以下簡稱UX設計師）+UI設計師+運營/市場對接+開發人員的完整開發流程，這意味著一款產品的開發變得更加細膩，更加具體，也更加民主。
本文將著重介紹交互設計師的輸出物–交互文檔的相關細節，同時礙于UX設計師在今天看來，仍然算是一個新興職位，所以將額外講解UX設計師的職位背景和相關工作內容，作為本篇文章的背景。
一、交互設計師的工作內容
UX設計師的存在，使原本產品經理工作中的原型制作工作逐步轉讓給UX設計師，使產品經理更關注需求的戰略層面，更能進行戰略層面的設計。同時，UX設計師也分擔了UI設計師的布局設計、跳轉設計等非本職工作，使開發流程中的角色更加專注自己的工作。
交互設計師，UX設計師，有的公司也稱之為UE設計師。具體的工作內容可以認為有：
- 需求消化，使其可實現化，并制作對應的交互原型；
- 規定數據格式、樣式，規定數據的展示方式、字段限制；
- 規定控件的使用規范；
- 從功能流程的高度，梳理功能的頁面層級；
- 規定數據的前后臺交互；
- 規定臨界狀態；
- 頁面切換動效的規定和模擬等等。
不同的公司對交互設計師的工作內容可能有不同的界定，但是一般情況下，上述是大部分交互設計師的主要工作內容。在這樣一份工作中，交互設計師基本上是填補了從產品經理到UI設計師之間的空白，從開發角度和設計角度對一款產品的細節進行補完。
二、 交互設計師的輸出物
作為交互設計師的輸出物，交互文檔是聯系開發流程上下游的重要文件，它需要具備良好的可讀性、唯一性和時效性。
- 可讀性指的是不論產品經理、設計師還是開發人員，都需要讀得懂；
- 唯一性指的是，針對某個開發需求，必須有且只有一個交互文檔。針對某個項目，其對應的交互文檔也必須是獨一份（可以是一個交互文檔的集合）。即使存在多個版本，舊的版本必須標注為“歸檔備查”，并且明確備注過時時間；
- 時效性指的是，某個需求或者某個項目，尚在使用中的交互文檔，必須是最新的，符合當前需求要求和產品輸出的。
本文著重介紹的即是交互文檔的構成和它的寫法（基于中國移動交互文檔規范）。
三、交互文檔的構成
綜合國內IT行業的從業環境，基于Axure的原型制作可能更便于打通開發上下游。
大概礙于Axure做出來的原型不是那么美觀和便捷，部分產品經理和UX設計師可能已經轉戰Sketch等交互設計軟件，或者使用Flinto來模擬交互動效。但因為這些軟件大多無法跨平臺，考慮到很多公司并沒有能力全面采用MAC辦公，所以這里推薦使用Axure進行原型制作。
交互文檔一般由以下部分構成：
1. 交互文檔說明及日志
- 說明交互文檔所針對項目或者功能；
- 日志記錄它的創建時間、修改時間及修改原因和內容；
- 記錄文檔的編寫人和最新的更新時間。
交互文檔說明示例
交互文檔更新記錄/日志示例
- 交互文檔的Title有效地保證了交互文檔的唯一性，即該文檔對應的是XX項目或XX項目的XX功能；
- 通過編寫人、版本號、創建時間和更新時間，方便在文檔內容存疑時，找到對應的時間節點和該文檔的負責人，便于對接和修正；
- 在更新記錄中，需要有效地標明版本號、更新時間、更新內容和修改人，便于文檔內容出現存疑時，定位到是哪一部分出現了問題，該部分的對接人是誰，并且明確時間節點，便于版本的追溯和責任的厘清。
2. 文檔內容結構
大致包括模塊名稱、功能流程圖、頁面說明、頁面跳轉關系圖等。
交互文檔構成結構示例
在文檔內容的結構中，必須保證交互文檔的說明和日志是位于頭部，便于隨時查閱；
在正式內容中需要靈活運用Axure中的圖層，如分組和頁面圖標等。一般我們認為將頁面說明和頁面跳轉關系統一歸到一個功能流程或者一個分組下，這樣旣合乎邏輯也可以保證文檔內容的層次感，便于查閱時的定位和展開；
始終堅持“一個頁面只描述一個功能”的原則，這樣可以保證單個文檔頁面中的內容量適當，便于查閱。
頁面說明示例
在確定以上內容后，就可以保證這份交互文檔結構是足夠清晰的，是便于查閱的。接下來，我們將講解交互文檔的正式內容應該如何寫。
四、交互文檔該怎么寫
當交互文檔構成確定后，已經保證了描述對象的模塊劃分是清晰明確的，是不和其他模塊有過多的重合的，是唯一的、最新的、具備開發執行力的。
1. 功能流程圖
功能流程圖用以厘清功能邏輯，對開發人員來說是必需品。功能流程圖的繪制應只針對文檔中某個模塊的功能，而并非針對整個交互文檔描述對象。如果流程圖過大，會直接導致可閱讀性下降。因此，切忌好大喜功，將某個功能描述清楚即即可。
譬如描述一個網站整站的交互文檔中，有多個功能模塊需要描述，如登錄/注冊、用戶手機號綁定、下單/支付等等，我們應該清晰地描述每個功能各自的功能流程，而非將之串聯起來。
這里不再詳細介紹流程圖的畫法，可參考來自白三的《關于流程圖元素定義、結構分類；以及，我有一些技巧告訴你》
流程圖示例
2. 頁面說明圖
頁面說明圖可以詳細說明界面中元素的來源，控件的交互方式，數據的樣式，字段的長度規定，頁面元素的狀態變化等。
該頁面只做參考，實際工作中可不用這么細致
另，我個人其實不建議在交互稿的頁面制作中采用各種Icon，一方面是裝飾過度，另一方面各類Icon風格不一，直接降低了交互稿的美觀度。交互稿件的美觀體現在統一和素凈，重點信息永遠是對功能的描述和對各類情況的規定。
在頁面說明部分中，必須保證一個交互頁面中，針對的只有一個功能。比如注冊登錄，由注冊和登錄構成，頁面說明頁中必須分開，注冊頁面說明圖只羅列注冊功能相關頁面，登錄頁面說明圖只羅列登錄功能相關頁面。
頁面說明頁示例
3. 頁面跳轉關系圖
頁面跳轉關系圖是串連起頁面說明圖的重要核心，說明頁面和頁面之間的跳轉關系。也是功能流程圖的具象表現。這里的規則也和功能流程圖一致，只針對某個模塊，不針對整個交互文檔的描述對象。一方面是防止單頁交互頁面內容過多，不利于觀看，另一方面，如果單頁內容過多，也會導致Axure的運行緩慢。
頁面跳轉關系圖示例
在頁面跳轉關系圖中，必須注明頁面名稱。尤其注意的是頁面連接線不可過多重合，避免造成閱讀的不順暢。
錯誤示例
4. 頁面備注
頁面備注應注明于當頁下方，用紅色字體標注。如頁面內容過多，可考慮單獨開辟一頁進行說明。
五、總結
直到今天為止，仍然有很多人認為交互設計師的工作重點是設計動效或者頁面跳轉效果，其實交互設計師更多的工作內容仍然側重于更加邏輯化的部分，動效、頁面跳轉甚至是頁面元素的變化等設計，只是交互設計師工作中一個極小的部分。
所謂的人機交互，在主觀層面可能只是人為的Input和機器的Output的交互，其實這比較狹義。人機交互的內容其實就是交互設計師的工作內容，這包含的更多的是：信息設計、功能設計、界面布局設計、機器反饋方式的設計和頁面效果的模擬等。
偏重視覺的部分，交互設計師和UI設計師進行配合。偏重功能的部分，交互設計師需要和產品經理進行配合。而偏重實現的部分，交互設計師需要及時和開發進行配合。
回到最開始的那句話，交互設計師是溝通開發流程上下游的重要角色，而非狹義的只盯著動效或者手勢的“UX設計師”。
本文由 @無鹿森 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基于 CC0 協議
求原型稿
內容稍顯清淡……
同感
好文