設計系統有助於建立一套有組織的模式與實務集合，不僅能在組織內帶來一致的使用者體驗，也能透過程式碼重用為工程團隊提升效率。一旦你成功說服組織採用這套系統，並推動多個團隊導入，接下來在長期管理、擴充與優化系統的過程中，將會面臨許多挑戰。

資源配置

其中一項首要挑戰，就是為系統投入資源。設計系統一開始往往是由充滿熱情的工程師與設計師自然而然地推動成形，他們希望在不同應用程式之間重用模式與程式碼。這群人可以組成「核心團隊」（Core Team），引導系統的發展，定期討論共享函式庫集合的願景，決定哪些內容該加入函式庫，以及 API 該如何設計。

然而，這類維護與規劃本身就是一份全職工作。若只是利用本職工作之餘兼顧，往往難以負荷。結果便是元件 API 之間出現不一致，程式碼審查因實作方式的分歧而延宕，進而造成開發者的挫折感。

成立一個平台團隊來負責系統的開發，並建立明確的貢獻流程，就能有效解決這個問題。讓工程師專注於系統的長期健康發展，有助於帶來一致性，也讓新增內容到設計系統的流程更加清晰。

定義生命週期流程

借鏡Atomic Design 的理念，建立一套清晰的模式變更流程會很有幫助。以下是一些常見且值得思考的問題：

• 何時該新增元件，何時又該擴充現有元件？我們需要哪些資訊來做判斷？
• 如何定義元件的成熟度，並向使用者傳達？如果新增了一個元件，我們是否能放心讓它立刻被廣泛用於正式環境？
• 我們的 API 設計理念是什麼？應該偏向更彈性，還是更受限的 API 設計？
• 如何處理會造成破壞性的 API 變更，包含棄用或移除元件？我們會提前多久通知使用者？是否有主要的版本發布時程，讓各團隊能預先規劃？

確保品質

設計系統對其他工程團隊的一大承諾，就是減少他們的工作量：直接使用我們預先建好的元件，就不用自己從頭打造！但如果你的變更經常破壞這些元件在他們應用程式中的使用方式，很快就會引發不滿，因為非預期的除錯工作將落在這些團隊身上。

可以使用Storybook 建立各種「stories」來測試元件，涵蓋應用團隊使用元件的所有方式。Stories 代表功能與視覺上的測試案例，確保所有使用情境都有對應的 story，就能避免為使用者帶來問題。將 Storybook 與Chromatic 結合，還能加入視覺回歸測試，並讓設計師更輕鬆地參與審查階段。Storybook 的play functions 則能涵蓋那些需要使用者互動的情境。

使用react-testing-library 撰寫單元測試，是建立可維護測試的好方法，同時也能促使開發出更具可及性的元件。

對設計系統進行內部試用也是在下游使用者發現問題之前及早捕捉問題的好方法。在設計系統中維護多種分子與有機體，有助於更早發現原子層級的問題。

收集回饋並發掘未來機會

作為設計系統的維護者，你可能會被問到設計系統何時才會「完成」。事實上，隨著組織不斷建構新應用、遇到新的使用情境、浮現新的模式，設計系統將會持續演進。品牌重塑與設計團隊方向的改變，也可能為系統帶來不小的衝擊。

你需要定期向使用者收集回饋：包含工程團隊、設計師、產品經理以及終端使用者。你的設計系統本身就是一項產品，必須有人擔任產品負責人（Product Owner）的角色，確保設計系統朝正確的方向前進，並持續為所有使用者解決問題。