Two design system mental models that bump heads.

This is something that pops up so frequently you may not have actually noticed it.

I’m talking about two ways of thinking about design systems that can create entirely different ways of working, standards, practices and lead to different outcomes.

I’ve had these ideas simmering for long enough that I have reduced this idea to two fundamental directions:

A) Help lots of teams make one cohesive thing

B) Help lots of teams make multiple things appear as one cohesive thing

I know what you’re thinking…

Help lots of teams make one cohesive thing

This model supports a product or “the codebase” (singular).

This could be a native app, small company or start up with one (or single digit) primary target output.

This type of system is about working in the same way and using the same source material when making decisions. Everyone has access to everything. It’s a tighter, more controlled environment.

The system will be have a high coverage representation of the product and may even include things like un-templated “screens” or “pages”.

Contribution and changes will be easier because everyone can see the entire landscape of the product from within the system and decisions can be made quickly.

Versioning may have a tighter relationship with the product roadmap. For example, Design System v.2.0.0 might be paired with a particular release of an application, almost like apple having a new UI kit every time iOS updates.

This model will undoubtedly give you the most cohesive and visually aligned experience, but in part that it is because it is already one thing.

This type of system is usually design-led or has a design only deliverable because “the codebase” is the product itself.

Because of the needs of this type of model to have high coverage, there is usually a mixture of high and low quality solutions documented that may not scale well outside the target they are originally made for.

Help lots of teams make multiple things appear as one cohesive thing

This model supports an organisation with multiple disconnected applications.

The primary intent of this model is to help the wider ecosystem create the illusion of one experience for a user or customer. The chances are, if you work for a big company or organisation with lots of different offerings this will be one of the main objectives of the design system.

The system will likely have lower coverage of components with a higher emphasis on foundational product agnostic content. It will have more guidance on how to create common components, patterns and content the right way and a more modular or abstracted approach to component scope and properties.

It’s likely to have a greater return on investment because it has a greater number of potential consumers.

Contribution will be harder and stricter, because the design system will have limited visibility of the complete product landscape. Each contribution will need to go through vital rounds of research and testing before it can be raised up to potentially replace what been used by tens, hundreds or thousands of separate applications.

Versioning may have no direct relationship to the product roadmap at all, just a relationship to itself. The design system and product may only sync up versions for a new “era” of system — something like an inevitable rebrand (see the excellent Scott’s law of rebrands).

This type of system will have have a greater emphasis on the developer output — such as a insert-languge-here package. In this model, “the codebase” is the design system that gets consumed and becomes a dependency of product applications. The design deliverable in this case is to make sure the developer package is well represented in design tooling.

This model will have a high emphasis on backwards compatibility because at any one time products could be consuming any version of the design system ever released.

What might be surprising to some, the main product may not always need to directly consume (or need — shock I know) a design system. As mentioned at the start, this type of design system’s entire reason for existing could be for making the wider ecosystem feel like the main product. This allows the main product to change and adapt as needed and the design system’s job is to roll the relevant changes out to everyone else.

A great example of this was the GOV.UK Design System. When I was at GDS (quite a while ago now — I imagine things have changed a bit), the initial intent of the design system was not to create a design system for the GOV.UK website. It was to create a design system for the hundreds or thousands of product teams in multiple agencies make services that looked and behaved like GOV.UK. To give users a unified experience across an incredibly wide ecosystem.

This is just an attempt to recognise the reason both of these models exist.

When people say things about “aligning with code” ask yourself “what code?” — If it’s the product code, that’s entirely different from the code in a design system created package.

When people talk about “coverage”, coverage of what? Sure a product based system could and should have 80–100% coverage. But a central system used by hundreds of apps may intentionally not actually want or need to cover more than 30% of what’s out there.

Have a clear picture of what you’re making the system for and recognise how different approaches and ultimately create different outputs.

Dog fooding

As your organisation matures the scope of your design system may change. When you start to use a design system intended for the eco system on your main product, or try and roll out your product system to everyone else these concepts will indeed, bump heads.