“觀察現況, 提出假說, 執行實驗, 進行驗證, 調整假說” 這個基礎方法論相通於創業, 設計, 或是創新行為，甚至也是研究所與更往上高等教育的基礎課程。不管在中國或是台灣，用戶體驗設計行業都是高度聚集擁有碩士學歷的專家群，理當對這套方法並不陌生，在中國跟美國矽谷，這套方法叫做 ”迭代 (iteration)” ，但有趣的是在中國的互連網行業常常因為週期過短的迭代頻次導致沒有辦法正確的總結，而台灣的行業，這套方法論卻連在臨床實踐中都消失無蹤。
設計是一場大規模實驗。
這種氛圍對於在互連網行業從業的朋友們與正在組織裡面轉型的設計團隊來說，想必都感到親切而不陌生，在中國的行業內更接地氣的說這叫做 ”摸著石頭過河”，在美國矽谷則是更廣為人知的 “Fail fast, Learn fast”，而中美兩邊的企業鼓勵團隊直面體驗失敗的關鍵原因，是為了得到實驗後的總結，累積團隊的實戰經驗值，而不是只在紙上操兵。
遺憾的是國外的經驗在台灣實踐多半是相反的，長期觀察相對保守的台灣，產業從上至下都是比較害怕失敗的，一點點的瑕疵或失誤都必須要”有人被檢討, 被懲處, 被解決”，然後讓旁觀者圖得痛快，另外，產業內的從業人員對於幾個流行的方法論與案例觀摩可謂熟稔，然而真正實踐過的卻沒幾個。從幾個禮拜前沸沸揚揚的字型募資事件就是一個很好的案例。
台灣的行業普遍唾棄抄襲，但多數人只著眼在道德瑕疵上，但很少人能夠理解更重要的原因是因為最終的成功並不能被複製。馬雲也不只一次的在外宣講要從失敗中學習，甚至在杭州成立了湖畔大學，專以失敗案例分析與檢討。
那麼要怎麼學習正確的犯錯？可以想像這個過程像是在打靶，而迭代的過程就是在訓練經驗值，一次又一次的學習收斂技能，以便於能夠用最有效率的週期正中靶心。因此，觀察現況與了解用戶是不可輕忽的第一步，因為透過客觀的認識你的潛在用戶，可以幫助你與你的團隊在下一步：去設立方向不會偏差太多的假說。然後第三步：進行發散-混合-收斂的過程去探索所有可能的設計，並且在這個階段基於假說，建立最終可以被衡量設計好壞的目標。第四步：挑選出設計探索的結果，使用低保真/高保真的原型，帶給你的潛在用戶試用，並且在這個階段與用戶一起設計，並且蒐集他們對於現階段設計的反饋，而最後一步，就是帶著這些用戶的反饋與建議，回頭衡量這階段的設計與假說，然後再度回到步驟一。
協作的過程最重要的是：永遠要記得做得要比說得多，能先動手隨時記錄下來的就不要先動嘴，以便於保留每個想法，不致於讓這些反饋揮發在空氣中被遺忘，另外，值得注意的是每兩個步驟之間都可能需要反覆的操作。
在現今的 IBM Design Studios 的驅動下， 這套基礎的犯錯方法論也在 IBM 的產品與解決方案大規模的實踐。我們會在流程中不同的階段訂定的檢驗節點，以確保團隊中所有的夥伴都能夠被對齊(align)，所以我們在了解用戶之後，與開始進行設計探索之間，會先進行設計目標的定義，在完成設計探索之後，與執行原型設計之前，我們會進行設計方案的評審，以及我們在進行設計驗證的過程，會邀請潛在客戶來參與加入我們的設計流程。
最後要提到在實際應用時，以產品開發為導向的過程，很容易面臨與方案開發的過程有異同之處。
產品開發的問題常常在 in house 為主的甲方公司遭遇，很容易因為過少的用戶的定義，而將設計方向限縮的比較狹窄，導致未來產品在 scale up 的時候面臨 ”阿! 當初沒想清楚阿” 的窘境。此時的建議是要隨時把用戶角色分類疏理細緻，看看是不是有遺漏的用戶旅程或是用戶角色，並且再次微調目標方針，如果再怎麼樣也想不到，不要糾結，先往前走，在驗證環節請潛在用戶參與設計，藉此進行微調，當然別忘了永遠要設定可以被衡量的設計目標。
方案開發的問題常常發生在 agency 為主的乙方公司，也就是意見v.s.意見( Opion vs Opion)，導致各方爭執不休而無形中浪費的不少時間，而讓有時間壓力的 agency 面臨巨大的壓力。面臨這種情況的建議也很類似：如果意見來自於該方案的唯一客戶(金流)，或是一個怎麼樣也不能忽視的客戶(長期合作關係)，別糾結，先讓客戶選了算，然後記錄下來，一樣在驗證環節請潛在用戶參與設計，藉此進行微調，同樣別忘了永遠要設定可以被衡量的設計目標。
設計正是一場大規模實驗，市場就是你的試驗場，最終留下來最重要的就是經驗的總結與分享，讓過去團隊踩過一個一個的坑，能夠真正有效的轉化為寶貴的資訊與學習材料，如此我們才能不停的站在巨人的肩膀上，繼續在行業的前端戰鬥。
Next Article 別管創業了，先來看看「原始生活二十一天」吧！