[大衛選讀] 每次做設計提案，要寫體驗設計原則 (Design Principles) 時，設計師總會傷透腦筋，因為怎麼寫都是那幾個：「簡潔俐落、架構分明、隨心懂你」之類的。
PM 看了點點頭，客戶看了也覺得挺有道理的，但大家心裡都清楚，這些原則在遇到真正的問題時，就會顯得毫無用處。當 PM 跟設計師對某個功能吵了起來，沒有人會說「等等，讓我看看設計原則是怎麼講的」。
尤其在 AI 大量生成的狀況下，設計原則講屁話的情況就更常見了。叫 AI 幫你寫一版設計原則？它三秒鐘就能吐出一份看起來無懈可擊、但其實什麼都沒說的東西。
說實在的，我自己也寫過這種東西。帶團隊的時候常常會開個工作坊、搜集便利貼、濃縮出 3-5 條聽起來很專業的設計策略方向。結果呢？這些共識下寫出來的文字，從來沒在後續真正困難的設計決策中，幫上過什麼忙。
後來我才想通：問題不在於團隊不認真，而在於那些原則從一開始就「不敢做取捨」。
好的設計原則，本質上不是在宣告我們重視什麼，而是一份「犧牲聲明, Sacrifice Statement」：為了達成設計目標，我們願意放棄些什麼？
接下來談談，怎樣才是一份好的設計原則。
原則一：如果反過來說就沒人要支持，那它就不是有用的設計原則
怎麼判斷一條設計原則好不好？有一個很簡單的方法：把它反過來說。
「介面要簡潔」，反過來就是「介面要複雜」。有人會主張這個嗎？沒有。所以這不是設計原則，徹徹底底是一句廢話。
好的原則不是告訴你什麼是對的，而是在兩個都不錯的選項之間，幫助你更好地選邊站。它的核心功能是協助團隊，在面對「取捨, tradeoff」時，能做出一致有共識的選擇。
來看一個好的例子。Intercom 的設計原則之一是「有預設的立場，但底層保持彈性, Opinionated by default, flexible under the hood」。
反面是什麼？「不預設立場，讓使用者自己決定一切」，這恰恰是很多時候，看起來不會犯大錯的設計方向。
Intercom 這個設計原則等於公開宣告：我們寧可先替使用者做好選擇，即使某些進階用戶會覺得被限制了，也在所不惜。
這就是真正的取捨。他們自己也承認，早期產品曾經做得「太彈性」，結果客戶反而不知道怎麼上手，後來才回頭加入更多所謂「有立場的預設行為」。
我覺得這裡有一個很實用的思考起點：別從腦力激盪開始，而是從你們團隊重複爭論的議題開始。那些吵了又吵、好像永遠吵不完的問題，才是需要設計原則來一錘定音的地方。
換句話說，好的設計原則往往不是從「我們希望成為什麼」往後延伸的，而是從「我們老是在哪裡卡住」開始思考的。
原則二：必須是從研究裡長出來，而不是在會議室裡投票出來的
第二件我常提醒團隊的事：好的設計原則必須「從研究發現中長出來」。得要深刻反映目標用戶在這個產品脈絡下的真實需求，而不是通用的設計教科書。
英國政府數位服務團隊 (GDS) 的設計原則就是個好例子。其中一條「這是給所有人的, This is for everyone」，聽起來像政治正確的口號；但在他們的脈絡裡，這是一個真正的犧牲聲明。
設計原則中進一步提到，如果無障礙設計跟美觀衝突時：「如果必須犧牲優雅，那就犧牲吧, If we have to sacrifice elegance – so be it.」
不得不說，政府的設計原則能這樣寫，真的很帥。
帥氣的背後，當中的研究發現是：最需要政府數位服務的人（像是簽證申請、福利計算等），往往是最不擅長使用網路的人。對他們來說，美感不是重點，能不能上手使用才是最重要的。
於是，GDS 的團隊把簽證查詢做成了互動式問答，把福利計算做成了步驟引導，都是這條原則的具體展現。
相對的，太多團隊的設計原則是在某個下午的工作坊裡，用便利貼投票產生的。大家寫下覺得重要的詞，貼到牆上，投票選出最受歡迎的。問題是，這個過程選出來的是「最沒爭議的共識」，而不是「最能指導決策的觀點」。
所以我的看法是：所有的設計決策，包括設計原則本身，都應該有研究脈絡支撐。
那些沒有實證研究的設計原則，只是在拍腦袋、玩文字遊戲。遇到爭論時，很快就會縮回去了。
原則三：設計原則應該是「裁判」，而不是「啦啦隊」
第三件事，也是最實用的：好的設計原則要能在具體的設計決策中，擔任起裁判的角色。
我自己帶團隊的經驗是：流程可以告訴你「步驟」，但是原則才能告訴你「方向」。當你做產品設計，遇到原本流程中沒有覆蓋到的情境時，好的原則會讓你有信心，能大膽做決定。
Amazon 的 16 條領導原則 (Leadership Principles) 是另一個經典案例。前高階主管 Doug Herrington 最近在 Fortune 的訪談中坦言，他一開始覺得那些原則「像邪教一樣」；但後來他發現，真正的價值在於：當十幾萬人需要做出一致的決策，原則就是最高效的對齊工具。
他形容這套原則讓整間公司「朝同一個方向划槳前進」，因為每個人的出發點一樣，摩擦力就會少很多。
這在小團隊裡可能感受不深，但只要你的產品團隊超過十個人、或是同時有好幾個小組在開發不同功能，對齊的問題就會指數級放大。
沒有原則的團隊，每次遇到分歧就得開會討論，而且常常是同一場討論反覆上演。有原則的團隊呢？很多決策可以直接在小組內解決，因為大家有共同的判斷依據。
關鍵在這裡：設計原則要能當裁判，意味著它必須能在兩個人意見不同的時候，給出明確方向。
舉個例，當 PM 說「加一個功能入口讓使用者更容易發現新功能」，設計師卻認為「加了畫面會變複雜」的時候，那該怎麼辦？
如果原則是「保持簡潔」，兩邊都能拿它來支持自己的論點。但如果原則是「優先確保核心任務的流暢度，而非探索新功能」，那馬上就能做出裁判結論了。
結語：好的原則不用怕太強烈，重點是有沒有脈絡
最後想聊一個我們常遇到的心理障礙：很多人寫設計原則的時候會怕「講太死」，擔心太有立場會綁住團隊的手腳。但我覺得剛好相反。不敢表態把話講清楚，才是真正在浪費大家的時間。
舉一個經典的例子。德國傳奇工業設計師 Dieter Rams 在 1970 年代提出「好設計的十個原則」。放在今天看，像是「好設計是誠實的」、「好設計是有美感的」，這聽起來根本沒什麼殺傷力，誰會反對呢？
但在那個年代，消費電子產品充斥著各種花俏的裝飾，Rams 說出「少，但更好」是需要勇氣的。他等於在說：我願意犧牲那些看起來很厲害的細節，去換取產品的本質價值。放在那個時代脈絡裡，這就是一個強烈的犧牲聲明。
所以重點不是原則寫得多強烈，而是它有沒有紮根在你自己產品服務的脈絡裡。
在寫設計原則時，可以試著問自己三個問題：這個原則有清楚的立場嗎？它是從研究裡長出來的嗎？它能在兩難的時候當裁判嗎？
如果三個都能點頭，那就大膽寫下去，不用怕它太尖銳。真正好的設計原則，讀起來本來就應該讓某些人覺得不太舒服。
因為它正在替你的團隊做一個，別人不敢做的決定。
回頭看，我們以前寫的那些「簡潔、一致、以人為本」的設計原則，還真的是一堆屁話。問題不是寫得不正確，而是寫得太安全了。它們誰都不得罪，所以也誰都幫不了。
如果能重來一次，我肯定會從團隊裡最常吵架的那個問題開始寫起 (呵呵)
