如何建立設計系統，然後失敗。
這是一篇關於設計系統的失敗經驗的分享。內容裡並沒有扭轉局面然後最後成功的情節，如果喜歡喜劇結尾的讀者可能要失望了。
但如果你跟我一樣是喜歡幸災樂禍的正常人，那可能會覺得有趣。
故事背景
我的公司是一間專做印度市場的線上旅遊公司，目前總部約有一百五十位員工。在這個悲劇發生時，產品部門總共分成三個小組：UI（四人）、UX（三人，包含我本人）、產品經理（五人）。
我們的產品橫跨各種裝置，並且已經上線有兩年的時間。
所有悲劇都有一個美好的開頭
時間是2019年年中，我正結束一個中大型的項目，並正要開始另一個中大型的項目。
在剛進公司就被委以重任，並且獲得廣泛認可的我，認為我們應該要開始進行設計流程的重整。會有這樣的想法除了因為公司的產品確實需要一致性的規範，我也認為無所不能的自己，可以也應該帶領這樣結構性的工程(真是蠢斃了)。
我很快的做了基本的資料搜集，研讀了Material Design的整份文件。同時，致電給在Oppo擔任高級設計經理的哥哥，徵詢他建構設計系統的經驗。
在接下來的一個禮拜內，我徵得了主管的認可，找了UI設計師、工程師們開了第一次的設計系統的Kick-off meeting。向他們推廣設計系統的優點，並且把自己對建構設計系統的想法、預設的時程向他們熱情的分享。
大家點著頭點著頭、原則性的同意我所說的，會議就這樣在我的樂觀情緒下結束了。
問題漸漸浮現，但被刻意忽略
團隊裡有四個設計師，我請他們做的第一件事，就是整理出我們產品中的各個使用得到的組件清單 — 我的想法很簡單：先整理出一個全面的清單，再依據重要性決定設計的優先順序，接下來進行開發、維護。
一個禮拜之後，我請他們交出所整理的組件清單，卻發現清單的內容粗淺、組件的分組方式不合理，不適合作為項目的規劃依據。
設計師們表示他們並不了解組件清單應該包含的內容，因此只憑藉直覺與經驗輸出了這份清單。我接著問他們是否有去瞭解過主流的設計系統，怎麼對組件進行規劃分組、是否了解原子設計理論，最後卻得到不置可否的答案（就是沒有，但不好意思說）。
「沒有關係吧，這只是一個小挫敗，項目開始的時候都會這樣的，大不了清單自己列。」我想。於是我花了一些時間把清單完善，然後開始規劃執行的計畫。
船到橋頭，才不會自然直
一個多月之後，我們還在沒完成第一階段的設計。
到了設計交付的那一天，我滿懷期待的招集了部門，希望進行一次盛大的發表。這一次的交付內容主要包含了顏色系統與字體系統的設計。
意料之外的是，本應充滿掌聲與激勵的初次發表換來的卻是滿場的沈默。
在顏色部分，設計師列舉了目前使用的品牌色，但卻沒有給出將來的用色規範、用色比例、所有的顏色也沒有進行足夠的擴充。在字級部分，設計師給出的字級分類方式並不標準、沒有考慮Spacing、Casing。
最重要的是，設計師在呈現設計規範的時候，並沒有呈現出任何支持這些設計決定的理論依據、思考過程。也沒有使用現有的產品介面進行實用演示。所有人都不知道這份設計規範實際投入使用會是什麼效果。
會議因此就在一個「大家覺得不說些什麼會大事不妙，但卻不知道怎麼給建議」的氣氛下結束了。
在會議的最後，我向所有人重新解釋了一次設計系統的重要性。但其實在發表這些結語的同時我已經意識到大事不妙了 — 我以為事情就會自己走上正軌的想法過於天真，但為時已晚。
接二連三的失敗，然後集體失憶
兩個禮拜之後，負責icon設計的設計師交付了產品所有icon的新設計，但結果慘不忍睹 — 與品牌不搭、與字體不搭，甚至與其他icon不搭。儘管如此，我們為了支持設計還是堅持使用了這些icon，然後在幾次的會議上被公開挑戰美感。
在之後其他專案中，我們嘗試使用設計規範所訂定的顏色與字體，但產品經理卻以不夠美觀、無法創造視覺層級、無法凸顯個別元素的理由而拒絕使用有設計系統的版本。
當我們把這個問題上升到產品部門主管時，得到的回應卻是「依照產品經理的決定執行」。甚至主管自己的需求也幾乎不會遵照設計規範進行設計。
設計師們也因此大受打擊。原本積極參與的設計師開始展現似有若無的逃避心態，而本來就不看好這項專案的設計師更是直接罷工。
這個時候的我才終於意識到這項專案已經失敗了，而且早在我意識到之前就已經死得透心涼。
設計系統從此成為一個大家避而不談的話題，每當有人提起總是被苦笑以對。項目計劃遭到擱置，我悄悄把在任務管理系統裡與他相關的任務一個一個撤下。主管似乎也跟我心照不宣，原本的部門周會裡追蹤設計系統的議程也被直接取消了。
就這樣，在幾次熱烈的會議、數百個小時的工作時間之後，我們換來不堪使用的icon庫、沒人敢用的顏色字級系統，以及低落的士氣。
所以，問題到底出在哪裏？
在擁有更豐富的管理與項目經驗之後回想起來，我想這次失敗的原因主要包含以下：
正當性不足
設計系統的執行者、使用者（UI設計師）與這項專案的發起者（我 — UX設計師）並不匹配，降低了管理專案的正當性。
在背景介紹中提到，我們的部門分成UI、UX、產品經理三種角色。在理想的情況下，應該由UI設計師來發起並執行這項專案。但我以為自己的能力足夠，就有意識地忽略了這個問題。
另外，雖然我對於設計系統的要比部門內的UI設計師要熟悉，但在沒有視覺設計的經驗背景的前提之下，我與UI的溝通總是講著不同的語言、有著肉眼可見的鴻溝。我與UI設計師之間也沒有上下級的隸屬關係，在組織授權層面就沒有正當性。
不自量力
團隊中有一半是初級設計師，剩下的設計師也沒有搭建設計系統的經驗，因此在設計系統的搭建過程中，所有人都像摸著石子過河，對項目目前狀態、下一步是什麼一片茫然。
除此之外，我們一開始設定的目標就太過弘大了。
我的第一步是請設計師們列舉所有可能使用到的組件清單，而這個工作流程背後的思想就是希望可以一次性做出涵蓋所有組件的設計系統。現在看來真是既不自量力也不切實際呢。
欠缺共識與認可
我想這是整個專案失敗的最主要原因，也是我從項目的開始到最後不了了之都持續在犯的錯。例如：
- 在與主管提議時，我高估了主管對設計系統的重視。以至於我沒有花足夠的時間準備詳盡的提案、讓她充分認可專案並 onboard
- 在與主管提議時，並沒有先與UI設計師討論過，讓UI onboard
- 在項目正式的啟動會上，並沒有把產品經理邀請進來，讓產品經理 onboard
- 在制定項目計劃的時候，並沒有與主管、UI設計師充分討論，取得他們對工作方式與流程的認可
這些我該做未做的溝通，為專案留下許多後遺症。部門上司不認為設計系統重要，沒有給項目足夠多的關注或資源，沒有給我充分的授權；UI團隊的角色流於聽話辦事的執行者、對項目一頭霧水；產品經理不了解設計系統對於體驗、系統健康的重要性，對設計規範不認可也不想用。
結語
以上就是我在執行設計系統時的失敗經驗。除了娛樂一下喜歡幸災樂禍的讀者之外，也希望提供了一些自己的屍體讓大家可以踩著前進，做出更好的設計。
其實寫這篇文章的一個重要背景，是因為我又發起了一次設計系統的專案。事過境遷，我已經成為了團隊的組長，直接控制了UI設計師們（反派笑），也在過程中盡量避免了以上所提到的問題。
這次成功了的話，我會再寫成另一篇文章描述始末，祝我好運。
