Published in


Consolidating Design Systems

Over time, systems happen.

How Did We Get Here? Map the Ecosystem.

Four design systems, supporting squads of varying quantities adopting a visual language at various times.
  • Product serving customers across web, native, and other touchpoints.
  • Internal (aka, Intranet, Admin, “Enterprise”) apps serving employees.
  • Marketing (for some, “.com”) and ecommerce, usually in the form of content sites and/or pre- and post-purchase transactional apps.
  • Corporate sites about the company, finances, jobs, press, and microsites.
System of systems for a large bank, in need of more consolidation

What Do We Have? Compare & Rationalize.

Compare Libraries & Outputs

High-level system comparison that precedes a more thorough audit and report
  • Visual style: Inconsistent.
    Hopes of existing alignment are dashed. The logo and core brand color match, but divergent neutral, interactive, and accent colors are in utter conflict. Typography is a mess. Icons are sourced from libraries with distinct tones.
  • UI Components: Overlapping but Inconsistent.
    Both offer the same core set common components. But their design and variation taxonomy don’t at all match. Plus, each library also offers up to 20 other components that the other does not.
  • Additional Libraries: One vast, another empty.
    The Product catalog also strongly supports UX Patterns, Accessibility, Layouts, and Motion, while Internal Tools offers nothing beyond style and components. Where’s content strategy / Editorial? Both casually (or meekly) point to Brand’s PDF single page on tone.
  • Outputs: Different code frameworks, different design software.
    Product offers React code and Sketch assets, while Internal tools provides a dated Angular codebase and an Adobe Illustrator symbol set.
  • Documentation: Different but both strong.
    Both teams invested heavily in quality code documenting and contain relevant design guidance. That’s rare, but if true, then shift conversation to content reconciliation and information architecture concerns.

Evaluate System Practices, Too

How Do We Consolidate? Pick a Path.

Option #1. Keep Both. Do Nothing.

  • For features, nothing changes. Both persist redundant libraries.
  • For people and processes, disconnected practices remain.
  • For products, nothing changes. Adopters dodge a refactoring or redesign, yet users continue with lower quality, inconsistent experiences.

Option #2. Keep Both and Start Sharing Subsystems.

  • For features, converge foundations, even if design before code. Start with style (color, typography) applied to essential components (buttons, forms). Do teams share a dependency on design tokens that are separated from any given component library? Be realistic that a single source-of-truth for front-end code and documentation probably come later.
  • For people and process, increase collaboration across groups. Brown bags and random shares should give way to vibrant Slack discussions and and regularly attended critique. Leaders must create space and time for this, but it may not yet be time to unify rituals into a single team.
  • For products, demonstrate proof of intent through willing teams on both sides without a mandate wide change all products now.

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

  • For features, once a new design language is in play, so too will be UI components and code too. The “softer” libraries like UX patterns and editorial may avoid reimagination, but they won’t be in the spotlight.
  • For people and processes, a larger team may combines the capacity of both existing programs under a bigger umbrella, although maybe efficiencies risk trimming system capacity.
  • For products, every … single … experience faces uncertain, potentially large change. Existing adopters from all sides may wince at integrating a massive redesign while being subsumed by something intended for an even more diverse portfolio.

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

  • For features, acquired customers will demand feature parity with what they currently use. You can’t drop components, features, frameworks, and supported platforms, can you? Possibly, but the surviving system will need to grow and diversify to serve a wider customer base.
  • For people and processes, combine both to ideally grow the team to serve the wider base. Adopting a stronger system favors adopting the workflows and operations of that system, but not always.
  • For products, it’s business as usual for those using the surviving system. On the other hand, acquired customers must adopt something new.



A collection of stories, studies, and deep thinking from EightShapes

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Nathan Curtis

Founded UX firm @eightshapes, contributing to the design systems field through consulting and workshops. VT & @uchicago grad.