大家好，這里是 TCC 翻譯情報局，我是李澤慧。在如今的產品設計團隊中，體驗設計師需要做的事情已經跨越了職能邊界，為了尋求更好的設計方案，常常要承上啟下地連接整個團隊。其中所涉及的工作，基于我們熟知的設計流程，同時隱藏了許多跨職能的思考和工作細節，需要體驗設計師全方位理解設計工作對其他職能的影響，以及其他職能工作對設計的限制。作者將定義問題、創意發散、原型 & 測試、復盤反思四大設計流程細化為 12 個步驟，詳細講述了每個步驟涉及的職能任務和思考。就像開啟一段英雄旅程，設計師需要充分理解并計劃這場冒險之旅，遵循規則，從而更好地解決問題，應對挑戰。

 

△ UX 設計師的旅程圖，包含了四個象限，12 個步驟，每個象限有 3 個步驟

 

用戶體驗設計師和產品設計師的角色，已經超越了以往在某一個特定職能上簡單設計解決方案，缺少跨職能參與度的局面 。為了尋求更好的設計方案，設計師需要跨職能地參與到項目的整個工作生態中。我們都非常熟悉一種設計流程，即定義問題，創意發散，繪制原型和測試原型。這種設計流程可以滿足它的教育目的，被更多人輕松的理解，但是不涉及跨職能層面的內容，也沒有提供足夠多的細節來指導我們如何勝任用戶體驗設計師的工作。

用戶體驗設計師在每個階段都需要思考很多事情。很重要的就是不要遺漏任何細節，這些遺漏很可能會給設計的落地帶來負面影響，影響最終的產品、用戶體驗以及業務功能。舉個例子，如果你忘記制定提升可訪問性的策略，你的用戶可能無法在他們首選的設備上訪問你的產品，工程師不知道哪種設備需要提供支持，設計師也會缺少設計的限制和考慮。

知曉以上所有的信息后，我想到創造一個跨職能設計流程，同時提供足夠多的細節來幫助用戶體驗設計師遵循這個流程。

用戶體驗設計師旅程

如果你喜歡寫故事，可能聽說過 “英雄旅程”。它描繪了大多數書籍講故事常用的 12 個步驟。我認為一個項目的旅程，從現有的產品到發布新產品，再到分析優化，也可以像英雄旅程一樣被分成 12 個步驟。這個旅程的英雄就是用戶體驗設計師。

1. 目前的產品

當前世界

用戶體驗設計師在日常生活中會了解很多產品的重要細節、產品特性、功能和用戶對產品的期望，甚至要考慮優化對產品和業務現狀的影響 。工作室里的每個人、每一天都在他們固有的軌道上行駛，對于設計師而言，這是一個機會，讓你專注于一個難以在規定時間之內完成的工作。在這個階段我們可以做：

• 形成性調研，尋找機會點和洞察點
• 評估性調研，尋找痛點和爽點
• 把你的調研結果通過 PPT，報告的形式展示給你的小組
• 給積壓的設計工作增加任務并設定優先級
• 升級設計系統(升級組件、文件規范等)
• 讓團隊所有人了解設計有關的一些進度
• 輔助產品方向確定(策略或者一些 workshop 和討論)

2. 應對挑戰

準備冒險

這一步破壞了現有產品的舒適性并提出了挑戰或要求 。根據你所在團隊的工作方式和管理方式，挑戰會以不同的形式到來。挑戰的規模也會隨著團隊的情況而變化，可以是很大、很小、適中、非常聚焦或者更具開放性。

• 提取下一個待辦事項
• 通過一個會議來討論業務目標(提升一個 KPI 等)
• 通過一個會議來討論產品創意
• 記錄下假設和問題，加入到調研事項中(這些會發生在整個項目旅程中)

3. 理解并計劃

拒絕冒險

用戶體驗設計師可能會很熱切地想要接受挑戰和要求，但在這個階段需要回答和考慮一些問題，以確定前進的策略 。首先要確定遵循的設計方法：

• 設計沖刺(風險很大的挑戰，快速的驗證，商業理念)
• 精益 UX(大中型的設計目標，業務目標)
• 構思，原型，測試(小型挑戰，積壓的設計問題，調整設計方案)

根據選擇的方法和挑戰的規模，以下步驟可能獨立或者以不同順序開展。為了加深為對項目的理解，接下來開始提問或者進行一些小的練習：

• 項目的目標和任務是什么?如果不知道，可以對業務結果進行模擬練習
• 用戶是誰?如果不知道，試著建立一個原型角色 (稍后驗證)
• 需要解決什么問題?如果不知道，嘗試確立用戶目標
• 對于企業和用戶而言，成功的產品是怎樣的?
• 哪些任務對用戶來說是很重要的?進行一個快速的用戶旅程練習，用戶寫在左邊，目標寫在右邊，文字和箭頭在中間
• 之前是否嘗試過這個挑戰?(現有產品調研，結果如何)
• 什么因素會導致項目失敗?
• 把答案轉變成 “我們可以怎么樣”(How Might We )
• 確定設計標準清單(足夠具體以指導項目，但也要保持開放，提供探索和研究空間)

用戶體驗設計師在這個階段，要開始對可訪問性和包容性設計打下基礎，討論和規劃以下內容：

• 支持的設備、軟件和硬件
• 以上設備支持的版本
• 考慮文化的多樣性(如果是全球性項目)，以及文化因素會影響哪些方面(比如時間，顏色使用，語言等)
• 將這些內容寫進項目的設計規范里(這條很容易被忘記和輕視)

4. 接觸專家和用戶

會議的導師

專家信息有助于解答用戶體驗設計師當前的問題 ，為他們提供理論基石和設計信心 。

一個好的產品需要不同職能共同參與，而用戶體驗設計師需要把這些職能結合起來 。每一種職能都是某一領域的專家，比如用戶、科技、市場、商業等。最后，用戶體驗設計師將會擁有一個全局視角，而不僅僅是站在設計職能的角度來看問題。

• 沒有人會了解一切。—— Jake Knapp(設計沖刺)

設定一個 15 分鐘的會議，并和職能負責人商談，包括：

• 項目經理
• 市場人員
• 銷售人員
• 消費者服務
• 工程開發
• 用戶研究
• 其他

用問句的形式來獲取有用的信息，比如：

• 哪些因素會推動項目的成功?
• 我們有哪些獨一無二的優勢和機會?
• 最大的威脅和風險是什么?
• 哪些因素會導致項目的失敗?
• 展示之前的計劃和練習，獲取他們的建議

為了更好地應對挑戰，你可以通過調研來洞察機會，發現當前產品的問題。比如，你面對的挑戰是 “提升用戶購買力“，那就需要：

• 尋找機會和新的洞見，產出研究結論
• 通過評估式研究，發現用戶痛點和爽點
• 把調研結果展示給整個團隊

優秀的用戶體驗設計師可以綜合以上所有的信息，進而找到一個最佳解決方案。

5. 創意和解決方案

跨越門檻

到了這一步，用戶體驗設計師可以真正開始著手應對挑戰，尋求解決方法。這時候，無論是小組合作還是個人進行，都最好保持相對平衡的關系。如果在一個小組里，最好遵循 “在一起，但獨立” 的準則。這意味著團隊里職位更高的人不要控制整個團隊的思考，要給團隊更多的討論和決策空間。所有的練習和活動都應該匿名參與。

從尋找靈感開始，它不一定來自產品領域 。用戶有時也非常喜歡從其他領域，特別是他們經常使用的事物中學習交互模式。記得使用閃電演示[2] 的方法在小組里進行討論。

([2] 閃電演示 Lightening Demo，即一種有組織結構的展示會議，參與者可以展示他們的靈感和喜歡的點子以激發所有人的討論)

一旦找到了靈感，回顧一下之前所有收集到的信息。這時候，用戶體驗設計師會有許許多多的想法，可以：

• 把想法用草圖的方式畫下來
• 使用 crazy8 或者 six up 的方法來探索、延伸、迭代想法 (兩種方法都是發散想法、延伸概念的小工具)

如果缺乏想法，可以用 SCAMPER 方法來問自己：

• 替代：在不影響使用流程的情況下，哪些部分可以被替代?
• 合并：可以把兩個流程合并成一個嗎?
• 適應：我們如何讓使用流程更加靈活?
• 修改：有什么地方或元素可以加強或是顯眼一點，來顯現它的價值?
• 其他用途：還有誰可以使用這個產品?產品在不同設定或目的下會有什么表現?
• 消除：如果我們刪掉這一部分會怎么樣?
• 反轉：如果我們逆轉這一流程會怎么樣?

回顧整個過程，在小組內進行投票，選擇最好的想法并且：

• 畫出具體的解決方法
• 制作導航和站點地圖
• 制作任務流程

最后，為了確保整個設計方案沒有遺漏 ，請使用步驟 3 進行查漏補缺 。舉個例子，一個項目發現 “社交媒體廣告和電子郵件對模板有需求”，基于這個描述開始提問和練習，并繪制出草圖。請記得，很多時候，我們的重點應該完全放在產品以及核心流程上，而不是其他地方。

故事地圖

在這個時候，開展故事地圖討論會是很有必要的，可以拆解想法并且確定最小可行性產品(MVP：Minimal Viable Product)，特別是在一個不斷迭代、敏捷開發的環境下。作為一個用戶體驗設計師，請確保可用性不會受到嚴重影響，可以允許少量干擾因素存在。一旦通過原型驗證了想法，根據團隊的工作模式，可以使用故事地圖來嘗試搭建最小可用產品(MUP：Minimal Usable Product)。

6. 反饋和指導

測試、贊同、反對

用戶體驗設計師必須面對通往最終解決方案過程中的反饋和批評 。

在一個合作性的工作坊中，最好的想法和機會點會通過投票產生。舉個例子，在一個設計沖刺中，用戶體驗設計師提出的解決方案需要得到其他利益相關者的反饋意見。他們可以是：

• 項目經理 — 決策人(得到他們的批準)
• 工程師 — 科技部門(探討技術方面是否可行，目前的設備是否兼容等問題)
• 其他(取決于具體的項目)
• 在設計評審中，用戶體驗設計師需要把自己的想法推銷出去
• 設定一個場景，誰是用戶，在什么場景，哪些必須是真實的，用戶是如何來到這里的?
• 以用戶的角度來體驗產品原型
• 不要遺漏次要信息和細節，比如通知，加載狀態，錯誤狀態等
• 每一個設計決策都需要有依據并且合理
• 注釋要寫在顯眼的地方
• 如果產生分歧，要從專業的角度來進行解釋，如果他們繼續提出問題，把問題記下來并表示你會繼續關注，必要時可用 A/B 測試
• 所有的點評都是有價值的，不要完全否定那些反對意見，也不要以自我為中心

有時候，設計評審這個過程可能需要幾次迭代才能完成，尤其是一些復雜的技術問題。最終，由決策者決定最終的方案。一旦最終決策完成，就可以開始招募用戶來驗證設計方案，或者使用第三方招募服務和小組。

• 嘗試找到 6～7 名參與者，發現設計方案中沒有被忽略的問題
• 為每一場測試預定 1 小時的時間(包含審核時間)
• 在測試之間預留休息和準備時間(15-30 分鐘)

7. 建立原型

設計的末端

在進行最終的設計驗證之前，還需要完成最后一步。

區分原型和可交付給軟件開發者的設計規范是很重要的，在這個階段，我們關注的是前者。這意味著要創建一個高保真的最小可行性原型來獲得驗證。首先，需要確定保真度和原型：

• 紙模型(低保真)
• 線框圖(低保真)
• 視覺設計(高保真)
• 虛擬數據 (編碼)
• 登陸頁測試(編碼)
• 偽造的功能(編碼)
• 綠野仙蹤(編碼)[3]
• 真實的功能(編碼)

([3]：綠野仙蹤 Wizard of oz：在開發聊天機器人之前，可以利用“綠野仙蹤”作為最小化可行產品(MVP)測試。“綠野仙蹤”測試的名稱來源于《綠野仙蹤》這部電影。測試時，有一個真人(“魔法師”)會替代機器與用戶進行對話。)

接下來，確定構建原型所需要的工作。有時候，用戶體驗設計師承擔了所有的任務，但是在理想情況下，這項工作需要混合其他職能：

• UI 設計師
• 視覺設計師
• 文案
• 設計資產管理者
• 開發者 (如果需要編碼)

原型工具：

• 紙筆、剪刀、膠水(紙模型)
• Balsamiq 軟件(線框圖)
• Sketch、Figma、Studio、Invision 等軟件(視覺設計)
• HTML、CSS、JS(編碼)
• 其他更多

如果原型是需要編碼或高保真輸出 ，請遵循設計規范：

• 一致性和組件化
• 層級和對比
• 一些設計準則，如簡約至上，接近原則，尺寸等
• 響應式設計(如果需要測試多個設備，可以先選擇其中一個，在第 11 步時考慮其他設備)
• 提供反饋(讓用戶了解情況，獲得反饋)
• 定義制表順序(如果不需要，可以在第 11 步進行)

8. 測試原型

面對考驗

與客戶一起測試設計方案的性能，可以獲得更深入的洞察和見解，更好地推動項目落地。

建立好原型后，就可以開始驗證了。理想情況下，我們會和參與者進行一個 30 分鐘的對話 。首先，收集項目所有的假定、問題、原型，接著建立測試計劃和腳本，思考以下幾個方面：

• 測試目的和選擇的方法
• 需要了解哪些信息(驗證假設，發現問題還是測試原型的功能)
• 驗證項目中之前未解決的問題(如果時間足夠)
• 測試參與者應該是誰(所有受影響的用戶，新手用戶和高級用戶，考慮用戶的多樣性和特殊性)
• 如何衡量成功(任務成功率、任務完成時間、錯誤率、滿意度等)
• 篩選問題并且補充一些新的問題

接著開始撰寫腳本，思考以下幾個方面：

• 介紹項目并且設定期望
• 獲取參與者同意，提供獎勵作為感謝
• 避免引導性問題，封閉性問題或者引入偏見，根據受眾使用不同的問題
• 確定問題和任務的優先級(最高優先級到最低優先級)
• 避免在任務編寫和任務排序中摻雜偏見
• 設定每個任務的目標和需要觀察的內容
• 如果缺少問題，在時間允許的情況下，可以進行更廣泛的研究(調查問卷，觀察筆記等)
• 在進行測試之前，可以和同學進行模擬練習，這會幫助你發現腳本隱藏的問題，確保整個流程的時間是合適的 。

當參與者、原型和腳本都已準備好，就可以進行測試了，確保以下幾個方面：

• 通過專業友好的開場白進行暖場(提供飲品，閑聊、開放的氛圍)，讓參與者感到輕松
• 觀察參與者是否有問題和顧慮
• 適當地沉默，給參與者更多時間思考，獲取更多細節
• 探究參與者的答案 ，詢問原因
• 不要引導參與者做任務測試，讓他們自己探索，盡量不提供幫助
• 面對參與者的問題，可以使用反問回答，比如詢問 “你怎么看?”，必要時可以靈活調整測試任務，但是不要帶有偏見

允許參與者表達其他想法，并通過介紹接下來的步驟來結束每一個測試環節。也可以要求參與者填寫問卷，來獲得：

• 凈推薦值(NPS)
• 系統可用性量表(SUS)
• 其他定量數據

9. 調研結果

獲得寶劍

調研產生的結果會通過不同形式回饋給設計師，比如問題、更多的知識和洞見，或者是設計上的驗證。

把調研過程中的發現記錄下來，以指導之后項目的發展，在未來遇到相似問題時不斷回顧這些經驗 。最好將調研計劃和調研記錄放在一個文檔里，當你回顧時就不需要重新去理解項目是什么，所有的東西都在一個地方可供查閱，也可以避免其他瀏覽者多次跳轉 。記錄以下內容：

• 調研概述，調研總結(數據可視化，凈推薦值 NPS，系統可用性量表(SUS)，或者其他內容)
• 哪些假設和問題得到印證和解釋(提供證據，更新知識庫)
• 單個任務的統計信息(任務成功率、失敗率、任務時間)
• 哪些環節進展順利
• 哪些環節出現問題
• 產品漏洞(如果已經編碼)
• 其他建議

當記錄這些調研結果的時候，確保：

• 先寫重要信息，總結和建議
• 寫給那些可能會看這篇文檔的人，思考他們想要知道什么(可能包含項目經理、團隊負責人、調研者、市場負責人等)
• 包含證據、視頻、手稿等
• 留意那些有沖突的調研結果 ，包含其他項目的研究(這類情況可能需要進一步探索)
• 保持簡潔直接，避免歧義
• 解釋每一個洞見的意義，以及可以做什么
• 保護參與者的個人信息(不可泄露，除非得到他們同意)

如果可能，讓整個團隊參與到調研中。通過實時(匿名)觀看或者參與錄制，讓團隊成員成為記錄者。這樣你的團隊就可以更多地獲得一手資料，而不是通過報告來了解信息，并且會更加激勵團隊，提升工作效率。

10. 繼續項目或者進行迭代

回去的路

這場旅程還沒有結束，設計方案可能還需要根據其性能進行優化 。根據測試結果，這里有一些不同的方向可以選擇。最好的情況是，設計方案有效，只需要一些小的細節修改;最壞的情況是，設計方案失敗了。

• 設計是允許失敗的—— 精益 UX

根據調研結果，可以：

• 根據調研結果更新設計方案，以更好的服務用戶，通常只是一些小的調整(可以通過快速的用戶測試來重新驗證，節省時間)
• 如果設計方案得到了部分驗證，回到步驟 5 去獲得新的創意，來修改那些失敗的原型
• 如果原型完全失敗了，可以用以下這些建議來重新思考。用戶真的需要這個嗎?有更好的解決方案嗎?根據調研結果決定是否要回到步驟 5 去生成新的想法，重新定義設計挑戰和設計理解，或者直接過渡到下一個項目。

發起一個會議，向團隊成員展示調研、測試結果，以及更新后的原型，并提出下一階段的建議。回到之前的步驟是一個很艱難的決定，也很難得到支持。更不幸的是，在設計沖刺階段，沒有足夠的時間支持后退。因此，需要通過調研結果來解釋后退的價值，從業務和用戶層面來說服決策者。

11. 最終的設計和成果

王者歸來

設計方案會對現有產品以及開發工作產生重大影響 。設計方案確定后，還需要補充一些其他狀態，比如開發團隊需要從設計師這里了解到的信息：

• 響應式設計(設備種類，可訪問性，屏幕尺寸)
• 跳轉邏輯和頁面滾動(可訪問性)
• 特殊頁面(404，服務條款隱私頁面等)
• 空白頁面、開屏頁面、幫助頁面
• 圖標和圖像
• 加載、失敗、成功反饋，給用戶時間做出反應
• 懸停狀態，選中狀態
• 過渡動畫，不要刻意讓動畫很慢，避免閃爍
• 組件尺寸(按鈕，鏈接，菜單項)
• 最終的媒體內容(圖片，文字，視頻，音頻)，與撰稿人合作完成
• 盡量不選用高飽和的色彩，傾向平靜向的調色板(如有必要，請減少干擾和焦慮，允許用戶進行色彩模式切換)

現在，可以開始思考如何衡量新的設計方案，以驗證新產品是否成功或者需要改進。建立一個設計量化方案以確保開發團隊可以進行正確有效的數據埋點。思考以下幾點：

• 業務和項目目標
• 支持目標的戰略和策略
• 需要追蹤關注的 KPI
• 需要追蹤關注的交互行為
• 轉化漏斗
• 第三方應用程序 (Hotjar, Google Analytics 等)
• 宏觀目標和微觀目標
• 創建一個追蹤任務，并讓開發團隊實行

為了方便開發團隊制定工作計劃，設計師需要確保原型和其他設計資產易于理解 ，并支持隨時訪問。保持與開發團隊的溝通，減少信息差，做好支持性工作，有時候仍需要修改一些設計細節。

定期查看開發團隊的工作進程，以確保項目順利推進，且符合設計規范。對開發交付的內容進行最后的設計審查，包含：

• 檢查每個頁面，以及在不同設備上的顯示狀態
• 確認圖像、視頻、音頻內容
• 檢查鍵盤、屏幕閱讀和盲文閱讀器的狀態
• 檢查目標區域的懸停和選中狀態
• 檢查動畫和過渡
• 進行對比度和字號大小
• 確保所有的通知提示是易于理解的，特別是錯誤提示

不要過分依賴質量檢測團隊去發現設計以及可訪問性方面的問題。

12. 發布和分析

寶貴的經驗

接下來要講的，是一個解決問題的方法，又或者是一個整理思路，請大家自行感受。

當產品通過質量檢查并成功發布 ，就會來到一個新的階段。接下來就要開始收集數據了，時間跨度取決于產品的使用頻率和用戶群大小，可能需要數周甚至數月。數據收集完成后，請創建報告或演示文稿，內容包含：

• 分析產品帶來的價值，時間投入，金錢投入，商業價值，投資回報等
• 分析業務目標和 KPI 是否完成，是接近目標還是離目標很遠
• 分析項目的宏觀目標和微觀目標，哪些是有效的，哪些是無效的?
• 分析價值轉化漏斗，在某一個步驟存在很高的跳出率嗎?
• 分析一些基礎數據，比如獲客率，跳出率等
• 多數據三角分析，提供更多有價值的結論，比如數據，熱點圖等

如果結果是糟糕的，復盤就變得更有價值 —— 找到出錯點和優化點 。如果結果讓整個團隊離 KPI 更近一步，或者有任何可以提升的地方，那么就值得花時間強化這些部分，幫助項目順利進行。接下來，就可以在歸檔文件中加入這些結論，或者進入下一個設計挑戰，繼續向業務目標邁進。

聽你說

這是一個動態的過程，以上提及的步驟會隨著時間的發展有所改變。UX 設計師需要具備多樣化的技能，來參與整個項目旅程。毫無疑問的是，我一定遺漏了一些細節。我所描述的步驟和你的項目經歷有相似之處嗎?你會因此改變哪些步驟?或者增加哪些內容?我漏掉了什么?歡迎交流!