每個人都有自己的優點和缺點，我的優點大家都知道，善於發現總結和傳播。對我來說最大的缺點是做決策，小到決定按鈕的位置、當下用什麼設計方法、大到決定需求是不是砍掉，對我來說都能糾結和躊躇好久。
初學設計時我也像很多人一樣，對設計流程和設計方法抱有過高的幻想，以爲按照流程執行採取固定的設計方法就能產出優秀的設計方案。
然而工作完全不是這樣，總會有突發的事情、中途介入的需求、需要敏捷處理的任務。根本不可能讓你真正從頭到尾執行一次標準的用戶體驗設計流程。
設計方法就更別說了，大家看看尼爾森可用性原則、各種法則定理，除了當作評審和彙報時讓自己顯得很專業，有誰會真的一板一眼的去落地使用？而且稍微琢磨一下，就發現很多法則定理互相矛盾，如果沒有因地制宜的去改造和確定優先級，直接去用結果就是邯鄲學步貽笑大方。
到底怎麼樣才能作出下一步的決策，讓設計往正確方向發展下去呢？
我相信不僅僅設計有這個問題，其他崗位和其他行業應該也會遇到類似的問題。本質上來說這都是——如何採取正確的策略達到目標的問題。
項目管理鐵三角
一次偶然的機會讀了幾章項目管理的書籍，提到：有明確目的，需要一定時間處理的一系列任務和活動，都可以稱之爲項目。很顯然，互聯網產品設計也符合該定義，也是一種項目。
在項目管理著名的鐵三角概念中：時間 + 成本 + 範圍 = 質量。項目管理的目標就是平衡這四個元素。
之所以說平衡是因爲任何一個改動，必然對另外的元素產生影響。例如增加需求讓項目的範圍增加，必然導致時間和成本的增加。如果爲了提前發版本縮減時間，又不願意投入更多開發資源，必然導致 BUG 增加，質量變差。
這四個元素始終處在動態平衡之中，我們不可能讓項目範圍大時間少成本低還質量好。
如果把我們接到的設計需求當作項目來看，那我們也要處理好四個元素。
例如剛開始參加工作的新人常犯的一個錯誤是把需求當作不可修改的聖旨，經常因爲一個緊急需求自己硬扛加班加點做，結果還因爲質量不達標而被責罰。這種時候就應該和需求方討論，要麼讓需求方決策增加時間要麼降低質量標準，或者縮減需求的範圍。
工作越久，接到的需求也越抽象模糊，從“設計一個體驗好的頁面”變成了“如何保證整個產品的體驗質量”。面對抽象的需求要明確好範圍，制定質量標準，規劃好時間並且申請相應的資源來做。
有經驗的團隊在項目管理上通過制定不同的項目設計流程來利於更快決策。例如大衆點評設計團隊將需求分爲 4 個級別，不同的級別採取不同的設計流程和評審方，設計師也有對應的職責。
項目管理知識幫助我們從整體來看待設計需求，過程中隨時決策調整範圍、時間和成本，來把控最終設計產出的質量。
決策思維
整體視角不能解決所有問題，設計過程中有很多具體細節的問題需要討論。
同事推薦我閱讀前 IBM 高級副總裁王嘉陵所著《決策思維》，用一個完整的思路來面對所有需要決策的具體問題。
《決策思維》道出了決策的本質：有目標有選擇纔有決策可做。如果資源是無限的，我們就可以用任何方式做任何想做的事情，而不需要做選擇。所以決策的本質是分配有限的資源達到目標。
作者依據 30 年來在 IBM 的成功事業爲基礎，提出決策內容高質量三個重點 （GPA）：
- G：目標（Goal）
- P：優先級（Priority）
- A：可選方案（Alternatives）
和決策過程的三個重點（ IPO）：
- I：信息（Information）
- P：人員（People）
- O：客觀推理（Objective Reasoning）
並將決策過程總結爲 10 個步驟：
- 隨時觀察時勢，評估商業形勢
- 確定長遠目標
- 釐清目前的優先級
- 提出多項可選方案
- 客觀推理可選方案帶來的結果
- 選擇帶來最佳結果的方案
- 制定實施、溝通、評估的計劃
- 溝通、實施
- 評估進展，並主動調整
- 慶賀進步，再優化
我將書中提到的決策重點內容和步驟繪製成如下圖示。
如果把提出多個可選方案當作發散，決策最佳的方案當作聚焦。我們就發現這個圖示和設計思維、雙鑽模型很像。
可能成功的方法底層原理都是相通的吧。
這套方法看起來簡明，但實際操作起來卻很難。我認爲最難的步驟在於收集信息。如果沒有收集到足夠多的信息，我們不知道現狀、目標，更無法提出多個可供使用的解決方案。而客觀推理就更難了，要以當前的現狀推測執行方案之後可能帶來的結果，我們又不是哆啦 A 夢能乘坐時光機穿越未來，怎麼能提前推斷未知的結果呢。
最小可行產品
只要我們有足夠的時間，進行各種調研，請教各種專家，我們當然能更好地推斷方案帶來的結果。然而時間不等人，等你推斷出方案的結果時，市場早已變化。過去的方案已經不適用了。
既然市場瞬息萬變，漫長調研不如先推出半成品到市場上看看用戶反饋再改進，就是互聯網公司普通採用的快速迭代方法。該方法來自於埃裏克·萊斯於 2012年所著的《精益創業》中提到的「最小可行性產品」（MVP，Minimum Viable Product）。
我們根據當前收集到的信息提出假設，並依據假設快速開發出最小可行性產品投入市場，接下來我們根據數據和用戶反饋驗證當初的假設是否成立。
如果成立那說明自己推斷是正確的，繼續按計劃執行。如果錯誤，則反思提出新的假設再繼續開發驗證。簡而言之就是投石問路、摸着石頭過河。
爲什麼要依據收集的信息提出假設？因爲我們不知道收集的信息是事實還是觀點。用戶有出行的需求這是事實，事實是已經發生或已知存在的信息。用戶希望有更快的馬滿足出行速度的需求就是觀點，而觀點是個人主觀的判斷，可能是對的也可能是錯的。直接使用未經證實的觀點來設計產品，可能導致最終結果出錯。
爲了驗證觀點是否正確，我們才採用最小可行性產品來快速驗證。但使用該方法又會進入另外一個誤區——提出假設後馬上一拍腦袋開發產品進行驗證。
之所以開發最小可行產品是因爲這樣耗費的時間和資源最少，用最少的資源拿到結論纔是目的。很多時候開發並不是成本最小的方式，我們可以用其他更快更實惠的方式拿到結論。
例如要驗證用戶是否更喜歡深色模式界面，我們確實得開發出深色模式的版本再觀察用戶的使用率。但如果只是驗證用戶是否晚上經常使用 App，通過後臺數據查詢晚上的活躍用戶比例或者給用戶發放問卷，驗證假設的速度比開發產品快得多。
設計方法的四要素
既然最小可行性產品不一定是最有效率和最實惠的方法，那現在決策的重點就是如何採取成本最低效率最高的方法來達到目的。爲此我們必須梳理所有設計方法，整理歸類，遇到問題時，才能快速決策使用最佳方法。
我將方法用 4 個維度來梳理：
- 輸入：使用某方法的前提。比如可用性測試，必須有至少 5 個用戶和產品的高保真原型或已開發成行的程序。
- 輸出：使用方法得到的結果。例如可用性測試做完能得到用戶使用產品的行爲，以及可用性問題。
- 成本：使用方法消耗的資源。例如可用性測試短從用戶邀約到測試，得消耗 2-3 天，成本高。而調研問卷發放到結論一個下午不到，成本低。
- 類型：分爲表達、結論、發散這 3 種屬性。比如用戶體驗地圖能向大家展示當前用戶痛點。有些方法是爲了梳理得出明確的結論，例如流程設計。還有方法是爲了發散找到更多的可選方案，比如頭腦風暴。一個方法可以有多個屬性。
就像看到釘子拿起錘子，看到螺絲找螺絲刀。爲了達成目標而決策使用哪個方法前，可以先看看現狀符合哪個方法的輸入條件。再想想哪個方法的輸出和類型與自己希望達成的目標相同。思考一下現階段能付出的成本，最後作出決策。
考慮設計之外的方法
設計並不是解決問題的唯一方式，有時候設計之外的方式有奇效。例如爲了禁止用戶做某事，與其把警告文案做得再大，不如通過運營制定策略，給予用戶懲罰來得有效。
總結
通過以上閱讀和思考，我目前梳理的設計決策思路如下：
- 把設計當作項目，動態地調節範圍、時間、成本和質量。
- 收集信息，確定現狀和目標。
- 區分信息中的事實和觀點，決策最佳方法（包括設計方法和非設計方法）驗證觀點對錯，獲得新的事實。
- 根據當前事實評估與目標的距離，再提出新的觀點進行驗證。
以上思路還比較粗淺，之後有更系統的思路再和大家寫文分享。