本篇文章是 〈關於 UX 設計的初學者教程：1. 如何像 UX 設計師一樣思考〉 的下半部份，如果你還沒有看過上篇，建議你先到這裡從上半部分開始閱讀。
確定限制條件
質疑這個問題有助於我們決定是否應該設計一個解決方案。形式化我們的約束有助於我們決定如何設計解決方案。
通常會遇到這些類型的約束：
- 時機 - 在當今精益與敏捷的世界中，每個公司都希望能夠快速地運送好產品。了解是否需要通過不可協商的日期發布您的 MVP（例如您的公司花費 $ 58,000 贊助的全球技術會議）
- 技術 - 開發團隊如何編寫代碼，以便您的系統的響應時間感到即時？您的服務器是否支持足夠的帶寬來實時快速地提供數據？數據中心的位置是否會影響某些地區的體驗質量？
- 媒介 - 用戶對您的產品類型有什麼期望？目前的心智模式和用戶界面模式是什麼產品 需要納入？
- 預算 - 公司為該項目預留了多少資金，以及在出現不可預見的問題或挑戰的情況下可以延伸多少錢？ 在你的提問後，進行徹底的利益相關者的討論，以便盡可能早地揭示任何隱藏的約束條件。
為解決方案收集上下文
一旦你確定了最初的約束，你需要驗證這些假設。此時，您將開始進行用戶研究，優先考慮要求和原型概念。
1. 用戶研究
最具成本效益的生成研究方法是用戶訪問。您可以在辦公室，通過 Skype，甚至在用戶的位置（上下文詢問）進行更好的觀察
自然使用案例。
當面試用戶時，您的目標是探索整個體驗的範圍 - 而不僅僅是焦點的直接領域。例如，如果你想創建一個 Netflix 的競爭對手，不要只是告訴人們他們目前如何使用 Netflix。與他們談談他們使用的其他服務 - 合法或非法。他們在哪裡觀看劇集或電影？他們使用什麼設備？他們下載或流？為什麼？
詢問大量關於用戶行為（而不是用戶意見）的開放式問題，然後暫停答案。因為最好的見解有時會出現，所以不要擔心面試稍微偏離主題從切線。
2. 優先考慮要求
完成用戶訪談後，您需要查看答案並開始識別模式。根據任何現有的定量數據（例如應用內分析）檢查這些模式。在定義要求時，設計師和利益相關者通常會根據設計約束條件對定性數據和定量數據進行評估，並使用 2x2 矩陣進行優先級排序。
3. 原型 MVP
最小可行產品代表驗證假設所需的最少努力量。 不要混淆一個 MVP 的不完整或匆忙的產品。 你的目標是盡可能在最小的範圍內創建完整的東西。
在第一個 MVP 上工作時，注意將 2×2 矩陣的 “Quick Wins” 和 “Big Projects” 象限的項目合併在一起。 丟棄右下象限中的所有項目，並將左下象限中的所有項目移動到待辦事項中。
您可能會開始勾畫 MVP，然後進入數字平台創建一個數字樣機。 它不需要漂亮，但它必須運行足夠好，以測試用戶。如果 MVP 原型忠實地執行了提供 80％價值的 20％功能，那麼您就處於正確的軌道。 只有在您測試其他假設時（例如，如果您的品牌顏色影響可用性），才會提高保真度。
結論
永遠不要以為你知道所有的答案。
在測試 MVP 原型時，您可能會發現其他用戶需求，並需要重新調整需求的優先級。 不要驚慌 - 設計從來不是一個線性過程。雖然每個設計師的個體過程都不相同，但他們都遵循相同的思維框架：對問題提出質疑，通過用戶研究獲得上下文，並且建立恰到好處的驗證現有假設並揭示新的需求。
在下一章中，我們將詳細介紹活動和交付成果，幫助推動決策，因為設計師從揭示問題到完善解決方案都可以取得進展。
