Explore the options of consolidating multiple design systems. Learn strategies, potential benefits and real-world examples to guide your organization.
Let’s say you are working on a set of tools for your colleagues, it’s getting traction, projects are built faster, your team grows and you decide it’s time to make the right thing — make this the official Design System. The word spreads, you talk to the upper management and find out there are other similar initiatives in the company. Incidentally, one System exists for ages already, but your departments are so far apart you never knew. The other System is a niche thing, they use a different frontend framework for particular reasons. Oh, and they also have components for mobile platforms.
Your head starts to spin, you are not alone who have been working on the Design System establishment! After a breather some new feelings and realizations emerge. What happens now? In a quarter? After a year?
If this sounds familiar you’ve probably been there, or you might be there now while you are reading this. Worry not, you are on the right track. In this article we’ll explore the scenarios of the upcoming potential developments of the Systems organization.
To be fair, this multi-system case is not as rare as it may seem. Different teams serving different projects with different business value, historical reasons, budgeting, resources, time allocation, people expertise, stakeholders support etc — produce independent varying Design Systems over time. There can be many similarities, but there will never be a total match, and that’s ok. Then of course, time is another factor. Huge team of experts won’t build a Design System of the same degree of maturity in 3 months as a moderately developed team would do in 3 years.
Over time leadership may (will!) come up with an idea of consolidation. For a number of reasons, of course, however something is pretty much on the surface — it’s what Design Systems were built for! Overcome challenges at scale — less effort duplication, less resources spent, less redundancy, higher consistency. Sounds almost too easy, because it’s surely not. And it may even get gnarly when independent systems prefer to stay independent…
A Schroedinger’s System
Systems Superposition / All images belong to their respectful authors
So where do things go from here? Well, there are Options. Abrupt decision is a bad decision. Everything should be considered, analyzed, weighted and potentially POC-d (Proof of Concept) in some cases. The final outcome is unique to your organization’s circumstances and aspirations. Can it go back to the starting point? It sure can! Should we prepare for a 2.5-year-long migration? Maybe we should! At this point, it’s like System appearing in superposition.
And yet, potential developments are known to the extent. What’s more, a lot of companies have been through similar challenges already and their experience is invaluable.
Knowledge is power. Equip for the journey.
Options and Examples
Let’s have a look at the challenges that your organization might be facing with the help of a real-world analogy.
Imagine an automotive conglomerate that operates multiple car brands, each serving different market segments but under the same corporate umbrella. Each brand has developed its unique way of building cars, utilizing different engineering teams, technologies, and suppliers. However, to optimize operations, reduce costs, and leverage synergies, the conglomerate considers strategies to consolidate its manufacturing and design processes while still catering to its diverse market segments.
Systems Status Quo
We’ll now explore several options of further advancement, each highlighting pros, cons, risks, costs and “quick wins”, that aim to tactically improve the current situation.
Option 1: Systems Continue Work as They Do
In this scenario, the automotive conglomerate allows each of its car brands to operate independently, utilizing their unique manufacturing processes, technologies, and market strategies. Each brand caters to its specific segment — luxury, economy, sports, etc. without altering their individual operations. This approach maintains brand identity and specialization but may lead to redundancy in research, development, and production across the conglomerate.
Option 1: Systems continue work as they doPros: Each brand maintains its unique identity and specialized market focus. Innovation and experimentation are less restricted by overarching constraints.Cons: Duplication of efforts and resources across brands leads to inefficiencies. Opportunities for cost savings and standardization are missed.Risks: Stagnation due to a lack of collaboration and knowledge sharing. Potential to fall behind competitors who optimize their operations.Costs: Same, for maintaining separate development, production facilities, and support systems.Quick Win: Cross-brand communities of practice to share knowledge and best practices without altering existing structures.
A good example of this approach is Apple, which continues to develop macOS and iOS separately, catering to desktop and mobile markets with distinct systems. Although there are crossover features, the platforms remain independent.
This option may seem like nothing happens from a practical perspective. However, it’s incorrect to say there are no changes — while going through comparison and analysis, systems, stakeholders and leadership acquire a lot of knowledge. Sure, systems’ status quo holds for now, but this information allows us to strategize over different areas of development. And most probably over time there will be other improvements and re-evaluations.
Option 2: Systems Start Sharing Subsystems
Here, the conglomerate first identifies commonalities between its brands, such as the need for safety features, infotainment systems, or engine components. It decides then to consolidate these into shared subsystems, developed centrally and then deployed across different car models and brands. This initiative reduces costs and streamlines operations while still allowing each brand to maintain its unique market positioning. Brands start benefiting from advancements in technology and design innovations developed by their sister brands, promoting a culture of knowledge sharing and efficiency.
Option 2: Systems start sharing subsystemsPros: Efficiency gains from reusing components and knowledge across brands. Potential for a unified quality standard.Cons: Challenges in aligning different teams’ priorities and methods. Risk of diluting brand identity.Risks: Resistance from teams accustomed to working independently. Integration issues between disparate systems.Costs: Moderate, investments in integration and standardization upfront but savings over time.Quick win: Shared organization of common components, like infotainment systems or safety features.
Some time ago Adobe transitioned its standalone desktop applications into an integrated suite known as Adobe Creative Cloud, allowing for seamless file and setting synchronization across different Adobe software. This shift enabled designers to work more fluidly between applications like Photoshop, Illustrator, and After Effects, effectively sharing subsystems such as cloud storage, font management, and asset libraries.
In the context of a Design System environment instantaneously one thinks of Design Tokens or other forms of system foundation and brand uniformity. You can also consider a common Documentation library, shared Accessibility best practices, Voice and Tone guidelines and more along these lines. From a technical perspective think of unifying the platform solutions, like release processes, assets distribution etc.
Option 3: Systems Retire and a New One Emerges
To continue with analogy, the conglomerate decides to phase out several of its older, less efficient car brands or models and launches a new brand or model line that incorporates the best technologies, processes, and market strategies learned from the entire group. This new brand is built from scratch to address current market demands and technological advancements, aiming to replace the older ones progressively.
Option 3: Systems retire and a New one emerges
It’s a bold move, involving significant investment and a strategic overhaul, but it’s aimed at ensuring long-term relevance and competitiveness in the market.
Pros: Opportunity to build from the ground up with modern practices and technologies. Can address legacy issues.Cons: Significant upfront investment. Risk of disruption to current operations and customer experiences.Risks: Adoption resistance, both internally and from existing users. Potential for project delays and overruns.Costs: High, both in development and in transitioning users and staff.Quick Win: Pilot programs to test and refine the new system before a full rollout.
In 2014 Google announced a transition from AngularJS to Angular. It was a significant shift spanning more than 1600 applications that involved retiring the old framework in favor of a new one built from the ground up, considering modern web development practices.
Once again, it is quite a bold move, and even more bold if done at once, as that would be similar to pulling the hand brake at 200km/h on the autobahn. Apart from investment and thorough planning, this strategy cries for RFC, POC, probably a couple, maybe a dozen. And a carefully organized roadmap, transitioning from here to then and following the milestones. Depending on the organization size it can take years, and even after that you may find some outdated pages in your apps, simply due to the cost efficiency.
More lean strategy may involve transition to the state in “Option 2” first and re-evaluate some time later. It may happen that this step would be satisfactory enough.
Option 4: One System Stays and Others Retire
After a thorough assessment, the conglomerate decides that only the most advanced, efficient, and market-responsive brand will continue its operations as before. The other brands will gradually be phased out, with their best features, technologies, and market strategies being integrated into the surviving brand. This could mean, for example, that a high-efficiency engine developed for a luxury brand is adapted for use in economy models, or a successful design language is adopted across the board. This process includes retraining staff, retooling manufacturing processes, and transitioning the customer base to adopt the products of the consolidated brand.
Option 4: One System Stays and Others RetirePros: Streamlines operations by focusing on the most successful or advanced system. Encourages uniform quality and experience.Cons: May not meet all unique market segment needs. Could discourage innovation in the absorbed systems.Risks: Alienation of customers and teams attached to the retiring brands/systems.Costs: Moderate to high, depending on the scale of integration and rebranding efforts.Quick Win: Integrating branding and marketing efforts for a smoother transition and unified customer experience.
In the tech world, Adobe’s decision to discontinue Flash in favor of HTML5 is a pertinent example. Over time, Flash’s limitations became apparent, including security vulnerabilities and lack of support on mobile devices. HTML5 offered a more secure, efficient, and flexible alternative, leading Adobe to announce the end of Flash support by the end of 2020. This shift required developers and content creators to migrate their content to the newer, more sustainable HTML5 standard.
💡 If you feel nostalgic, check out the ruffle project — the open source and safe Flash player emulator
Choosing this approach can get quite nuanced if none of the systems shines bright enough to overshadow others. In practice that could mean lack in one or some disciplines with solid advantage in the others. For example, great specialists without dedicated time allocation, stable and developed UI library minus the accessibility practices, or excellence in all tech areas, except the library framework is a couple of generations behind.
Naturally, to proceed with one system, it should stand strong so it can be formed based on the best suitable choice, plus the best or lacking disciplines from the other systems (hybrid approach).
To the Next Steps
Consolidation discovery requires patience, meticulous planning, and an openness to gradual progress, due to the inert nature of large-scale organizations and overall complexity. It can be very challenging to align different departments and systems due to established processes and the scale of existing operations. This inherent inertia means that consolidation is not a switch that can be flipped overnight. It’s something that might unfold over several years or, in some cases, might lead to the realization that complete consolidation is not the optimal solution after all.
This is why the initial step in this journey is a comprehensive analysis and feature comparison of the existing systems. This foundational work is critical, as it sets the stage for informed decision-making regarding the future of the organization’s Design Systems. Further, the organization may proceed with drafting RFCs, developing POCs, or even forming new teams dedicated to lead the consolidation effort.
These steps are not trivial, they require significant investment in terms of time, resources, and commitment from leadership and stakeholders across the organization. However, armed with a clear understanding of the potential options ahead and drawing on the experiences of others who have navigated similar challenges, organizations can approach the task of Design Systems consolidation with greater confidence and clarity.
Acknowledgment
This article is heavily inspired by the work of Nathan Curtis. If you haven’t read it yet, please indulge yourself!
How to consolidate multiple design systems was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
