所有設計專案，應該在 Google 文件開始
大多數的設計師太快埋首於 UI 工具
新的設計專案開跑了，通常會發生哪些事情？
有可能是準備好啟動會議。為了盡量讓事情有效率，受邀名單小小的。有些人無法參加、腦力激盪出幾個點子。大多是少數幾個人之間在對話，其他人就只是聽著。有些人看一下通知訊息，專注力飄走了。幸好，有人在做筆記。會議結束後，設計師開始在 Figma 或 Sketch 消化每個人的願景，有可能還會參考一些產品來獲得靈感。設計師試了幾個角度，其中幾個存起來。沒參加到啟動會議的人，一星期後才晃進來，留下幾個回饋。你解釋：早就討論過那些相似的點子了。
就是這麼回事⋯
在這樣的專案流程，關係人沒什麼時間參與，壓力也都堆在熟悉設計工具™的人身上。
這種流程裡，設計師就像守門員
優秀的設計，很少是從單打獨鬥的天才產出的，而是廣泛納入設計師與非設計師的團隊。然而，不是每個人都懂得使用產品原型工具。
所以，如何邀請更多人參與設計探索？
所有設計專案，應該在 Google 文件開始
（或 Dropbox Paper 或 Zoho Writer 或任何一款你家使用的協作工具）
使用 Google 文件的功效：
- 降低進入門檻：使用 Google 文件的設計探索，可以讓比較多人參與。
- 比較容易大範圍灑網：打字很快，所以從各種角度探索點子也快。
- 專注在問題：人就是很難忽略圖片。每個人被限制在文字時，能夠保持專注，而不會被視覺或某些工法分心。
讓我們細說分明。
降低進入門檻
設計師不會是一直有最好點子的人。任何地方都會有優秀的點子：產品經理、業務、客服⋯等。問題就在不是每個人都知道如何使用設計軟體。設計應該是歡迎大家參與流程，而不是鎖起來、擋在外面。
Google 文件降低了進入門檻，每個人都在相同的條件進行腦力激盪。一開始就讓每個人都能有所表示，可以避免工作事項成為穀倉、納入不同觀點，最終打造出更好的產品。大家覺得自己是流程裡的一份子時，也產生熱情。
以 Google 文件開始，使得的工作事項在初始階段就得以互相交流，大家在任何階段都可以參與。非常適合分散式、跨時區的團隊。
盡早以團隊進行設計，避免之後成為少數決定的設計。
比較容易大範圍灑網
探索設計的時候，最好儘早大範圍灑網，納入考量的解決方案不設限。文字有這方面專長：快速地拆解問題、搭起潛在解決方案，充分討論使用情境。這時候的完整度，要做修改還很便宜。
畫圖和寫程式會花更多時間。太早這樣做的話，會落入不正確的細節規模，探索設計就慢下來了。每個人都發聲過、整個團隊開始聚焦在一兩個點子之後，技法會更有效。
專注在問題
人類是視覺動物。只要看過圖片，就很難忽略。會引發錨點誤差，也就是變得以最先看到的事情為基準。發生這狀況時，我們很難重整心智模式，發掘另一種方法。
如果過早以圖片著手，容易愛上手法，看不到問題。在最佳解決方案出現之前，討論就變成設計評論 (design critique) 了。文字沒有這種問題，因為易於拆解，快速前進。
限制在文字的時候，每個人都專於問題本身，還有因此被影響到的事情。
實作起來是什麼樣子？
在 Stack Overflow，每個專案開始時稱為功能規格。在 Dialpad，叫做產品總覽 (Product Review Descriptions)。遇到得花費一兩天以上的專案時，就會新增一份文件。通常，產品經理、研究員或設計師打好新文件草稿後，便邀請其他人填寫基本訊息。
文件還很隨性，結構和內容沒有嚴格規範。 通常包含：
- 背景與問題
- 目標、非目標
- 成功的模樣
- 研究
- 需求
- 設計點子
- 考慮過的替代方案
- 什麼情況會搞砸？
- 如何衡量成果？
- 值得一提的討論
我常常在聊天室貼上文件的連結，說：「大家，我們正在做這件事，如果有興趣的話，歡迎回饋」，接著用 @ 指名文件裡相關段落的團隊，問他們問題。
進入門檻降低了，團隊比較容易快速大範圍灑網。
我還會加上會議記錄和設計評論的回饋；放上最新版本的設計、相關專案的連結；讓大家都能看到已經討論過的總結相關對話記錄或電子郵件討論串，也不用四處打開留言討論串，尋找已經討論過的事情。
這份文件最後成為設計考據概要。任何人都能夠閱讀文件，瞭解問題、看到在專案期間裡，設計如何逐漸演化。
團隊已經將方向縮至一、兩個，而且已經想透核心使用者體驗後，我才會打開 Figma。每個人的步調可能不太一樣，但我覺得在視覺設計工具裡，探索是比較慢的。
結論
我非常喜歡過去幾年裡，如此的工作方式。團隊夥伴說：很前期就參與設計流程，令人覺得受到重視。部門之間的合作變好了，讓設計真正成為團隊運動。因為在流程中攔截到各式各樣的回饋意見，使得設計比以前更好。
你有類似的流程嗎？文件有些不同？希望可以跟大家交換筆記！請在 Twitter 標註我，或寄封信。
感謝 Vicky Cheng 在這篇文章初期草稿的回饋。