使用者體驗設計基本概念逐步指南。
本文介紹的工作流程可協助團隊、產品、新創公司和公司建立穩健且有意義的流程，為客戶打造更優質的使用者體驗。您可以單獨使用流程中的不同部分，但最好是將其視為一系列步驟。
本指南大量借鑑了設計衝刺方法，Google 的多個團隊都使用這種方法來排解及解決挑戰，例如自動駕駛汽車和 Project Loon。
雙鑽石
這項流程工作是以使用者體驗圈中稱為「雙鑽石」的概念為基礎，由英國設計委員會推廣。團隊會先發散思考，透過研究瞭解想法，然後收斂思考，定義挑戰，接著發散思考，各自草擬想法，分享想法，決定最佳前進方式，最後進行測試和驗證。
背景介紹
首先，請從手邊的根本挑戰著手，並像寫提案一樣寫下來，問自己：「我實際想解決的問題是什麼？」。挑戰陳述是您為專案設定的簡報，其中包含您的目標。
這項挑戰可能是針對需要改進的現有產品功能，或是全新的產品。無論任務為何，只要根據目標調整語言即可。這份聲明應與團隊目標相關、以目標對象為中心、鼓舞人心且簡明扼要。
這些是我過去參與過的產品實際案例。
設計一套系統，管理內翻足患者的治療和後續照護。
建立應用程式，簡化複雜的金融系統，並精簡至基本要素。
在不同平台上設計一致的行動應用程式，同時保有品牌特色。
更新挑戰聲明
寫出幾個不同的目標後，請向團隊展示，取得共識。建議您設定期限，協助團隊專注解決問題。因此，加上調整項後，上述清單可能會變成：
- 設計一套系統，管理 2 歲以下內翻足兒童的治療和後續照護，並在今年第 1 季推出。
- 建立簡單的財經應用程式，讓使用者只要輕觸按鈕，就能買賣股票，不需具備財經知識。這款應用程式於 2017 年 7 月首次推出。
- 在今年年底前，製作一份適用於多個平台的設計指南，並在每個平台上有效定位公司品牌。
完成挑戰陳述後，請將其放在顯眼的位置，以便在工作時看到。您需要經常參考這份文件，甚至可能需要在整個專案中更新或修改。
驗證問題
下一步是研究挑戰並瞭解問題。您需要瞭解的是，團隊對問題的理解是否正確。我們經常從自己的角度看待問題，但這很危險，因為科技業人士大多是進階使用者，實際上只占少數。我們是少數敢於發聲的人，可能會誤以為某件事是問題，但實際上並非如此。
收集資料來驗證挑戰的方法有很多種。每種方法都取決於您的團隊，以及您是否能存取使用者。目標是進一步瞭解手邊的問題。
與利害關係人進行內部訪談
訪談過程包括訪談貴公司的每位團隊成員和利害關係人，從行銷到帳戶。這有助於瞭解他們認為的實際挑戰和潛在解決方案。這裡所說的解決方案並非技術解決方案，而是公司或產品的最佳情況和最終目標。舉例來說，如果使用上述挑戰，「在年底前將我們的內翻足軟體推廣到 80% 的醫療機構」會是很好的目標。
不過，這種驗證方法最不受歡迎，因為它會阻礙團隊討論和協作，可能會在組織中造成孤立的氛圍。不過，這項方法仍可提供一些有關客戶和設計挑戰的實用資訊，否則您可能會錯過這些資訊。
短講
這與內部訪談類似，但這次您要將所有利害關係人聚集在同一個會議室。接著，請選出五或六位利害關係人 (行銷、銷售、設計、客戶、研究等) 進行簡報，每個人從自己的角度出發，針對挑戰進行最多 10 分鐘的簡報。簡報必須涵蓋的主題應為：
- 業務目標
- 從他們的角度來看，專案面臨的挑戰 (可能是技術、研究收集、設計創作等…)
- 目前的使用者研究
最後預留 5 分鐘供提問，並由指定人員全程記錄。完成後，建議您更新挑戰，反映新學到的知識。目標是收集一份項目符號清單，列出可推動功能或流程，協助您達成產品目標。
使用者訪談
這可能是瞭解使用者歷程、痛點和流程的最佳方式。安排至少五場使用者訪談，如果可以，請安排更多場。您可以詢問的問題包括：
- 他們如何完成現有工作？舉例來說，假設您想解決上述財經應用程式的問題，可以詢問他們「您目前如何購買股票和股份？」
- 他們喜歡這個流程的哪些方面？
- 他們不喜歡這項流程的哪些部分？
- 使用者目前使用哪些類似產品？
- 他們喜歡哪些產品或服務？
- 他們不喜歡什麼？
- 如果他們有魔法棒，可以改變這項流程中的一件事，會是什麼？
訪談的目的是讓使用者談談他們面臨的挑戰。這不是討論點，因此請盡可能保持安靜。即使使用者停止說話，也請務必稍等片刻，因為他們可能正在整理思緒。你會驚訝地發現，有人停頓幾秒後，還會繼續說很多話。
請全程記錄，並盡可能錄下對話內容，以免遺漏任何資訊。目的是將挑戰與收集到的使用者洞察資料進行比較。兩者是否一致？你是否學到任何有助於更新挑戰陳述的知識？
民族誌實地研究
您可以在實際情境中觀察使用者，例如他們如何購物、如何通勤上班、如何傳送簡訊等。但如果觀察使用者自行執行動作和任務，就能獲得深入分析。基本上，你只需觀察，不要干涉，並記下他們覺得容易或困難的部分，以及可能遺漏的事項。目標是融入使用者的環境，更深入瞭解他們的痛點。
這項技術通常需要較長時間才能完成，且需要研究人員主導這部分專案。但這可能是最能深入瞭解使用者的做法，因為您可以在自然環境中觀察研究對象。
統整所有資訊
完成專案的學習階段後，您需要最後一次檢視挑戰。您是否走在正確的道路上？有任何需要調整的地方嗎？寫下你學到的所有內容，並將其分類。視您要解決的問題而定，這些可能成為功能或流程的基礎。此外，您也可以使用這些資料更新及修訂挑戰。
收集到足夠的意見回饋和深入分析後，就可以運用這些知識建立專案藍圖。
專案地圖
您要解決的問題通常涉及不同類型的人員 (或參與者)，每個人都與專案流程息息相關。根據所學，您需要列出可能的參與者。這可以是使用者類型或利害關係人，例如「治療內翻足的醫生」、「內翻足患者」、「照顧患者的看護人員」等。請在紙張或白板 (如有) 的左側寫下每位參與者。在右側寫下每位玩家的目標。
最後，請寫下每位玩家達成目標所需的步數。舉例來說，如果是「治療內翻足的醫生」，目標就是「治癒內翻足患者」，因此步驟可能是「在系統中註冊患者」、「開始醫療計畫」、「建立醫療健康檢查週期」和「執行醫療程序」。
結果會是一張專案地圖，其中包含程序中的主要步驟。您可以將其視為專案的概覽，不含太多細節。團隊成員也能藉此判斷地圖是否符合挑戰聲明。稍後，當您細分每個步驟時，會有更多詳細資訊。但目前專案地圖可讓你大致瞭解使用者為達成最終目標而採取的步驟。
線框稿和分鏡腳本
瘋狂八分牌
我建議使用「瘋狂 8」方法，將一張紙折兩次，分成八個區塊。接著，根據目前為止學到的所有內容，在每個面板中畫出一個構想。請在十分鐘內，想出填滿八個面板的點子。如果給自己超過 20 分鐘的時間，你可能會開始拖延，去泡杯咖啡、查看電子郵件、與團隊閒聊，基本上就是避免工作。在這個步驟中，您需要營造急迫感，迫使自己快速且更有效率地工作。
如果你與團隊合作，請讓每個人都進行自己的測試。這個過程會啟動大腦，讓你開始思考挑戰。草圖通常是介面設計線框稿。
接著，您和團隊成員會向大家展示自己的構想。 每個人都必須詳細說明自己的八個構想，以及選擇特定方向的原因。提醒每位團隊成員，運用所學知識來佐證自己的構想。所有人發表完畢後，就可開始投票。每人有兩個圓點貼紙，可投給任何構想。如果真的很喜歡某個點子，可以將兩票都投給該點子。
修正設計
投票結束後，請根據票數最多的構想，繪製最終構想草圖。你也可以參考同事提出的其他構想。 請再花十分鐘完成這項工作。完成後，再次向團隊展示構想，並像之前一樣投票。
製作構想的分鏡腳本
設計完成後，就可以開始製作腳本，規劃與使用者的互動。此時，您應該已經思考過使用者會採取的不同步驟。在流程中加入同事的設計也很常見。您需要有明確的逐步流程，並在其中加入一些使用者可能分歧的點。請回頭查看專案地圖，確認設計是否符合目標。
建立原型
建立原型並非要打造完美的程式碼，而是要讓使用者覺得可信。每個人使用的原型設計工具不盡相同。有些人喜歡 Keynote 或 Powerpoint，因為這類工具會迫使你思考流程，而非設計細節。建議您花時間學習 Balsamiq、Marvel 或 Framer 等工具，以便進一步控管行為。無論使用哪種工具，請務必確保能讓你專注於流程，且看起來真實。您需要找真人測試原型，因此原型必須盡可能逼真，但同時也不應花費數週時間製作。
建立原型時，必須在時間和真實性之間取得平衡，因此請小心不要過度偏向任何一端。無論是哪種情況，都可能浪費時間。
對設計進行可用性測試
如果您有測試實驗室，那就太好了。如果沒有，只要注意為使用者打造舒適且不干擾的環境，建立一個並不困難。測試通常會由使用者和團隊中的兩位成員參與，其中一位負責記錄，另一位負責提問。建議您使用 Hangouts 等應用程式，並記錄他們的動作，如果您想讓其他團隊成員從其他房間觀察，這也相當方便。這對應用程式製作者來說可能相當可怕，因為我們會看到自己的設計在實際環境中運作。這會是令人耳目一新且發人深省的體驗。
問自己以下問題
測試設計時，請要求使用者在應用程式中執行工作，並請他們大聲說出正在執行的操作和原因。這聽起來有點奇怪，但有助於瞭解他們的想法。當他們遇到困難時，請盡量不要打斷或告訴他們該怎麼做。只要在他們完成 (或未完成) 流程後，詢問他們為什麼採取特定流程即可。
您需要瞭解：
- 他們喜歡原型的哪些部分？
- 他們不喜歡原型的哪些部分？
- 有哪些痛點？
- 為什麼流程能運作
- 流程為何無法運作
- 他們想改善哪些方面？
- 整體設計/流程是否符合他們的需求？
重新檢視設計並進行另一輪測試
您已根據意見回饋，建立可運作的原型。現在，請修改設計，並分析哪些做法有效，哪些無效。請放膽建立全新的線框圖腳本，並製作新的原型。從頭開始，比嘗試移動先前原型上的內容，更能創造更好的流程。請不要太過重視，因為這只是原型。
對設計感到滿意後，可以再次測試並進一步調整。如果原型完全不符合預期，您可能會認為專案失敗了。但實際上並非如此。與實際建構設計相比，您可能花費較少的開發時間，而且更瞭解使用者實際喜歡的內容。設計衝刺的理念是「要不成功，要不學到經驗」，因此如果構想未如預期，也不必太自責。
製作！
你已測試過自己的想法。使用者喜歡這些內容。相關人員從一開始就參與其中，因此會投入心力。現在可以開始製作了。現在，你應該清楚瞭解需要製作哪些內容，以及體驗的優先順序。在專案的每個里程碑，您可能需要進行可用性測試，協助驗證工作並確保進度符合預期。
在投入大量工作、時間和精力之前，請務必盡可能瞭解相關資訊，以免採用的解決方案不合適。
閱讀本文後，您應該對使用者體驗及其重要性有了基本認識。使用者體驗不應視為設計師或研究人員的角色。實際上，專案中的每個人都有責任，因此我建議在每個機會都參與。