Splitting Design Systems

Deciding to split a design systems is a critical decision that will reshape how teams work and how products evolve. This tactic helps you explore whether your system should stay unified or evolve into multiple systems by mapping needs, weighing trade-offs, and defining boundaries. It provides a structured process to make the split intentional and sustainable.

How to

1. Frame the decision

   Begin with a Hypothesis Statement about what your current system is expected to solve. Define the problem you're testing: is one system enough, or are diverging needs creating friction?

2. Map shared and unique needs

   Audit your brands, platforms, and domains. Identify what is truly common across all contexts and what is unique. Use Audit outputs to ground this in real evidence.

3. Weigh the trade-offs

   Discuss what is gained and lost in each scenario. A single system simplifies governance but can slow delivery. Multiple systems speed up teams but risk duplication and inconsistency.

4. Define split criteria

   Agree on clear rules for when something belongs in the shared system versus a branched one (e.g., base tokens stay unified, platform patterns may diverge).

5. Plan ownership and migration

   Assign who will own each system using system RACI. Document how assets will migrate in your Guidance Setup so teams know what to adopt and when.

6. Review impact

   After the split, run a System Health Check to track adoption and validate that the decision improved clarity and delivery.