Does your organization need a Design System?

The design system has gradually become an implicit standard for ambitious digital projects.

On the IT side, we are talking about industrialization and technical debt reduction.

On the Product side, we imagine more fluid releases.

On the marketing side, we hope for true UI consistency and more autonomy.

But behind this demand are very different realities. A design system is not a simple graphical deliverable. It is an internal product, with governance, backlog and operating cost.

It is relevant when responding to a scale issue: homogenizing a complex digital ecosystem, aligning several teams, structuring a brand on multiple devices....

On the other hand, in many contexts – a single site, a limited team, a constrained budget – investment can be disproportionate.

So the real question is not: Do you need a design system?

But well: does your organization have the maturity and scale to absorb it?

Why this question arises (and why it is strategic)

In many organizations, the topic emerges when the complexity begins to affect the teams.

IU debt slows down developments. Several digital devices coexist without a common framework. Marketing contributions become difficult to channel into CMS. Visual regressions accumulate.

At this stage, the temptation is strong to seek a structural solution.

The design system then appears as an obvious answer, almost reassuring.

It promises to unify, rationalize, speed up.

But this evidence is often based on a shortcut: to confuse the need for coherence and the need for industrialization.

However, industrialisation implies a sufficient scale – in surfaces, in teams, in frequency of delivery – and a real ability to govern an internal product over time.

Before investing, it becomes essential to objectify the situation: what level of structuring is really relevant to your real context?

Before deciding: what exactly are we talking about?

In many projects, terms are used interchangeably. This is often where misunderstandings begin.

Graphical chart: brand identity (and product-side limits)

The graphic chart defines the logo, colours, typography, iconography, rules of use of the brand.

For example:	However, it does not specify:
Licensed logo variations	How to structure a complex page
The main and secondary colours of the brand	How to manage component variants
The rules for typography and iconography	How to avoid UI regressions at each sprint

For a CTO, the charter does not deal with technical debt or velocity. For Marketing, it does not guarantee the consistency of blocks in CMS.

She's laying an identity base. It does not structure a digital product.

Guide Style: UI rules ready to apply

The guide style goes further. It formalizes interface rules: buttons, forms, tables, grids, basic accessibility rules, do/don't.

There are concrete guidelines: when to use such pattern, how to prioritize titles, which variants are allowed.

For example :

What size to use for an H1, H2 or H3 title in an editorial page

When to display a primary or secondary button

How to structure a form to remain legible and accessible

In a simple context – a team, a site – it is often largely enough to align practices without making the organisation more complex.

It provides a framework, without requiring heavy governance.

IU kit: Assets that accelerate... but rule nothing

An IU kit (often under Figma) includes components drawn with their variants.

It is an accelerator in the design phase and facilitates the transmission of work between designers and developers.

For example:

A button in several states (normal, hover, disabled)

A card produced with different variants

A navigation component ready for reuse in models.

On the other hand, without documentation of use, without versioning and without component library in code, it does not install governance.

Each developer can interpret differently. Tool helps. It doesn't structure.

Design system: a complete product

A design system changes scale.

It generally includes:

• a component library in code (often documented in Storybook),
• Token design (colours, typography, centralized spacing),
• formalized IU patterns,
• detailed documentation for use,
• clear governance (ownership, dedicated backlog, versioning).

In the most mature organizations, the design system can also integrate cross-cutting requirements such as accessibility or webperformance, directly into the components.

For example :

An accessible and already tested button component on all media

A grid and partitioning system shared between design and development

A form component directly incorporating good accessibility practices

It is a living product, with a roadmap and evolution rituals.

It is a lever of industrialization, a time-to-market accelerator and a framework of autonomy – provided it is truly integrated into CMS.

"A design system goes beyond the site. It's the company's visual DNA."

Building a design system from the real: a reverse approach

An efficient system design is not decreed, but is built from real use.

In many organizations, the approach is to define a comprehensive system upstream, to create a clear framework before needs multiply.

However, this approach can be counterproductive when it remains too theoretical.

We experimented with a project at the agency for a major housing player. At the time of our intervention, the design system group was under construction. For our part, we were in charge of the technical redesign of an existing site: UX rationalization, block consolidation, Gutenberg structuring and formalization of a WordPress style guide.

The context could seem complex: a system under construction, a site being redesigned, several teams involved...

Yet it is this configuration that has given its consistency to the whole.

Rather than imposing a theoretical framework on the site, the design system group fed on the uses actually observed: components used, proven variants, technical constraints identified, nomenclature already aligned between design and integration.

In other words, the site powered the design system – not the reverse.

This approach anchors the system in validated needs, facilitates its adoption and limits the gap between documentation and operational reality.

A design system becomes more relevant when it formalizes an existing maturity rather than when it tries to anticipate it from day one.

Signals that indicate that a design system may be relevant

• When several surfaces have to be homogenized – corporate site, intranet, application, transactional path – duplication becomes visible. For example, we have seen contexts with more than twenty variants of buttons and about ten types of cards for the same group. At this scale, each change produced becomes a cross-cutting audit. A design system can then structure the whole system for a long time.
• The multiplication of teams is another indicator. From three to four teams working in parallel, the design–dev handoff becomes a recurring friction point. Common language — shared tokens, versioned components, centralized documentation — secures deliveries and reduces interpretations.
• The delivery rate also counts. When releases are weekly or daily, reuse becomes strategic. Assemble rather than recreate, test once to deploy everywhere: ROI becomes more tangible.
• Another signal: inconsistency already costs time. On an e-commerce project, nearly 30% of the time front was absorbed by the correction of differences of styles. The establishment of a joint bookshop has reduced these corrections by half in a few months.

A design system becomes rational when inconsistency already costs money.

Finally, a design system must be ready to make it live. An identified owner, a dedicated backlog, rules for adding components: otherwise, the initiative blows. The subject is not only technical, it is organizational.

Signals that invite to delay

Conversely, some contexts call for more pragmatism.

• A one-shot project or a tight budget can make investment disproportionate. In this case, a clear guide style and some robust components often cover the essentials.

"If you have a one shot project and a single site, a design system is simply not depreciable."

• A single digital surface, driven by a single team, does not always justify heavy governance. A well structured WordPress theme can effectively meet the need.
• Very unstable needs also constitute a brake. Documenting patterns that will disappear in three months generates a "museum effect" difficult to maintain.
• The absence of clear ownershipAnother warning signal. Without identified responsibility, "out-of-system" variants multiply and the source of truth gradually blurs.
• Finally, the stack must be aligned. If the front does not properly consume the tokens design or if the CMS does not allow to frame the edition (blocks, templates, variants), the system will be bypassed — Sometimes from the first weeks.

The relevant compromise: the topic with safeguards

In 80% of cases, the reliable car remains more suitable than the assault tank.

In these contexts, the question is not to reproduce the standards of the major groups, but to adapt the level of structuring to the operational reality.

In concrete terms, this means standardizing foundations: colours, typography, grid, spacing.... Then formalize 10 to 20 key components – buttons, forms, cards, navigation, tables – actually used in the project.

Each component has clearly framed variants.

Creating a new variant follows an explicit rule.

Freedom exists, but it is framed.

In our WordPress projects, this approach takes the form of a structured theme based on Gutenberg and the Full Site Editing (FSE):

• coherent global styles,
• useful custom blocks,
• robust editorial templates,
• reusable patterns,
• framework of editing options to limit drifts.

This framework ensures sustainable UI coherence, secure marketing autonomy and control of technical debt, without introducing heavy governance or creating an internal product to be maintained independently.

It is not a question of giving up structure, but of industrializing to the extent of the real need.

In many organisations, this intermediate approach generates more value than a comprehensive design system that is difficult to make live.

If you go on a design system: some survival rules

Even before defining the first components, a condition must be met: the decision must be organisational.

A design system becomes really relevant when several factors converge – multiplication of surfaces, teams working in parallel, sustained delivery rate, already measurable cost of inconsistency – and when explicit governance can be put in place.

Without this convergence, the risk is not technical failure, but progressive shortness of breath. To maximize adoption and sustainability opportunities:

1. Start with a real UI audit to anchor the approach in existing rather than theoretical ideals.
2. Define a clear MVP scope (10-15 components covering 80% of uses) in order to avoid catalogue effect.
3. Centralize useful and pragmatic token design, without overcomplexing the structure.
4. Document to help decide, not just to describe: when to use a component, when to avoid, what accessibility and QA rules apply.
5. Clarify ownership and contribution rules : dedicated backlog, formalised arbitrations, source of unique truth.

Do not seek initial completeness. Even mature design systems are constantly evolving.

On a multi-team project, the main block was not the quality of the components, but a blurred handoff. Clarification of responsibilities and contribution rules was sufficient to significantly reduce off-system creations in a few months.

The right choice is the one you can maintain

The design system is neither a mandatory standard nor a bridle of designers. It's a strategic tool. But like any strategic tool, it only has value if it is aligned with organizational reality.

In the right context, it generates a real leverage effect.

In other cases, a structured WordPress theme or a well thought out guide style brings more value with less complexity.

If you hesitate between system design and structured theme, the simplest often remains to objectify the situation. The goal is not to push towards the most ambitious solution, but to the one that will really serve your organization over time.