Consolidating Design Systems

Over time, systems happen.


An enterprise usually has many concurrent design systems. Separate groups chart paths loosely aware or even willfully ignorant of what others do. Many systems isn’t necessarily bad. Different programs may support different experiences and teams with different tools, and that’s ok.

Other times, systems keep experiences and teams apart. Unjustifiable inconsistency. Varying quality. Unmistakable redundancy. “We can do better,” an enterprise leader may say, “designing at scale.” And so they ponder:

Should we consolidate our design systems? If so, how?

Consolidation takes effort, time, and an emotional capability to relinquish (some) control. Heretofore independent systems may resist this uncomfortable change. So an approach to consolidation is best shared, rational, and yet also decisive. First, share an understanding of how each system arose. Second, rationalize the features, outputs, and practices on offer. Finally, define a consolidated identity and how it comes together.

How Did We Get Here? Map the Ecosystem.

Products (here, a circle) adopt systems (here, a diamond) to efficiently and consistently compose their experience.

Diagram of product depends on system

Across an enterprise, disparate systems can arise separate by myriad boundaries of teams, organization units, and platforms.

For example, systems can mirror organizational boundaries, such as:

While distinct systems, outsiders assume they share a common visual language inherited from Brand. Or, at least the logo, right? Not always. Inspection reveals massive discrepancies. One experience touts modern typography sourced from Brand in 2018. An archaic internal toolset from 2013 still rocks Verdana. It’s as if they are from separate companies. If you’ve worked at a company of any scale, you’ve lived this.

Larger entities — think the size of Microsofts, Amazons, IBMs, GEs, or any of the large banks — may replicate such system divisions across lines of business.

Complex diagram mapping systems to products
System of systems for a large bank, in need of more consolidation

In other cases, lines of business also create boundaries, such as a bank’s groups and apps for credit card, banking accounts, and loans. Leaders in design, product and engineering may be on their consolidation journey, having consolidated some (like credit card and banking) while others (loans and institutional) lag behind.

Distinct systems can also emerge due to a fairly basic premise:

“That system, over there, wasn’t made for us.”

Maybe native design conventions differ from the better-funded web system. Or, there’s a belief that “Employee tools have different needs than customers. Therefore, we need a different visual style and components.” Flat out, maybe it’s thinly-veiled hubris: their system isn’t good enough for our stuff. Digging into this more subjective and often emotional divisiveness is important.

Well-intentioned system teams serving distinct portfolios do try to “stay in touch” and “share best practices.” Yet apart from a meeting here and a hallway conversation there, nothing comes to pass. Are they sharing outputs like code libraries, documentation, design asset libraries? Not even close.

What Do We Have? Compare & Rationalize.

If you are considering consolidating, the first step is compare and rationalize differences. Your objective: help makers, customers, and sponsors get a sense of how things differ and could change as a result.

Compare Libraries & Outputs

To start, compare features of visual style, UI components, and other categories. Identify what features exist, how they are disseminated (as code and design assets), and depth of documentation of each part.

Rationalization table of two different systems
High-level system comparison that precedes a more thorough audit and report

For example, a Product group’s system may be more robustly featured and funded. On the other hand, Intranet’s system may be less mature, minimally funded. In that case, a high-level comparison would communicate:

Evaluate System Practices, Too

Systems aren’t just features. You must also evaluate how each system gets work done, expressed through the teams, processes, and depth of adoption already established. So also compare:

How Do We Consolidate? Pick a Path.

System histories and rationalization in hand, time to answer the big question: how do we consolidate and what — if any — systems survive it?

Option #1. Keep Both. Do Nothing.

Sometimes, teams walk away from the table. They aren’t ready to yield the autonomy, established norms, and distinct goals they don’t share. Another big threat? Resistance to change among their adopting customers.

Diagram of two systems, remaining distinct

Takeaways: If adoption of a consolidated system isn’t likely, why bother ?Traditionally, slowly changing products (I’m looking at you, internal tools!) are less likely to prioritize what consolidation brings.

To avoid doing nothing, begin conversation with agreement that both portfolios intend to use a consolidated system, soon. Also, to push conversation past a “do nothing” impasse, leadership must care enough, mandate consolidation, and designate a system to serve — and expected to be used by — teams into the future.

Option #2. Keep Both and Start Sharing Subsystems.

Complete consolidation may be too ambitious, yet teams could start with subsystem(s). Multiple systems with smaller connections — in code and collaboration — makes things more complicated. But start small, pilot sharing the foundational things, and see if it works.

Diagram of two systems depending on an ascendant shared system

Takeaways: It’s hard to stay connected, in agreement, and synchronized across boundaries without a long term commitment.

I’ve never seen a subsystem-only step occur, although I’ve discussed it with a few organizations. The approach appeals to sensibilities of separating concerns and making incremental progress. Yet change will be slow and and lack authoritative oomph. My role as outsider often leads to the harder, strategic question: are we really consolidating or not, and if so, how?

Option #3. Retire Both and Build a New System Together

Instead of sustaining existing features from one or both systems, you may retire both as a reboot to something new. Blowing up the old and starting fresh, bigger may be triggered by an external force — an executive mandate, brand refresh, or tech replatform. Maybe all of the above.

Diagram of all products shifting to a shared, new third system

Takeaways: Consolidation framed as a merger of equals raises complications. Decision-making is unclear. Everything is up for discussion. Without a considerable reboot leveling the playing field and really starting fresh, rationalization could dilute the value of both and integration becomes time-consuming. It’s expensive to reinvent from the ground up. Worse, every product’s change will take a long time. This is a difficult path to tread.

Option #4. Keep One and Inherit Features From the Other

Rationalization often indicates a predominant choice. A stronger system. As such, the mindset shifts to acquisition: what must we add from the weaker to the stronger system to best support all customers?

Diagram of some products shifting to a new system

When discussing an acquisition, ask the hard questions:

Takeaways: A stronger system’s success places them in a powerful position to dictate terms. Acquired systems may bring weaker tools, processes, capacity and commitments from their leaders. Yet their core features may still be strong, as is their emotional tie to them.

When talking mergers and acquisitions, “look into the books” of weaker system too. They may be looking for a way out, an existential lifeline, otherwise risking a fade into an abyss without a consolidation.

These imbalances makes consolidation conversations difficult. Your goal? Realizing the promise of a thriving practice serving more teams at scale. So time to exercise some leadership and management to make consolidation best serve your community!

Need help with your system?

EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.