Design systems: using the name in vain

Design systems are all the rage.

They help your business unify your customer experiences across all touchpoints.

This helps users gain familiarity with your range of products and services whilst allowing you to manage design at scale. Now, more than ever, knowing what a design system contains is important, as is understanding wherein the journey you are towards creating one as this contributes to your design maturity as an organisation.

We’ve nailed down the following definition and for a more in-depth write-up about them you can take a read of my blog on design systems and how they drive business value:

“A design system is a product of design that is centrally managed with rules and clear standards that articulate what is permissible when building and delivering any application, product, service, advert or system for your brand. They’re living organisms that serve as the source of truth, allowing you to manage, design and deliver at scale. A design system is not actualised until it has been applied to a live environment.”

Despite their virtues we frequently see the term design system used in bad faith – spotting this is important. So, how do you spot if what you’re being told is a design system is really, well, a design system? That’s tricky, but here’s five things to help you get started.

1. A Sketch file – or any file - is not a design system (but it’s a good place to start) 

A design system must be a living, breathing entity and applied in the context of your products and services - not under lock and key - so people actually experience it. Creating, documenting and managing your product is a good thing but it doesn’t mean anyone is actually gaining benefit from it other than your design team.

What you need to make this happen is to make sure it will be adhered to, and interpreted accurately. You also need company-wide investment, alignment and culpability around using it. This requires hard work to ensure it’s respected as much as traditional brand guidelines. In these situations, having a C-suite advocate really helps to create alignment organisation-wide.

2. You cannot have multiple versions

You need a single central shared source of truth which is understood, used and controlled – ideally by a team in their own right who oversee other teams in your business using it. This means each product or service offering you have should not have its own design system.

A design system needs to be adhered to in the same way that brand is. If something needs to change a central governance team (often a Design System team in its own right) should be the one to make the decision. In some instances, a different way of working with design is fine, it’s just not a design system you’re dealing with.

3. A code-based framework is not a design system

React, Vue JS and Angular have an ability to structure the way design is built into a design system but without the proper controls that doesn’t matter. Your structure will crumble.

In isolation neither frameworks nor governance do all that’s needed to ensure a design system is technically integrated as well as overseen.

4. It cannot be a static artefact that’s open to interpretation

A design system has to be technically integrated and connected to the live environment. Without this it’s easy for people to interpret your design system how they please. Treating it as a living breathing thing – i.e. a product in its own right - prevents it from breaking and minimises the risk of inconsistent artefacts going live.

Equally, just having a website or live location called ‘Design System’ doesn’t mean you are utilising a design system, it means you have a style guide or design repository on the web.

Even if it contains design and research to support the design decisions and offers rules on usage but it isn’t live anywhere, it isn’t a design system.

What’s lacking is the rules, governance and documentation supporting it alongside real-world application to your products and services.

Here’s a good example that demonstrates the hard work required to connect both the build with the design.

Quote from the article:

Designers render components into Sketch directly from the codebase, allowing them to access the most up-to-date resources of the Design System at any given point in time.

5. It has a bad title: is what you have both a design, technical and people framework?

Does your design system try to boil your organisation’s proverbial ocean? Design systems are complicated enough without housing all touch-points across the design teams within your business. A design system is about the design and development, the rules which frame it and the models set in place to control and deploy it. 

Taking a step back

It’s worth remembering that not everyone needs a design system, just make sure the name isn’t being used in vain. This can create confusion and ultimately cost. Likewise, if what you think you’re spending money on isn’t in fact a design system then you’ve got a problem.

That said, the points I’ve mentioned above are all necessary elements of bringing a design system to life. Although, only when they’re working together harmoniously to deliver great user experiences are they doing the job of a design system. What determines your ability to refer to your approach to design as part of a design system is your ability to deliver it and govern it across a potentially large digital real estate. This delivers the best possible experience to your users which makes for better human outcomes. 

Remember there isn’t one way to deliver a design system. It’s about understanding how specifically a company should run their products in order to operationalise design using such artefacts as a design system to manage and scale.