Simply put, a Primary Design System is a set of common rules, constraints and principles implemented in website design and code. It’s a library of components that can be reused in the building of a website or digital tool, a multi-site web estate or even a suite of distinct brands sharing a technology platform. They differ from designs systems, in that they are un-opinionated and unbranded, and can be used to power multiple branded design systems.

Primary Design Systems are guided by pre-set, clear standards that determine how they behave, how they can be configured and how they should be used. Critically, they are unbranded, which allows them to power multiple brand identities when they are applied and bring clear standards of branding and user experience to each brand, market instance and breakpoint.

More broadly, governance frameworks help them evolve and thrive.

Primary Design Systems vs design systems

Say you run the consumer division of a multi-national multi-brand consumer health or FMCG provider. You look after 20 brands - each having its own visual identity, content strategy, audience and sales approach. You also operate in 30 markets, many of which server multiple languages, let's say 30 languages in total.

Your marketing teams need to be able to adjust messaging to both brand, local and language needs. But at a global level you need brand consistency, publishing efficiency and governance. And your technology colleagues need a single platform that can serve all markets but be maintained and upgraded in one place.

A design system can easily handle the execution of a single brand across multiple territories and languages, using techniques like Drupal multi-site and Acquia Site Factory. However, that still leaves you with 20 web platforms to support.

A Primary Design System (PDS) is unbranded, and less opinionated than a normal Design System - as it must be used across various brands. Design patterns are created, tested, evolved and maintained within the PDS. For each Brand, and Brand Design System is created - where the MDS is deployed to a lead brand instance, and has brand specific stylings, typography, logos etc applied through configuration.

Configuration is key here. Because an MDS model stores brand specific settings as configuration and content, the code remains identical for all brands tenants of the platforms. One platform, one point of maintenance and upgrade.

What they are not: guides vs systems

Primary design systems share a space in the design world with other approaches that have similarities. Many brands produce style guides - we’ve heard them called brand books, playbooks or build guides - however, a guide is not a system. 

Guides allow greater interpretation when applied. They are not rule driven, but approach driven. Systems, on the other hand, have rules that allow them to perform predictably no matter how they are applied. There’s no right or wrong in choosing a guide or a system, but the choice is important.

Guides are powerful where there are diverse use cases - perhaps too diverse to be brought into a single approach, or where the guide might need to cover multiple technology platforms with varying behaviours. Guides help promote a ‘best effort’ consistently. Crucially, guides can’t be delivered by a technology platform unless there is bespoke development. This limits re-usability, productivity and consistency.

Systems are rule driven. They can be driven by a single technology platform (we use Acquia Site Studio with Drupal, for example) and this means that the library of components will always behave predictably. Rules sound kind of boring but allowing the re-use of components delivers an infinite variety of creative options in displaying, ordering, re-ordering and optimising the content you wish to present to your customer. Rules set designers free.

Design systems are not templates. Templates dictate the layout of a page. Design systems provide content and layout components that deliver broader flexibility than a template. If you want to make a change to a template, you need to go back into development. Design systems allow the change of layout without development.

Why have one: the use case

Most marketers want to publish content in ways that support commercial goals and consumer needs, rather than ways governed by their technology. They want to be able to adapt content when changes in their commercial strategy occur, or to maximise opportunities presented by new customer insight. But they want to do all of this within a structure that is brand consistent and delivers best practice in user experience. 

Primary Design Systems, when implemented correctly, can achieve this goal in the following ways:

  • Gaining entry to your marketplace. If you need to create 20 market websites in 10 languages quickly (we’ve developed design systems that drive up to 170 brands across 1,500 websites), then design systems can help get you there sooner than building standalone market-instances, websites and digital tools. Re-use drives productivity, and that gets you to your customers more quickly.
  • Gaining knowledge about your marketplace. Your design system allows non-technical marketing staff to execute content publishing without going back to the development team. So if you are interested in executing a series of agile marketing sprints, with content optimisation driven by A/B testing, Primary Design Systems give you the tools to experiment and be creative - without burning the marketing budget on development tasks that might eventually be discarded.
  • Gaining reach across your marketplace. Reach might mean accessing customers in new markets or languages. It might mean extending messaging to groups you previously didn’t address through poor accessibility. Reach could be bringing an improved user experience and consistency of experience that attract customers who previously would not have engaged, or bringing new products, campaigns or content propositions to your marketplace in a way that opens you up to opportunity. 

Primary Design Systems help solve practical barriers to new opportunity for marketers. They embed the stuff you want - the good semantic markup that search engines love, the accessibility, and brand consistency - while giving you the freedom to express content in ways that might not have been predicted when your platform was first built.

Prioritising the Why: customer first

Any marketplace is filled with human beings seeking value. Primary Design Systems are rooted in the needs of the marketplace they serve - they require a deep understanding of the inhabitants and what makes them tick to be able to deliver this value. 

Building a Primary Design System starts with fundamental questions:

  • Who is our audience?
  • What do they want; what benefit will they achieve from engaging with us?
  • To help deliver this, what do we want them to learn; what do we want them to do?

As a result, effective Primary Design Systems are opinionated, to a greater or lesser degree. That means they are intended to be used in certain ways for certain communication goals. They will have been developed through an audit of real content. The communication patterns should be ‘baked-in’ with authentic users in mind.

When we ignore this, users get cookie-cutter experiences that don’t treat them with respect. Everything starts looking eerily similar, and slightly ill-fitting. Why would we expect users to engage with us, when we cannot be bothered to engage them in the language and content structure they need?

Beware approaches that ship with their own inbuilt design system. It won’t have been developed with your business’ use cases in mind and might encourage laziness.

So far so good. Hopefully what we’ve covered in this article resonates with you. However, we’re never short of an opinion here at Coherence. Here are some things we believe in:

Primary Design Systems are documented

We start the Primary Design System process through audits of content and gathering of content requirements. As soon as it’s feasible, we start to build our Functional Design Specification (FDS). This document covers:

  • The design patterns to be used
  • The branding environment they live in (colour palette, typography)
  • Global system behaviours (grid system, padding and margin behaviours)
  • Component configuration states (text alignment, image positioning, elements that can be shown and hidden, background settings)
  • Responsive behaviour across each breakpoint

These are the essentials any visual or brand designer will need so they can design to the technical platform that will publish the Primary Design Systems. Designers want to design. Far from being a restriction, Primary Design Systems help inform designers on what can be done. This offers freedom, rather than limitation. It also prevents the circular “what can I do…well what do you want to do?” discussion that so often takes place between designers and technologists when they begin work on a discovery-led activity.

These features are not enough though. The FDS should also give us:

  • Typical use cases for each pattern
  • Examples on how they can be used in situ
  • Guidance on how they are used as part of a content design process that considers user need and communication outcomes
  • Governance procedures that help us understand how, when and why a pattern might deserve to be included in a system, when not, and who decides

The FDS is technology agnostic. It could be delivered in any front end technology that supports standards driven coding - semantic markup for example, or accessibility standards. It acts as the spec document that informs the visual design process. Any visual designer using it correctly should be confident their work will render accurately when implemented. 

Primary Design Systems are implemented


We take the position that any design system is, by its nature, implemented in a front-end technology that enables it. For this we use Acquia Site Studio powered by Drupal. However, Primary Design Systems are rendered in other technologies such as React or Swift depending on what is being built.

While the FDS is technology agnostic, the Primary Design Systems itself ultimately cannot be. This is important, as if your Primary Design System needs to cover multiple technology platforms - front of house apps as well as back office systems for example, or legacy applications built in technologies that don’t lend themselves to supporting component-based libraries - trouble will ensue.


For a start, it will be harder to apply the system consistently, as the technologies in use will bring varying capabilities. The rule-based nature of the system will be undermined as the underlying platforms simply behave differently. The designer then lacks confidence on how their design will perform. In this scenario, style guides can provide greater flexibility. They allow the ‘cracks’ in the platform to be ‘papered over’ through looser definition.

Naturally, this happens at the expense of consistency, re-usability and productivity.

Primary Design Systems are usable

We develop Primary Design Systems to be used by non-technical content editors including marketers, content developers and visual designers. This means the underlying technology platform must deliver standards based front end code without the content editor needing to understand markup structures.

For this we use Acquia Site Studio, which provides a drag and drop interface that allows anyone with content editing training to assemble or reconfigure pages once the platform is in place. We don’t stop there though.

Primary Design Systems need to be usable to be useful

To be usable, the system should not have too many components, with highly refined use cases, so that an editor is confronted with a bewildering array of very specific patterns. The components need to cover all use cases but not fragment them. 

On the other hand, it might be tempting to create ‘all singing all dancing’ components, which are limited in number because they have sophisticated configuration options that allow them to cover a wide set of use cases. Again, this brings complexity which reduces usability.

We are looking for the sweet spot between coverage and usability, because ultimately we want marketers to be able to use Primary Design Systems to interact more easily with their customers.