「交互設計師到底具體做什麼？」雖然教科書給出標準答案——發現需求、提出方案、製作原型、用戶測試——但落地到具體專案、具體細節，每位設計師的實踐路徑各不相同。本文以網易郵箱「日程管理」專案為例，完整複盤一位交互設計師的實戰全流程。

階段一：發現需求，建立明確目標

1. 多源收集用戶聲音

• 用戶反饋系統：用戶抱怨「忙碌時忘記會議/約會」，期望專業日程管理
• 客服工單分析：高頻投訴「郵件裡的時間信息無法一鍵入行程」
• 競品體驗報告：Google Calendar、Outlook 行為模式基準線

2. 立項與跨職能啟動

產品經理發起立項，拉齊用研、交互、視覺、開發、測試組建專項小組。明確目標用戶：高頻郵件用戶、多會議職場人士、跨時區協作群體。

3. 混合調研方法論

• 用研組：大樣本問卷（N>2000）量化痛點優先級
• 交互設計師參與：協助設計問卷邏輯、分析開放題質性數據
• 團隊腦暴工作坊：回憶生活場景 → 提煉關鍵詞 → 親和圖歸類 → 輸出核心任務模型

產出：需求文檔（PRD）v1.0，包含核心功能清單、優先級、驗收標準、非功能性需求。

階段二：提出設計方案—— 概念設計與低保真探索

1. 概念敘述

「一個專業的日程管理功能，讓用戶高效管理每日日程與時間，提升工作效率，不再錯過任何重要約會！」

2. 初稿設計：手繪優先，快速收斂

不拘泥工具：Axure 流程圖、手繪草圖、白板流程圖皆可。核心目標——清晰表達設計構思，支撐團隊討論決策。

階段三：製作高保真交互原型—— 迭代的藝術

1. 交互更新日誌：版本管理的生命線

原型首頁建立「交互更新日誌」表格，字段：

字段	作用
更新時間	全鏈路追蹤，掌握時間節奏
版本名稱	快速定位歷史版本，支持回滾對比
更新類型	新增/修改/刪除/優化/技術債，識別變更性質
更新內容	具體變更描述 + 直接跳轉鏈接，消除「找不到改哪」痛點
參考需求文檔	雙向追溯：原型↔PRD，保證一致性
交互負責人	責任到人，便於交接與問責

2. 保真度選擇策略

• 成熟產品（如郵箱）：高保真模型，複用組件庫，效率優先
• 全新專案：黑白線框圖，聚焦流程邏輯而非視覺細節
• 設計師具備視覺把控力：可適度精致，減少後續視覺返工

階段四：編寫交互說明書—— 為溝通而生，不為文檔而文檔

交互說明書不是設計師的「舞文弄墨」，而是降低跨職能溝通成本的工具。通過訪談產品、視覺、開發、前端、測試等角色，提煉真實需求：

角色	核心需求	回應策略
產品/開發	頁面跳轉邏輯、業務規則、異常分支	流程圖+狀態機表、關鍵決策點註釋
產品	與 PRD 雙向關聯、避免內容重複	交互說明嵌入 PRD 或雙向超鏈接
視覺/頁面架構	隱藏交互、極限狀態、風格定位	標註 Focus/Hover/Loading/Empty/Error 狀態、預留擴展槽位
前端	極限數據（最長/最短列表）、邊界條件、異常處理	極限狀態專欄、錯誤碼映射表、降級方案

反模式警示

• ❌ 大段複製原型頁面截圖 + 流水賬文字
• ❌ 重複 PRD 已明確的邏輯判斷（單選/多選、必填校驗）
• ❌ 只有設計師自己看懂的專業術語堆砌

最佳載體選擇

不拘泥格式：原型頁面直接標註（Axure 便註/頁面備註）、圖上寫說明（Sketch/Figma 註釋）、郵件正文（輕量級同步）、Wiki/Confluence 頁面（持久化知識庫）、PPT（階段性匯報）。核心原則：解決具體溝通問題，需要時才產出，用完即棄不留垃圾。

階段五：用戶測試與驗證閉環

• 功能上線前：招募真實用戶進行可用性測試，收集場景化問題
• 整理優化點 → 納入迭代規劃 → 驗證修復效果
• 設計師長期自用自家產品：保證上線版本與設計稿一致，捕捉真實場景體驗斷層

心得與進階建議

交互設計「不難」（人人都是用戶，天然有同理心），但「很需要花心思」（決策自由度高、疏忽成本大、需嚴謹邏輯自洽）。持續精進路徑：

1. 建立個人「交互決策日記」，記錄關鍵決策理由與事後驗證
2. 系統學習認知心理學、行為經濟學、人機交互理論
3. 參與開源設計系統建設，在大規模實踐中打磨組件設計能力
4. 跨領域協作：主動理解開發技術棧、數據分析方法、商業模型邏輯

期待更多同行分享實戰細節，共同推動交互設計專業化進程。