用我這個互動流程管理工具，讓你的工作變得井然有序！
由於性格和習慣，我在工作中時常處於內斂閉塞的狀態。但作為專職互動設計師，除了完善功能細節和發揮創意外，整合各方資源、監測使用者體驗風險、提升團隊的使用者意識，是同樣重要的工作職責，而這些均需要在專案開發中和其他崗位一起推進。如何克服思維侷限、避免怠惰心理、充分調動內部資源，做到專案結束不留遺憾，一直是困擾我的問題。也一直在思考一種簡單易行的方法論，能通過外在規範來約束和督促自己。於是便有了被我稱為「四三二一」的互動設計流程管理工具。
四、三、二、一分別對應了產品開發流程中的需求、設計、開發、總結四個階段中應該採取的行動步驟，由前期到後期，由策劃到執行，均需要對應崗位的合作。從數字上可以看出，越是早期，應該要求越高、越多，以防止後期的偏差疏漏。下面從「四」開始說起。
「四」是who、why、when、where
「四」分別指who、why、when、where，這是需要和產品經理共同闡明的四個問題。
1. who，功能的使用者群是誰
也許有人會說，產品的使用者群不應在迭代中確認，而是產品最初應該定義好的，比如30～40歲之間的城市白領。這裡要談的其實是更加細分、明確的身份特徵。比如產品經理想要新增一個筆記功能，那麼我們就需要提前想到，什麼人喜歡在聽音訊時記筆記，他有沒有在其他地方記過筆記，喜歡什麼筆記平臺，習慣如何管理筆記等。競品分析和跨界分析，此時就可以介入了。
2. why，為什麼要做這個功能
使用者的需求是多種多樣甚至無窮無盡的，為什麼我們要在當前時間迭代新增這個功能，功能的提出者是誰，驗收標準是什麼，有沒有後續動作。一般情況下，需求提出者是產品經理本人；另一種是運營/內容提給產品經理/設計師的需求，比如要做專題活動或獨立的內容模組。後者尤其需要注意，要直接找需求提出者而非轉述者討論功能細節和實現效果。why 和who 一起，共同確定了功能的「範圍」層面，整體上把控住不要違背公司的「戰略」即可繼續執行。
3. when，功能使用場景有哪些
如果要增加搜人功能，放在搜內容後邊，那可能就存在一些情況，使用者希望首先出來的是人而不是內容。要做下載功能，一種是按照正常的查詢物件、逐個或批量下載、等待下載完畢後收聽；另一種是情況緊急，馬上要出門了，需要地方把我可能想聽的東西一鍵下載，越快越好。還有一些內部場景，如微信繫結，除了常規位置，也可以放在使用者匯入頭像的時候。如暱稱修改，除了常規位置，也可以放在需要臨時隱藏身份的時候（直播間裡）。場景切換可以給互動設計師帶來無限的想象力和可能性，也是創意爆發，達到驚喜效果的一個突破點。
4. where，資訊結構，即功能的位置和聯絡
介面和流程設計是互動設計的基本功，也是我們日常的核心工作。如VIP功能下，到期時間應出現在購買前、購買中、購買後的哪些地方；如工具欄上哪些功能需要放出，哪些需要收起。設計依據一般是功能的重要性、緊急性、使用次數、使用頻率、介面分割槽等。
在和產品經理討論執行的時候，有沒有什麼容易上手的理論工具可以使用呢？順此延展一下，根據功能的工具屬性和內容屬性，我從衡量指標、體驗要求、設計結構三個層面對二者進行了對比劃分：
需要解釋的是，「內容屬性」和「工具屬性」二者看上去處處相對，甚至有種相反的感覺，但其實二者在單個產品內更多是相互配合的關係。這裡做成並列表格是為了方便理解，也是為了能利用二者間的張力為產品或功能快速定性。內容型產品中，工具要為內容服務；工具型產品中，內容要為工具服務。前者如我目前正在做的知識付費，後者如一些日曆和天氣應用。知識付費中關鍵的導購流程、使用流程和拉新流程，都是圍繞內容展開的。能為此三大流程提供更快捷、更個性化、更有獲得感的工具支援，是產品經理和互動設計師可以共同促進的地方。
為什麼有的功能點選量很高卻要收起？如微信朋友圈；為什麼有的功能點選量相對不高卻要露出？如電商的收藏、客服之類。其重要原因是前者裡內容為工具服務；而後者屬於應急工具，需要快捷感和效率性，如果做不到這點，它們本身的存在意義就大打折扣了。
敏感的讀者也許已經發現，where 和when 有重疊的地方，因為使用場景也是資訊結構設計的重要參考因素，甚至是整個策劃和溝通流程的重要節點。它的作用，有些類似「使用者故事」在迭代開發中發揮的作用。以上四點，是需要在迭代初期與產品經理深度溝通同步的地方。
「三」是互動說明、demo、自檢表
「三」分別指互動說明、demo、自檢表。需要的配合資源是互動設計師、（GUI）設計師、測試工程師等。
1. 互動說明
使用 axure 製作的線框圖結合文字說明，包括功能需要的全部介面，方便設計師和測試進行對照設計與規劃測試用例。
與產品經理配合，儘量把產品文件中的規則和規格部分相容進來。
在樣式上與其他互動設計師和GUI設計師確認有沒有違反既定規範的地方，在顏色、透明度、間距、大小、形狀上為設計師提供專業建議。例如在重要的地方使用高亮，使用頻繁的地方放大面積。
以互動設計師制定的文案規範為基礎，與運營、產品經理和設計師商定元資料。注意系統平臺的用語習慣和稽核要求。
2. 演示用的demo
使用axure、keynote或墨刀製作，展示關鍵流程和動畫效果。
與動效設計師明確，如果需要新增動效，預期是什麼，併為其提供對應參考目標。包括為互動增強操作反饋，讓流程更順暢；為資訊傳達增強獲得感或鼓勵感；為功能增強儀式感或趣味性。如彈窗動畫、金幣掉落動畫、開紅包動畫。
與開發工程師協調，流程需要解決什麼問題，即使用者故事。這樣可以激發開發人員自帶的創造性和積極性，靈活積極地應對開發難題，甚至超預期實現目標。例如某個互動動作經過調研難度較大，則可以在明確要求後，允許其根據經驗自由發揮，互動設計師從旁協助。
向測試工程師說明，demo演示的只是關鍵部分，或靜態畫面和語言難以形容確切的部分，「互動說明」內會涉及到其他測試用例。
3. 簡易的互動設計自檢表
在互動設計師單人作戰，獨立決策，快速製圖的日常工作中，怎麼把疑慮、重點、期待、使用者感固定下來，既容易掌握實現，又可以凝結以往的經驗和規範，做一張簡單的自檢表就行了。我認為其中內容不應該拘於互動層面，也應該把產品、開發和測試的突破點寫下來。宜精不宜多，方便貫徹。保證每次迭代均有不同，描述範圍可大可小，且在上述的討論過程中逐步確立。以下僅舉例：
- 點選區有及時反饋，不依賴於網路和身份
- 文字有說服性
- 用圖片增強感染力
- 高頻率功能可以快速到達
- 新功能有邀請
- 無法挽回的操作有強制確認
- 標題顯示完整
- 可以檢視具體釋出時間
- 告知使用者使用規律或意外情況
- 有招牌互動
「二」是開發評審、開發走查
「二」分別指開發評審、開發走查。需要的配合資源是開發工程師。
1. 開發評審
依託以上文件向開發講解功能點，從功能來源開始，第一遍講創意，結合對現有功能的修改點，對其他產品的參考點。第二遍講細節，包括使用者身份、網路狀態、極限情況、跳轉和返回物件等。第三遍討論關鍵節點和設計顧慮、招牌互動、動畫效果等。如果產品經理對相關功能有多次迭代計劃，也要同步給大家。以使用者體驗為理論基點，同時瞭解開發質疑和困難。
2. 開發走查
開發過程中，也會多向開發和測試宣導本次迭代的設計重點和預期效果。根據這兩個崗位的工作節奏，是從基本完整開始測，從整體框架開始搭，而非按照介面順序逐個實現。所以要注意角落處零碎的細節是否慢慢在新增，不能著急，也不要遺漏。如果發現自己設計上有坑，不要遲疑要立即提出來，再和團隊商量是否立即填上，或等下次迭代。立即公開是防止問題在之後被運營、使用者或公司領導偶然發現時，相關人員沒有做好準備，不能快速響應。
「一」是1個教訓
「一」指1個教訓，即自我總結不足。
沒有完美的專案迭代，對互動設計師尤其如此。我經常是迭代剛開始，自己就有了更好的互動方案，或迭代進行到一半，發現場景不對。不能不說是遺憾。上邊談到的均是如何與其他崗位資源協同，求助於人。而自己要從已結束的迭代中發現問題，總結技巧，分享收穫，也把填坑方法說出來，可以讓更多人看到你的努力，更加信賴你，方便以後開展工作，和推廣使用者體驗的設計理念。
結語
以上四三二一走完，流程上並無新異之處，我把重點放在了資源協同和溝通物件上。願互動設計師除了能成為使用者的好朋友，也能努力成為同事們的好夥伴。
