Design System ，通常是為了跨各個產品/專案而建立，有別於用在單一專案的 Design Guideline。而這篇文就是在講述一個初次參與搭建 Design System 遇到的坑👀
背景
我任職於 B2B 新創公司。公司有許多複雜商業邏輯的後台產品以及複合元件，而且必須應用在不同的產品中。同時，公司有很多產品線要開跑，於是如何維持一致的產品設計變成我們當時的課題。
討論下來，我們 Design Team 一致覺得，這是建立 Design System 的好時機。我們還 Survey 了一些方便前端搭建元件庫的服務（最後選擇了Storybook）期待能夠協力完成一套美美的元件庫。
但結果也許可以說是不盡人意。
我們完成 Design System 的設計，成功地在跨產品間應用。前端也努力刻出美美的元件庫，UI 也完成驗收。
那為什麼說不盡人意呢？
因為經過一年後，元件庫不符合跨團隊各自的需求，考量各團隊自己的管理步調，元件庫決定不再繼續維護，往後的專案也以自己獨立的元件為主。（但設計這邊依然使用建立完成的 Design System）
從經驗中，我學到了⋯
回頭審視，Design System 最後無法順利推行，主要可以歸類為下列幾種理由：
🧐 原因一：各專案的設計與開發並行，來不及等 Design System 完成在步調快速的新創公司裡，我們最主要的目標就是讓產品盡快上線。而Design System 的複雜性勢必需要時間規劃與開發。
於是當時開發上決定採取專案、Design System 並行的策略。
設計上的分工為「主要做 Design System 元件的設計師」以及「其他產品線的設計師」，同時開工。
如果要用的元件 Design System 還沒做，那該產品線的設計師就先做一個版本，再看 Design System 要不要納入，之後在回頭調整。
不過，這樣的想法雖然很理想與美好，但實行上卻屢次碰壁。
因為「替換元件」跟「同步元件」其實都沒有想像中輕鬆。
以設計團隊自己本身來說，Design System 一做好設計元件，大家就會趕快拿去用。但 Design System 還尚未完善，所以應用上會卡關，畢竟設計好的元件本身也是需要迭代的！於是根據各產品線的 PO 要求，元件又開始變形了。
同時，各元件處於一個邊做邊更新的狀態。但對其他專案來說，同步元件樣式到最新版本，並不是首要之急，最後就產生了不同步。
這樣導致了同一個 Design System 元件卻存在著不同版本的情況，得花好一番力氣去修正，也失去了 Design System 原本想要統一設計語言的美意。
🧐 原因二：Design System 沒有建立維護流程因為人力問題，當初 Design System 當初是從其他專案抽人力來做，這代表著參與的人同時肩負著兩份任務。可能要一下處理 Design System 的需求，一下回去接其他專案。而這樣無論速度、品質、後續維護都進行得不順暢。
同時，這樣的進行方式，其實需要很多會議來同步彼此之間的進度。但當下大家在不同團隊中各做各的趕進度，同步困難。
🧐 原因三：Design System 的定位以及期待Design System 最常被用於解決跨產品、專案間的設計一制性與元件不重複開發等情況。但是當它被引入團隊後，團隊中的各個利害關係人對它抱持著不同想法。例如：認為有了 Design System 後，就能快速建立 MVP、有了Design System 以後不用畫 wireframe、某產品獨有的邏輯也希望包進 Design System ⋯等等。
這時才驚覺，Design System 並不是所有人的共同語言。非設計師的角色，可能對他抱有不同想法。有的人覺得他像棋盤，有的人覺得像塊綠豆糕。他是一個需要被介紹、導入的文化。執行上也像一個大專案一樣，需要了解各個利害關係人對此的看法，彼此溝通與協調。
此外，我們很容易看到著名的 Design System 擁有很高的完成度與精美的細節，而認為所謂 Design System 就應該有如此規模。
但那些知名的 Design System，背後完成的團隊規模與時間，未必是符合現在公司的資源以及需求的。
回到實務上，Design System 還是得根據組織架構、資源，以及團隊去怎麼應用來規劃。
其他人怎麼說？
有趣的是，我寫另一篇文時找了NNG的參考資料，他碰巧也提到幾個不推薦使用設計系統的情境，分別為：
1.Creating and maintaining a design system is a time-intensive activity which requires a dedicated team.
Design systems, unfortunately, are not a one-and-done solution. At their best, they are constantly evolving as teams gather feedback from those who use them.
設計系統並不是一個一次解決方案。他是需要持續發展、迭代的。因此，他需要一個 Team 定期取得回饋。
2. It takes time to teach others how to use the design system.
Any design system, even if it were adapted from an existing one, needs instructions for use — otherwise there is a risk that it may be applied inconsistently or incorrectly across screens or across teams.
設計系統需要花時間導入。協作對象需要了解如何使用，以及如何適配原本已存在的系統，否則將會有使用錯誤、增加不一致的風險。
結語
雖然說前面說了很多踩過的坑。但其實搭建 Design System ，對於往後專案的共識與抽象層次還是有很多幫助！所有設計師都參與了產品風格的討論與定義，公司產品的設計語言也更加統一，往後的專案也能帶著這些打好的基礎與共識出發。
