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

受到 英雄旅程[1]的啟發(fā)，給用戶體驗設(shè)計師的詳細指南。

（[1]英雄旅程 The Hero‘s Journey，一個英雄出發(fā)冒險，尋求轉(zhuǎn)變，贏得勝利，幫助同伴的旅程）

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

用戶體驗設(shè)計師和產(chǎn)品設(shè)計師的角色，已經(jīng)超越了以往在某一個特定職能上簡單設(shè)計解決方案，缺少跨職能參與度的局面。為了尋求更好的設(shè)計方案，設(shè)計師需要跨職能地參與到項目的整個工作生態(tài)中。

我們都非常熟悉一種設(shè)計流程，即定義問題、創(chuàng)意發(fā)散、繪制原型和測試原型。這種設(shè)計流程可以滿足它的教育目的，被更多人輕松地理解，但是不涉及跨職能層面的內(nèi)容，也沒有提供足夠多的細節(jié)來指導(dǎo)我們?nèi)绾蝿偃斡脩趔w驗設(shè)計師的工作。

用戶體驗設(shè)計師在每個階段都需要思考很多事情。很重要的就是不要遺漏任何細節(jié)，這些遺漏很可能會給設(shè)計的落地帶來負面影響，影響最終的產(chǎn)品、用戶體驗以及業(yè)務(wù)功能。

舉個例子，如果你忘記制定提升可訪問性的策略，你的用戶可能無法在他們首選的設(shè)備上訪問你的產(chǎn)品，工程師不知道哪種設(shè)備需要提供支持，設(shè)計師也會缺少設(shè)計的限制和考慮。

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

用戶體驗設(shè)計師旅程?The UX Designer’s Journey

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

一、目前的產(chǎn)品：當(dāng)前世界

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

• 形成性調(diào)研，尋找機會點和洞察點；
• 評估性調(diào)研，尋找痛點和爽點；
• 把你的調(diào)研結(jié)果通過 PPT，報告的形式展示給你的小組；
• 給積壓的設(shè)計工作增加任務(wù)并設(shè)定優(yōu)先級；
• 升級設(shè)計系統(tǒng)（升級組件、文件規(guī)范等）；
• 讓團隊所有人了解設(shè)計有關(guān)一些進度；
• 輔助產(chǎn)品方向確定（策略或者一些 workshop 和討論）。

二、應(yīng)對挑戰(zhàn)：準備冒險

這一步破壞了現(xiàn)有產(chǎn)品的舒適性并提出了挑戰(zhàn)或要求。

根據(jù)你所在團隊的工作方式和管理方式，挑戰(zhàn)會以不同的形式到來。挑戰(zhàn)的規(guī)模也會隨著團隊的情況而變化，可以是很大、很小、適中、非常聚焦或者更具開放性。

• 提取下一個待辦事項；
• 通過一個會議來討論業(yè)務(wù)目標（提升一個 KPI 等）；
• 通過一個會議來討論產(chǎn)品創(chuàng)意；
• 記錄下假設(shè)和問題，加入到調(diào)研事項中（這些會發(fā)生在整個項目旅程中）。

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

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

• 設(shè)計沖刺（風(fēng)險很大的挑戰(zhàn)，快速的驗證，商業(yè)理念）；
• 精益UX（大中型的設(shè)計目標，業(yè)務(wù)目標）；
• 構(gòu)思，原型，測試（小型挑戰(zhàn)，積壓的設(shè)計問題，調(diào)整設(shè)計方案）。

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

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

用戶體驗設(shè)計師在這個階段，要開始對可訪問性和包容性設(shè)計打下基礎(chǔ)，討論和規(guī)劃以下內(nèi)容：

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

四、接觸專家和用戶：會議的導(dǎo)師

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

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

沒有人會了解一切。

—— Jake Knapp（設(shè)計沖刺）

設(shè)定一個 15 分鐘的會議，并和職能負責(zé)人商談，包括：

• 項目經(jīng)理；
• 市場人員；
• 銷售人員；
• 消費者服務(wù)；
• 工程開發(fā)；
• 用戶研究；
• 其他。

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

• 哪些因素會推動項目的成功？
• 我們有哪些獨一無二的優(yōu)勢和機會？
• 最大的威脅和風(fēng)險是什么？
• 哪些因素會導(dǎo)致項目的失??？
• 展示之前的計劃和練習(xí)，獲取他們的建議

為了更好地應(yīng)對挑戰(zhàn)，你可以通過調(diào)研來洞察機會，發(fā)現(xiàn)當(dāng)前產(chǎn)品的問題。比如，你面對的挑戰(zhàn)是 “提升用戶購買力“，那就需要：

• 尋找機會和新的洞見，產(chǎn)出研究結(jié)論；
• 通過評估式研究，發(fā)現(xiàn)用戶痛點和爽點；
• 把調(diào)研結(jié)果展示給整個團隊。

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

五、創(chuàng)意和解決方案：跨越門檻

到了這一步，用戶體驗設(shè)計師可以真正開始著手應(yīng)對挑戰(zhàn)，尋求解決方法。

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

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

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

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

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

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

• 替代：在不影響使用流程的情況下，哪些部分可以被替代？
• 合并：可以把兩個流程合并成一個嗎？
• 適應(yīng)：我們?nèi)绾巫屖褂昧鞒谈屿`活？
• 修改：有什么地方或元素可以加強或是顯眼一點，來顯現(xiàn)它的價值？
• 其他用途：還有誰可以使用這個產(chǎn)品？產(chǎn)品在不同設(shè)定或目的下會有什么表現(xiàn)？
• 消除：如果我們刪掉這一部分會怎么樣？
• 反轉(zhuǎn)：如果我們逆轉(zhuǎn)這一流程會怎么樣？

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

• 畫出具體的解決方法；
• 制作導(dǎo)航和站點地圖；
• 制作任務(wù)流程。

最后，為了確保整個設(shè)計方案沒有遺漏，請使用步驟 3 進行查漏補缺。

舉個例子，一個項目發(fā)現(xiàn) “社交媒體廣告和電子郵件對模板有需求”，基于這個描述開始提問和練習(xí)，并繪制出草圖。請記得，很多時候，我們的重點應(yīng)該完全放在產(chǎn)品以及核心流程上，而不是其他地方。

故事地圖

在這個時候，開展故事地圖討論會是有很有必要的，可以拆解想法并且確定 最小可行性產(chǎn)品（MVP：Minimal Viable Product），特別是在一個不斷迭代、敏捷開發(fā)的環(huán)境下。

作為一個用戶體驗設(shè)計師，請確?？捎眯圆粫艿絿乐赜绊?，可以允許少量干擾因素存在。一旦通過原型驗證了想法，根據(jù)團隊的工作模式，可以使用故事地圖來嘗試搭建最小可用產(chǎn)品（MUP：Minimal Usable Product）。

六、反饋和指導(dǎo)：測試、贊同、反對

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

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

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

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

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

七、建立原型：設(shè)計的末端

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

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

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

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

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

• UI 設(shè)計師；
• 視覺設(shè)計師；
• 文案；
• 設(shè)計資產(chǎn)管理者；
• 開發(fā)者(如果需要編碼）。

原型工具：

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

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

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

八、測試原型：面對考驗

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

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

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

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

• 介紹項目并且設(shè)定期望；
• 獲取參與者同意，提供獎勵作為感謝；
• 避免引導(dǎo)性問題，封閉性問題或者引入偏見，根據(jù)受眾使用不同的問題；
• 確定問題和任務(wù)的優(yōu)先級（最高優(yōu)先級到最低優(yōu)先級）；
• 避免在任務(wù)編寫和任務(wù)排序中摻雜偏見；
• 設(shè)定每個任務(wù)的目標和需要觀察的內(nèi)容；
• 如果缺少問題，在時間允許的情況下，可以進行更廣泛的研究（調(diào)查問卷、觀察筆記等）。

在進行測試之前，可以和同學(xué)進行模擬練習(xí)，這會幫助你發(fā)現(xiàn)腳本隱藏的問題，確保整個流程的時間是合適的。

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

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

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

• 凈推薦值（NPS）；
• 系統(tǒng)可用性量表（SUS）；
• 其他定量數(shù)據(jù)。

九、調(diào)研結(jié)果：獲得寶劍

調(diào)研產(chǎn)生的結(jié)果會通過不同形式回饋給設(shè)計師，比如問題、更多的知識和洞見，或者是設(shè)計上的驗證。

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

• 調(diào)研概述，調(diào)研總結(jié)（數(shù)據(jù)可視化、凈推薦值 NPS、系統(tǒng)可用性量表（SUS），或者其他內(nèi)容）；
• 哪些假設(shè)和問題得到印證和解釋（提供證據(jù)，更新知識庫）；
• 單個任務(wù)的統(tǒng)計信息（任務(wù)成功率、失敗率、任務(wù)時間）；
• 哪些環(huán)節(jié)進展順利；
• 哪些環(huán)節(jié)出現(xiàn)問題；
• 產(chǎn)品漏洞（如果已經(jīng)編碼）；
• 其他建議。

當(dāng)記錄這些調(diào)研結(jié)果的時候，確保：

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

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

十、繼續(xù)項目或者進行迭代：回去的路

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

設(shè)計是允許失敗的。

—— 精益 UX

根據(jù)調(diào)研結(jié)果，可以：

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

發(fā)起一個會議，向團隊成員展示調(diào)研、測試結(jié)果，以及更新后的原型，并提出下一階段的建議。

回到之前的步驟是一個很艱難的決定，也很難得到支持。更不幸的是，在設(shè)計沖刺階段，沒有足夠的時間支持后退。因此，需要通過調(diào)研結(jié)果來解釋后退的價值，從業(yè)務(wù)和用戶層面來說服決策者。

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

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

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

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

• 業(yè)務(wù)和項目目標；
• 支持目標的戰(zhàn)略和策略；
• 需要追蹤關(guān)注的 KPI；
• 需要追蹤關(guān)注的交互行為；
• 轉(zhuǎn)化漏斗；
• 第三方應(yīng)用程序（Hotjar, Google Analytics 等）；
• 宏觀目標和微觀目標；
• 創(chuàng)建一個追蹤任務(wù)，并讓開發(fā)團隊實行。

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

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

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

不要過分依賴質(zhì)量檢測團隊去發(fā)現(xiàn)設(shè)計以及可訪問性方面的問題。

十二、發(fā)布和分析：寶貴的經(jīng)驗

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

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

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

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

聽你說

這是一個動態(tài)的過程，以上提及的步驟會隨著時間的發(fā)展有所改變。UX 設(shè)計師需要具備多樣化的技能，來參與整個項目旅程。

毫無疑問的是，我一定遺漏了一些細節(jié)。我所描述的步驟和你的項目經(jīng)歷有相似之處嗎？你會因此改變哪些步驟？或者增加哪些內(nèi)容？我漏掉了什么？歡迎交流！

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

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

原文鏈接：https://uxdesign.cc/the-12-step-designers-journey-694de2568153

本文由@TCC翻譯情報局 翻譯發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于 CC0 協(xié)議