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