Design Thinking的適用性思考

接觸到越來越多的DT，一直在體會與既往的諮詢方法的差異點和優缺點，剛翻出來DT過程的文件，掃了一遍，有了點新的感悟。

我是做SAP出身的，所以，今天突然get到一點，DT和我原來所熟知的SAP諮詢方法體系的基本差異在所謂“未知性”上。

做SAP ERP，通常透過使用者調研，瞭解as-is後，我們就可以給出to-be是什麼了，以及gap是什麼，提升點在哪裡。因為我們講的是最佳實踐，基於SAP的業務流程體系和管理方案，我們知道應該的未來是怎麼樣的。所以，我們不會把過多的重心放在跟使用者聊，激發與啟用他們的思考，讓他們逐步形成需求。

但DT所解決的，或者說所適用的場景，是面向未知。我沒有最佳實踐，你也不知道你要什麼，這時候不光需要乙方的腦力激盪，更需要的是甲方的腦力激盪，那麼好，我們用一種形式化的方法和正規化化的工具，來激發和啟用大家，透過共創，定義出來我們的所要尋找的方向。這也就是DT的中文名字為什麼通常被叫做設計思維“創新”工作坊的原因吧。

那麼，在這種模式下，我們怎麼應用DT方法呢？原來的方法體系扔掉？顯然不是，那肯定是要適時適度結合的了。問題是怎麼適時，怎麼適度，怎麼結合？

第一，面對未知時才考慮DT。如果一個專案是打著最佳實踐的招牌，請不要再高舉DT的招牌，否則這就是個自我矛盾的故事。如果面對甲乙雙方都可以坦然承認，特別是乙方承認，且甲方認可：“我不知道應該如何，我們可以一起去創造”的場景時，這就是適當的時候了。我乙方雖然不知道目標所在，但我知道去到目標的方法，讓我帶著你上路吧。

第二，2B專案，有的時候可以把DT當做一塊乳酪。DT的最常見應用場景是2C領域：面向消費者，專案雙方都不是消費者本主，ok，我們來觀察，然後頭腦風暴，形成對消費者及其心理和行為的認知，從而指導產品的設計。2B領域裡，使用者就是甲方自己，甲方很清楚知道自己的工作流程和內容，那麼在專案開始階段，就不要一開始就引入DT。試想一下，DT是要糾集一堆人，分組討論，每個組都畫一遍同樣的現狀流程，有意義麼？所以，最起碼初版的as-is就應該用傳統的方式做就好，找一兩個關鍵使用者，把基本流程講清楚就可以了。然後，如果沒有最佳實踐，那麼從as-is到to-be的過程中，要抓哪些重點，這些重點的關鍵改進方向是什麼，群策群力的形式化方法和做說想感的正規化化工具就體現出其價值了，這時候DT就可以閃亮登場了。這裡面要注意兩點，一點好，一點不好，應該說是一個可能的副作用。

• 傳統模式下，我們講的是流程，DT模式下，我們講的是使用者體驗，是以使用者為中心的使用者旅程，旅程也是流程，但此流程非彼流程。這裡的主視角不再是完整的工作流程，包含著多個相互協作的角色，而是限定在某個主人公身上，他的所做所思所感所想，這時候，甲方參與人員從被動的被訪談者，變成了舞臺中心的主角，大家圍繞著他，關心他，期待他，他逐漸放開了自己，變得侃侃而談，能說會道的他，看到他的一個個訴求被傾聽和認可，感覺好極了。這是好的一面，DT激發了使用者的活性，參與感、責任心有了明顯增強，多個使用者之間很可能還會捲起來。

• 副作用麼，則是，在甲方的滔滔不絕下，可能會得到大量的需求點，但由於體驗者多為一線的人員，其視角受限，往往會陷入過於個人化、過於細節的境地，更壞的是，囿於既有的井口，想的都是怎麼做井裡的精裝修，而很少考慮擴建、改建甚至打破這口井。

這個問題是尤為需要注意的，解決辦法有二。第一，要配備資深的顧問，有經驗有高度的顧問才有能力做適當引導。第二，專案經理或顧問組長要及時review各小組的成果，不要關注量，不需關注有多少需求點出來，而是要關注質，特別關注有多少高價值點需求，每個小組都必須要有三到五個關鍵提升點。第一輪，或者第一天下來，就應該有一些了，如果沒有，就需要覆盤了。

再往後，也不是to-be藍圖就有了，DT只是給了關鍵方向和點狀主線，藍圖還是需要回到傳統方法，細細的一點點討論，形成完整的描繪。當然，這時候按照現時流行的方法，可以agile化，細化一點，做一點，不斷迭代推進。