編輯導語：在使用者體驗設計中，設計師需要參與到產品設計的全流程中，若遺漏某些設計細節，則可能會對產品落地造成嚴重影響。那麼，使用者體驗設計可以從哪些方面著手、避免設計遺漏？本文作者總結細化了使用者體驗設計的十二個步驟，一起來看一下。

受到

英雄旅程

［1］的啟發，給使用者體驗設計師的詳細指南。

（［1］英雄旅程 The Hero‘s Journey，一個英雄出發冒險，尋求轉變，贏得勝利，幫助同伴的旅程）

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

使用者體驗設計師和產品設計師的角色，已經超越了以往在某一個特定職能上簡單設計解決方案，

缺少跨職能參與度的局面

。為了尋求更好的設計方案，設計師需要跨職能地參與到專案的整個工作生態中。

我們都非常熟悉一種設計流程，即定義問題、創意發散、繪製原型和測試原型。這種設計流程可以滿足它的教育目的，被更多人輕鬆地理解，但是不涉及跨職能層面的內容，也沒有提供足夠多的細節來指導我們如何勝任使用者體驗設計師的工作。

使用者體驗設計師在每個階段都需要思考很多事情。

很重要的就是不要遺漏任何細節

，這些遺漏很可能會給設計的落地帶來負面影響，影響最終的產品、使用者體驗以及業務功能。

舉個例子，如果你忘記制定提升可訪問性的策略，你的使用者可能無法在他們首選的裝置上訪問你的產品，工程師不知道哪種裝置需要提供支援，設計師也會缺少設計的限制和考慮。

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

使用者體驗設計師旅程 The UX Designer’s Journey

如果你喜歡寫故事，可能聽說過 “英雄旅程”。

它描繪了大多數書籍講故事常用的 12 個步驟

。我認為一個專案的旅程，

從現有的產品到釋出新產品

，

再到分析最佳化

，

也可以像英雄旅程一樣被分成 12 個步驟

。這個旅程的英雄就是使用者體驗設計師。

一、目前的產品：當前世界

使用者體驗設計師在日常生活中會了解很多產品的

重要細節

、

產品特性

、

功能和使用者對產品的期望

，

甚至要考慮最佳化對產品和業務現狀的影響

。工作室裡的每個人、每一天都在他們固有的軌道上行駛，對於設計師而言，這是一個機會，讓你專注於一個難以在規定時間之內完成的工作。在這個階段我們可以做：

形成性調研，尋找機會點和洞察點；

評估性調研，尋找痛點和爽點；

把你的調研結果透過 PPT，報告的形式展示給你的小組；

給積壓的設計工作增加任務並設定優先順序；

升級設計系統（升級元件、檔案規範等）；

讓團隊所有人瞭解設計有關一些進度；

輔助產品方向確定（策略或者一些 workshop 和討論）。

二、應對挑戰：準備冒險

這一步破壞了現有產品的舒適性並提出了挑戰或要求

。

根據你所在團隊的工作方式和管理方式，挑戰會以不同的形式到來。

挑戰的規模也會隨著團隊的情況而變化

，可以是很大、很小、適中、非常聚焦或者更具開放性。

提取下一個待辦事項；

透過一個會議來討論業務目標（提升一個 KPI 等）；

透過一個會議來討論產品創意；

記錄下假設和問題，加入到調研事項中（這些會發生在整個專案旅程中）。

三、理解並計劃：拒絕冒險

使用者體驗設計師可能會很熱切地想要接受挑戰和要求，

但在這個階段需要回答和考慮一些問題

，

以確定前進的策略

。首先要確定遵循的設計方法：

設計衝刺

（風險很大的挑戰，快速的驗證，商業理念）；

精益

UX

（大中型的設計目標，業務目標）；

構思，原型，測試（小型挑戰，積壓的設計問題，調整設計方案）。

根據選擇的方法和挑戰的規模，以下步驟可能獨立或者以不同順序開展。

為了加深為對專案的理解

，

接下來開始提問或者進行一些小的練習

：

專案的目標和任務是什麼？如果不知道，可以對業務結果進行模擬練習。

使用者是誰？如果不知道，

試著建立一個原型角色

（稍後驗證）。

需要解決什麼問題？如果不知道，嘗試確立使用者目標。

對於企業和使用者而言，

成功的產品是怎樣的

？

哪些任務對使用者來說是很重要的？進行一個快速的使用者旅程練習，使用者寫在左邊，目標寫在右邊，

文字和箭頭在中間。

之前是否嘗試過這個挑戰

？（現有產品調研，結果如何）

什麼因素會導致專案失敗？

把答案轉變成 “我們可以怎麼樣”（How Might We ）。

確定設計標準清單（足夠具體以指導專案，但也要保持開放，提供探索和研究空間）。

使用者體驗設計師在這個階段，要開始對

可訪問性和包容性

設計打下基礎，討論和規劃以下內容：

支援的裝置、軟體和硬體；

以上裝置支援的版本；

考慮文化的多樣性

（如果是全球性專案），

以及文化因素會影響哪些方面

（比如時間，顏色使用，語言等）；

將這些內容寫進專案的設計規範裡（這條很容易被忘記和輕視）。

四、接觸專家和使用者：會議的導師

專家資訊有助於解答使用者體驗設計師當前的問題

，

為他們提供理論基石和設計信心

。

一個好的產品需要不同職能共同參與

，

而使用者體驗設計師需要把這些職能結合起來

。每一種職能都是某一領域的專家，比如使用者，科技，市場，商業等。最後，使用者體驗設計師將會擁有一個全域性視角，而不僅僅是站在設計職能的角度來看問題。

沒有人會了解一切。

—— Jake Knapp（設計衝刺）

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

專案經理；

市場人員；

銷售人員；

消費者服務；

工程開發；

使用者研究；

其他。

用

問句的形式來

獲取有用的資訊，比如：

哪些因素會推動專案的成功？

我們有哪些獨一無二的優勢和機會？

最大的威脅和風險是什麼

？

哪些因素會導致專案的失敗？

展示之前的計劃和練習，獲取他們的建議

為了更好地應對挑戰，你可以透過

調研來洞察機會

，發現當前產品的問題。比如，你面對的挑戰是 “提升使用者購買力“，那就需要：

尋找機會和新的洞見

，

產出研究結論；

透過評估式研究

，

發現使用者痛點和爽點；

把調研結果展示給整個團隊。

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

五、創意和解決方案：跨越門檻

到了這一步，

使用者體驗

設計師可以真正開始著手應對挑戰

，

尋求解決方法

。

這時候，無論是小組合作還是個人進行，都最好保持相對平衡的關係。如果在一個小組裡，最好遵循 “在一起，但獨立” 的準則。這意味著團隊裡職位更高的人不要控制整個團隊的思考，要給團隊更多的討論和決策空間。所有的練習和活動都應該匿名參與。

從尋找靈感開始

，

它不一定來自產品領域

。使用者有時也非常喜歡從其他領域，特別是他們經常使用的事物中學習互動模式。記得使用

閃電演示

［2］的方法在小組裡進行討論。

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

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

把想法用草圖的方式畫下來；

使用 crazy8 或者 six up 的方法來探索、延伸、迭代想法（兩種方法都是發散想法、伸概念的小工具）；

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

替代：在不影響使用流程的情況下，哪些部分可以被替代？

合併：可以把兩個流程合併成一個嗎？

適應：我們如何讓使用流程更加靈活？

修改

：

有什麼地方或元素可以加強或是顯眼一點

，

來顯現它的價值

？

其他用途：

還有誰可以使用這個產品

？

產品在不同設定或目的下會有什麼表現

？

消除：如果我們刪掉這一部分會怎麼樣？

反轉：如果我們逆轉這一流程會怎麼樣？

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

最後，

為了確保整個設計方案沒有遺漏

，

請使用步驟 3 進行查漏補缺

。

舉個例子，一個專案發現 “社交媒體廣告和電子郵件對模板有需求”，基於這個描述開始提問和練習，並繪製出草圖。請記得，很多時候，我們的重點應該完全放在產品以及核心流程上，而不是其他地方。

故事地圖

在這個時候，

故事地圖

，可以拆解想法並且確定

開展故事地圖討論會是有很有必要的

（MVP：Minimal Viable Product），特別是在一個不斷迭代、敏捷開發的環境下。

作為一個使用者體驗設計師，請確保可用性不會受到嚴重影響，可以允許少量干擾因素存在

最小可行性產品

，

。一旦透過原型驗證了想法

，

根據團隊的工作模式

（MUP：Minimal Usable Product）。

六、反饋和指導：測試、贊同、反對

可以使用故事地圖來嘗試搭建最小可用產品

。

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

專案經理——決策人（得到他們的批准）；

工程師——科技部門（探討技術方面是否可行，目前的裝置是否相容等問題）；

其他（取決於具體的專案）；

在設計評審中，使用者體驗設計師需要把自己的想法推銷出去；

設定一個場景，誰是使用者，在什麼場景，哪些必須是真實的，使用者是如何來到這裡的？

以使用者的角度來體驗產品原型；

不要遺漏次要資訊和細節，比如通知、載入狀態、錯誤狀態等；

每一個設計決策都需要有依據並且合理；

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

如果產生分歧，要從專業的角度來進行解釋，如果他們繼續提出問題，把問題記下來並表示你會繼續關注，必要時可用 A/B 測試；

所有的點評都是有價值的，不要完全否定那些反對意見，也不要以自我為中心。

有時候，設計評審這個過程可能需要幾次迭代才能完成，尤其是一些

註釋要寫在顯眼的地方；

。最終，由決策者決定最終的方案。一旦最終決策完成，就可以開始招募使用者來驗證設計方案，或者使用第三方招募服務和小組。

嘗試找到 6～7 名參與者，

複雜的技術問題

為每一場測試預定 1 小時的時間（包含稽核時間）；

在測試之間

發現設計方案中沒有被忽略的問題；

（15-30 分鐘）。

七、建立原型：設計的末端

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

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

預留休息和準備時間

：

紙模型（低保真）；

線框圖（低保真）；

視覺設計（高保真）；

虛擬資料（編碼）；

登陸頁測試（編碼）；

偽造的功能（編碼）；

需要確定保真度和原型

（編碼）［3］；

真實的功能（編碼）。

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

接下來，

綠野仙蹤

。有時候，使用者體驗設計師承擔了所有的任務，但是在理想情況下，這項工作需要混合其他職能：

UI 設計師；

視覺設計師；

文案；

設計資產管理者；

開發者（如果需要編碼）。

確定構建原型所需要的工作

：

紙筆、剪刀、膠水（紙模型）；

Balsamiq 軟體（線框圖）；

Sketch、Figma、Studio、Invision 等軟體（視覺設計）；

HTML、CSS、JS（編碼）；

其他更多。

原型工具

，

如果原型是需要編碼或高保真輸出

：

一致性和元件化；

層級和對比；

一些設計準則，如簡約至上、接近原則、尺寸等；

響應式設計（如果需要測試多個裝置，可以先選擇其中一個，在第 11 步時考慮其他裝置）；

提供反饋（讓使用者瞭解情況，獲得反饋）；

定義製表順序（如果不需要，可以在第 11 步進行）。

八、測試原型：面對考驗

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

建立好原型後，就可以開始驗證了。理想情況下，

請遵循設計規範

。首先，收集專案所有的假定、問題、原型，接著建立測試計劃和指令碼，思考以下幾個方面：

測試目的和選擇的方法；

需要了解哪些資訊（驗證假設，發現問題還是測試原型的功能）；

驗證專案中之前未解決的問題（如果時間足夠）；

測試參與者應該是誰（所有受影響的使用者，新手使用者和高階使用者，考慮使用者的多樣性和特殊性）；

如何衡量成功（任務成功率、任務完成時間、錯誤率、滿意度等）；

篩選問題並且補充一些新的問題；

接著開始撰寫指令碼，思考以下幾個方面：

介紹專案並且設定期望；

獲取參與者同意，提供獎勵作為感謝；

避免引導性問題，封閉性問題或者引入偏見，根據受眾使用不同的問題；

我們會和參與者進行一個 30 分鐘的對話

（最高優先順序到最低優先順序）；

確定問題和任務的優先順序

避免在任務編寫和任務排序中摻雜偏見；

如果缺少問題，在時間允許的情況下，可以進行更廣泛的研究（調查問卷、觀察筆記等）。

在進行測試之前，可以和同學進行模擬練習，這會幫助你發現指令碼隱藏的問題，

設定每個任務的目標和需要觀察的內容；

。

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

透過專業友好的開場白進行暖場（提供飲品，閒聊、開放的氛圍），讓參與者感到輕鬆；

確保整個流程的時間是合適的

適當地沉默，

觀察參與者是否有問題和顧慮；

，獲取更多細節；

給參與者更多時間思考

，

探究參與者的答案

不要引導參與者做任務測試，讓他們自己探索，

詢問原因；

面對參與者的問題，可以使用反問回答，比如詢問 “你怎麼看？”，必要時可以靈活調整測試任務，但是不要帶有偏見；

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

淨推薦值（NPS）；

系統可用性量表（SUS）；

其他定量資料。

九、調研結果：獲得寶劍

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

把調研過程中的發現記錄下來，以指導之後專案的發展，

儘量不提供幫助；

。最好將調研計劃和調研記錄放在一個文件裡，當你回顧時就不需要重新去理解專案是什麼，所有的東西都在一個地方可供查閱，

在未來遇到相似問題時不斷回顧這些經驗

。記錄以下內容：

調研概述，調研總結（資料視覺化、淨推薦值 NPS、系統可用性量表（SUS），或者其他內容）；

哪些假設和問題得到印證和解釋（提供證據，更新知識庫）；

單個任務的統計資訊（任務成功率、失敗率、任務時間）；

也可以避免其他瀏覽者多次跳轉

哪些環節進展順利；

產品漏洞（如果已經編碼）；

其他建議。

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

先寫重要資訊，總結和建議；

寫給那些可能會看這篇文件的人，思考他們想要知道什麼（可能包含專案經理、團隊負責人、調研者、市場負責人等）；

包含證據、影片、手稿等；

哪些環節出現問題；

，

留意那些有衝突的調研結果

（這類情況可能需要進一步探索）；

保持簡潔直接，避免歧義；

解釋每一個洞見的意義，以及可以做什麼；

保護參與者的個人資訊（不可洩露，除非得到他們同意）。

如果可能，讓整個團隊參與到調研中。透過實時（匿名）觀看或者參與錄製，讓團隊成員成為記錄者。

包含其他專案的研究

，

這樣你的團隊就可以更多地獲得一手資料

，

而不是透過報告來了解資訊

，

並且會更加激勵團隊

。

十、繼續專案或者進行迭代：回去的路

這場旅程還沒有結束，

提升工作效率

。根據測試結果，這裡有一些不同的方向可以選擇。最好的情況是，設計方案有效，只需要一些小的細節修改；最壞的情況是，設計方案失敗了。

設計是允許失敗的。

—— 精益 UX

根據調研結果，可以：

根據調研結果更新設計方案，以更好的服務使用者，通常只是一些小的調整（可以透過快速的使用者測試來重新驗證，節省時間）；

如果設計方案得到了部分驗證，回到步驟 5 去獲得新的創意，來修改那些失敗的原型；

如果原型完全失敗了，可以用以下這些建議來重新思考。使用者真的需要這個嗎？有更好的解決方案嗎？根據調研結果決定是否要回到步驟 5 去生成新的想法，重新定義設計挑戰和設計理解，或者直接過渡到下一個專案。

發起一個會議，

設計方案可能還需要根據其效能進行最佳化

、

向團隊成員展示調研

，

測試結果

，並提出下一階段的建議。

回到之前的步驟是一個很艱難的決定，也很難得到支援。更不幸的是，在設計衝刺階段，沒有足夠的時間支援後退。因此，需要透過調研結果來解釋後退的價值，從業務和使用者層面來說服決策者。

十一、最終的設計和成果：王者歸來

以及更新後的原型

。設計方案確定後，還需要補充一些其他狀態，比如開發團隊需要從設計師這裡瞭解到的資訊：

響應式設計（裝置種類、可訪問性、螢幕尺寸）；

跳轉邏輯和頁面滾動（可訪問性）；

特殊頁面（404、服務條款隱私頁面等）；

空白頁面、開屏頁面、幫助頁面；

圖示和影象；

載入、失敗、成功反饋，給使用者時間做出反應；

懸停狀態，選中狀態；

過渡動畫，不要刻意讓動畫很慢，避免閃爍；

元件尺寸（按鈕、連結、選單項）；

最終的媒體內容（圖片、文字、影片、音訊），與撰稿人合作完成；

設計方案會對現有產品以及開發工作產生重大影響

，

儘量不選用高飽和的色彩

（如有必要，請減少干擾和焦慮，允許使用者進行色彩模式切換）。

現在，

傾向平靜向的調色盤

，

可以開始思考如何衡量新的設計方案

。建立一個設計量化方案以確保開發團隊可以進行正確有效的資料埋點。思考以下幾點：

業務和專案目標；

支援目標的戰略和策略；

需要追蹤關注的 KPI；

需要追蹤關注的互動行為；

轉化漏斗；

第三方應用程式（Hotjar， Google Analytics 等）；

宏觀目標和微觀目標；

建立一個追蹤任務，並讓開發團隊實行。

為了方便開發團隊制定工作計劃，

以驗證新產品是否成功或者需要改進

，並支援隨時訪問。保持與開發團隊的溝通，減少資訊差，做好支援性工作，有時候仍需要修改一些設計細節。

設計師需要確保原型和其他設計資產易於理解

，

定期檢視開發團隊的工作程序

，且符合設計規範。對開發交付的內容進行最後的設計審查，包含：

檢查每個頁面，以及在不同裝置上的顯示狀態；

確認影象、影片、音訊內容；

檢查鍵盤、螢幕閱讀和盲文閱讀器的狀態；

檢查目標區域的懸停和選中狀態；

檢查動畫和過渡；

進行對比度和字號大小；

確保所有的通知提示是易於理解的，特別是錯誤提示。

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

十二、釋出和分析：寶貴的經驗

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

以確保專案順利推進

，

當產品透過質量檢查併成功釋出

。接下來就要開始收集資料了，時間跨度取決於產品的使用頻率和使用者群大小，可能需要數週甚至數月。資料收集完成後，請建立報告或簡報，內容包含：

分析產品帶來的價值、時間投入、金錢投入、商業價值、投資回報等；

分析業務目標和 KPI 是否完成，是接近目標還是離目標很遠；

分析專案的宏觀目標和微觀目標，哪些是有效的，哪些是無效的？

分析價值轉化漏斗，在某一個步驟存在很高的跳出率嗎？

分析一些基礎資料，比如獲客率、跳出率等；

多資料三角分析，提供更多有價值的結論，比如資料、熱點圖等。

如果結果是糟糕的，

就會來到一個新的階段

。如果結果讓整個團隊離 KPI 更近一步，或者有任何可以提升的地方，那麼就值得花時間強化這些部分，幫助專案順利進行。接下來，就可以在歸檔檔案中加入這些結論，或者進入下一個設計挑戰，繼續向業務目標邁進。

覆盤就變得更有價值 —— 找到出錯點和最佳化點

這是一個動態的過程，以上提及的步驟會隨著時間的發展有所改變。UX 設計師需要具備多樣化的技能，來參與整個專案旅程。

毫無疑問的是，我一定遺漏了一些細節。我所描述的步驟和你的專案經歷有相似之處嗎？你會因此改變哪些步驟？或者增加哪些內容？我漏掉了什麼？歡迎交流！

本文翻譯已獲得作者的正式授權（授權截圖如下）。

作者：Blayne Philips，譯者：王英睿，編輯：孫淑雅，稽核：張小璽；公眾號：TCC翻譯情報局

原文連結：https：//uxdesign。cc/the-12-step-designers-journey-694de2568153

本文由@TCC翻譯情報局 翻譯釋出於人人都是產品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基於 CC0 協議