Design Matter, Speed Matters.
Lean UX 精實設計開發(下)
Google Ventures says " The Design Sprint gives teams a shortcut to learning without build and lunching."
專注於功能不如專注於我們試圖創造的價值，直到找到能夠實現價值的解決方案。我們的目標不是創造產出或功能，而是成果。
傳統的軟體專案是由需求和產出所構成，先將需求提交給團隊，然後請團隊為產出制定能滿足需求的功能項目以及完成的方法。在多數的情況下，團隊並不會特別溝通或考慮這些需求的背景與原因，甚至直接忽略整體策略。
為了降低在錯誤的功能，設計和工程實作上過度投資所帶來的風險，必須軟化自己的立場，從堅持甚麼是必要的設計轉變為驗證甚麼假設條件才是真的。
往往我們都會忽略假設，甚至把假設當作為真實的需求，無形中創造出很多虛無的痛點，而團隊又針對它開發出了沒有價值的雞肋功能。
研究是模式化的好奇心，是有目的投石問路 — Zora Neale Hurston
假設
假設是根據我們目前所膫解的知識而做出的最佳推測。所以假設充滿風險，然而，沒有證據確認假設的正確性之前，這些敘述都只能視為充滿風險的假設。如果我們又根據這些未經測試的假設來進行每個決策，就會增加產品失敗的風險。所以當我們發現一項假設時，需要自問，如何盡快確保這些敘述的正確性，讓握來決策能立足於更好的成功機會之上。
假設：四個關鍵問題
- 業務成果 : 對成功的標準與完成的定義
- 用戶：通常被建模為人物角色
- 用戶成果：即用戶目標，用戶想達成任務
- 功能 : 該功能是否能夠滿足用戶的需求
協作式設計
在生命歷程中，我們應該對協作持開放心態，去結識優秀的人，因為他人的主意經常會勝過自己的觀點，找到一群對充滿挑戰與啟迪的人，多和他們接觸，你的人生也會隨之改變 — Amy Poehler
從各自為政轉變為協作
在多數的公司裡，你所做的工作是根據你的職位名稱。組織中往往不鼓勵其他人做份內之外的工作。這種方式是深刻地反對協作，不鼓勵跨職能協作，就是變相鼓勵組織間壁壘分明。一個人的工作越明確，就越容易退縮到該領域的安全範圍內。結果，跨領域的對話逐漸消失，不信任、相互指責和自我保護的行為逐漸增長。壁壘分明的組織會致使協作行團隊走向死亡。
擁抱新技能
多數公司只要求設計師建立線框、規格和網站地圖。不論公司使用的流程為何，他們都限制設計師只參與專案的設計階段。在現有流程裡找機會安插設計師，限制他們的工作範圍，連帶也限制了他們的效能，所帶來的副作用就是強化孤立團隊模式。
設計體系的價值
設計體系是Lean UX的有利推動者。設計體系使得設計的視覺和微交互細節可以與其他設計決策同步開發和維護。這樣做有兩個好處：
- 設計的更快，因為不必每次設計都重新來過。
- 更快地做出原型，因為前端設計師使用成套的組件工具進行開發，他們並不需要每個方案開發不同元素，而是從設計體系拿出合適的組件直接使用。
整合精實UX與敏捷開發，參與會給你協調的能力，爭取你進行工作所需的時間，這不僅是針對UX設計師，團隊的其他成員也需要。產品經理需提供產品價值、設計負責人確保產品可用性、開發負責人完成產品可行性。
最小可行產品與原型(minimum viable product, MVP)
生活就是一場實驗，實驗次數越多，生活就會越好 — Amy Poehler
MVP 主要是為了獲取認知，盡早創造市場價值、關於創建大多數情況下，答案要麼關於價值，要麼關於效果。我們可以使用按照優先排序的一系列假設來對以上問題進行多角度的探索。MVP，最首要問題是：我們接下來需要了解的關鍵問題是甚麼？
1. 最關鍵的問題
2. 解決方案的風險
3. 最小工作量
創建MVP以理解價值
如果你正嘗試創建MVP來理解想法的價值，應遵循如下指南。
- 簡明扼要
- 使用清晰的Action Call — 有方法能夠知道用戶為甚麼使用以及離開
- 無情地排列（不需一次到位，清楚拆分衝刺）
- 保持敏捷
- 驗證想法可以透過運用身邊的工具
- 評估行為 — 實際行動
- 與用戶交流 — 用戶做甚麼、為甚麼做
要記住，MVP是一個增進認知的工具，會不斷迭代，甚至可能將其全拋開。
