由于性格和習慣，我在工作中時常處于內斂閉塞的狀態。但作為專職交互設計師，除了完善功能細節和發揮創意外，整合各方資源、監測用戶體驗風險、提升團隊的用戶意識，是同樣重要的工作職責，而這些均需要在項目開發中和其他崗位一起推進。如何克服思維局限、避免怠惰心理、充分調動內部資源，做到項目結束不留遺憾，一直是困擾我的問題。也一直在思考一種簡單易行的方法論，能通過外在規范來約束和督促自己。于是便有了被我稱為「四三二一」的交互設計流程管理工具。

四、三、二、一分別對應了產品開發流程中的需求、設計、開發、總結四個階段中應該采取的行動步驟，由前期到后期，由策劃到執行，均需要對應崗位的合作。從數字上可以看出，越是早期，應該要求越高、越多，以防止后期的偏差疏漏。下面從「四」開始說起。

「四」是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個教訓，即自我總結不足。

沒有完美的項目迭代，對交互設計師尤其如此。我經常是迭代剛開始，自己就有了更好的交互方案，或迭代進行到一半，發現場景不對。不能不說是遺憾。上邊談到的均是如何與其他崗位資源協同，求助于人。而自己要從已結束的迭代中發現問題，總結技巧，分享收獲，也把填坑方法說出來，可以讓更多人看到你的努力，更加信賴你，方便以后開展工作，和推廣用戶體驗的設計理念。

結語

以上四三二一走完，流程上并無新異之處，我把重點放在了資源協同和溝通對象上。愿交互設計師除了能成為用戶的好朋友，也能努力成為同事們的好伙伴。