如何整合多個設計系統

譯者序：設計系統的目標是爲組織帶來規模化的效率和一致性。然而，隨着時間的推移和團隊的增長，單個組織內往往會出現多個並行的設計系統。合併多個系統是一個複雜的過程，需要仔細規劃和執行。本文作者 Evgeny Khoroshilov 探討了幾種整合多個設計系統的選擇，包括繼續保持現狀、共享子系統、全新構建統一系統或保留一個主導系統等。每種方式都有其優缺點，適合不同的組織情況。

探索整合多個設計系統的選項。學習策略，潛在的好處和實際的例子來指導你的組織。

讓我們假設你正在爲同事開發一套工具，它越來越受歡迎，項目進展得更快，你的團隊也在壯大，於是你決定是時候做正確的事情了 — 將之正式定爲設計系統。消息傳開後，你與高層管理人員交談，發現公司內還有其他類似的計劃。順便說一句，已經有一個存在了很長時間的系統，但你們的部門太遠，你從未知曉。另一個系統是一個小衆系統，他們出於某些特殊原因使用不同的前端框架。哦，他們還有移動平臺的組件。

你的頭開始發暈，你並不是唯一一個在建立設計系統的人！經過一番冷靜下來，一些新的感受和認識開始浮現。接下來會發生什麼？一個季度後？一年後？

如果這聽起來很熟悉，你可能就經歷過這種情況，又或者你現在正處於這種境地。別擔心，你正走在正確的道路上。在本文中，我們將探討系統組織即將面臨的潛在發展情景。

坦率地說，這種多系統案例並不像看起來那麼罕見。不同的團隊服務於不同的項目，具有不同的業務價值、歷史原因、預算、資源、時間分配、人員專長、利益相關者支持等，隨着時間的推移，產生了獨立而不盡相同的設計系統。它們當中可能有許多相似之處，但永遠不會完全吻合，這也是可以理解的。當然，時間也是另一個因素。一個龐大的專家團隊在 3 個月內構建的設計系統，其成熟度當然無法與一箇中等發展水平的團隊花費 3 年時間構建的系統相提並論。

隨着時間的推移，領導層可能將產生整合的想法。當然，有許多原因，但是很顯然 — 這正是設計系統的初衷！大規模應對挑戰 — 減少重複工作、減少資源浪費、減少冗餘、提高一致性。聽起來幾乎太過簡單，因爲它當然並非如此。當獨立的系統更願意保持獨立時，情況甚至可能變得棘手。。。

一個薛定諤的系統

系統疊加 / 所有圖像歸其各自作者所有

那麼事情會朝着什麼方向發展呢？嗯，有選擇。唐突的決定是個壞決定。一切都應該被考慮、分析、權衡，在某些情況下還需要進行概念驗證 (POC)。最終結果取決於你的組織的具體環境和願景。能否回到起點？當然可以！我們是否應該爲一個長達 2.5 年的遷移做好準備？也許我們應該這樣做！此時，它就像是一個出現在疊加狀態中的系統。

然而，潛在的發展方向在一定程度上是已知的。更重要的是，許多公司已經經歷過類似的挑戰，他們的經驗是寶貴的。

知識就是力量。爲這段旅程做好準備。

方案與實例

讓我們通過現實世界中的一個類比，來了解你的組織可能面臨的挑戰。

想象一個汽車集團，旗下擁有多個汽車品牌，每個品牌分別服務於不同的市場細分，但都隸屬於同一家企業。每個品牌都發展出了自己獨特的製造汽車方式，利用不同的工程團隊、技術和供應商。然而，爲了優化運營、降低成本併發揮協同效應，集團正在考慮整合其製造和設計流程的策略，同時仍照顧不同市場細分的需求。

系統現狀

接下來，我們將探索未來發展的幾個選擇，每個選擇都會強調優缺點、風險、成本和 “快速成果”，目的是在戰術層面上改善當前狀況。

選項 1: 系統繼續保持現狀

在這種情況下，汽車集團允許旗下每一個汽車品牌獨立運營，利用其獨特的製造流程、技術和市場策略。每個品牌致力於服務其特定細分市場——豪華、經濟、運動等，而不會改變其個人運營。這種做法保持了品牌身份和專門化，但可能導致整個集團在研究、開發和生產方面的重複。

選項 1: 保持現狀

這種做法的一個很好例子是蘋果公司，它繼續分別開發 macOS 和 iOS，以滿足臺式機和移動市場的不同需求。儘管兩者有一些交叉功能，但這兩個平臺仍保持獨立。

從實際角度看，這個選項似乎什麼也沒發生。然而，說沒有任何變化是不正確的——在進行比較和分析的過程中，系統、利益相關者和領導層獲得了大量知識。當然，系統現狀暫時保持不變，但這些信息使我們能夠針對不同的發展領域制定戰略。而且，很可能隨着時間的推移會有其他改進和重新評估。

選項 2：系統開始共享子系統

在這種情況下，集團首先確定其品牌之間的共同點，比如需要安全功能、信息娛樂系統或發動機部件。然後決定將這些統一爲共享的子系統，由中央開發並部署到不同的汽車型號和品牌。這一舉措可減少成本並簡化運營，同時仍允許每個品牌保持其獨特的市場定位。品牌開始從技術和設計創新中獲益，這些創新是由姐妹品牌開發的，從而促進知識共享和效率文化。

選項 2: 開始共享子系統

前些時候，Adobe 將其獨立的桌面應用程序過渡到 Adobe Creative Cloud 集成套件，允許不同 Adobe 軟件之間無縫文件和設置同步，如 Photoshop、Illustrator 和 After Effects。這一轉變使設計師能夠在不同應用程序之間更流暢地工作，實質上是在共享雲存儲、字體管理和資產庫等子系統。

在設計系統環境中，人們立刻會想到設計令牌（Token）或其他形式的系統基礎和品牌統一。您還可以考慮一個共同的文檔庫、共享無障礙實踐、語音和語氣指南等。從技術角度來看，考慮統一平臺解決方案，如發佈流程、資產分發等。

選項 3：系統退役，嶄新系統出現

繼續類比，集團決定逐步淘汰其中一些較舊、效率較低的汽車品牌或型號，並推出一個新品牌或新車型，其中融合了整個集團的最佳技術、流程和市場策略。這個新品牌是從頭開始構建的，旨在滿足當前市場需求和技術進步，逐步取代較舊的品牌。

選項 3：系統退役，一個新的系統出現

這是一個大膽的舉措，涉及重大投資和戰略性大修，但目的是確保長期保持市場相關性和競爭力。

2014 年，谷歌宣佈從 AngularJS 過渡到 Angular。這是一個重大轉變，涉及 1600 多個應用程序，需要廢棄舊框架，利用現代 Web 開發實踐從頭開始構建新框架。

這確實是一個大膽的舉措，如果一次性做出如此大的改變，就好比在高速公路上狠踩剎車。除了投資和徹底的規劃外，這一策略還需要 RFC、POC，可能需要多次概念驗證。還需要一個仔細組織的路線圖，逐步過渡。根據組織規模的不同，這可能需要數年時間，即使在那之後，您可能仍會發現應用程序中存在一些過時的頁面，這純屬是出於成本效益的考慮。

更精簡的策略可能是先過渡到 “選項 2” 所述狀態，過一段時間後再評估。有可能這一步就足夠了。

選項 4：保留一個系統，其他系統退役

經過徹底評估後，集團決定只保留最先進、最高效、最具市場響應能力的品牌繼續運營。其他品牌將逐步被淘汰，而它們最出色的功能、技術和市場策略將被整合到倖存的品牌中。這可能意味着，爲豪華品牌開發的高效發動機將被用於經濟型車型，或者成功的設計語言將在全系列中採用。此過程包括重新培訓員工、調整製造流程，並過渡客戶羣以採用整合品牌的產品。

選項 4：保留一個系統，其他退役

在科技界，Adobe 決定放棄 Flash、轉而支持 HTML5 就是一個恰當的例子。隨着時間推移，Flash 的侷限性變得越來越明顯，包括安全漏洞和在移動設備上缺乏支持。HTML5 提供了更安全、高效和靈活的替代方案，促使 Adobe 宣佈到 2020 年底停止對 Flash 的支持。這一轉變要求開發人員和內容創作者將內容遷移到更新、更可持續的 HTML5 標準上。

如果覺得懷念, 可以查看一下 ruffle 項目——開源和安全的 Flash 播放器模擬器

如果沒有一個系統的光芒足以掩蓋其他系統，選擇這種方法可能會變得非常微妙。在實踐中，這可能意味着缺乏一個或一些在其他領域具有堅實優勢的學科。例如，優秀的專家沒有專門的時間分配，穩定和開發的 UI 庫沒有無障礙實踐，或者在所有技術領域都很優秀，除了庫框架落後了幾代人。 

自然地，要繼續使用一個系統，它應該是強大的，這樣它可以基於最佳合適的選擇，加上來自其他系統的最佳或缺乏的規程 (混合方法) 形成。

接下來的步驟

由於大規模組織的惰性和整體複雜性，整合發現需要耐心、細緻的計劃和對漸進進展的開放態度。由於既定的流程和現有業務的規模，使不同部門和系統保持一致可能是非常具有挑戰性的。這種固有的慣性意味着，整合不是一種可以在一夜之間翻轉的轉換。它可能需要幾年的時間才能展開，或者在某些情況下，可能會導致人們意識到完全合併並不是最佳解決方案。 

這就是爲什麼本旅程的第一步是對現有系統進行全面分析和功能比較。這項基礎性工作是至關重要的，因爲它爲組織設計系統的未來做出明智的決策奠定了基礎。此外，組織可以繼續起草 RFCs，開發 POCs，甚至組建新的團隊來領導整合工作。 

這些步驟並不是微不足道的，它們需要在時間、資源、領導層和整個組織的利益相關者的承諾方面進行大量的投資。然而，有了對未來潛在選擇的清晰理解，並吸取其他人應對類似挑戰的經驗，組織可以更有信心和清晰地處理設計系統整合的任務。

原作者：Evgeny Khoroshilov

原標題：How to consolidate multiple design systems

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/wBbD5TscUgWOj_UoBey-jA

猜你喜歡