“Lies, damned lies, and statistics” is a phrase describing the persuasive power of statistics to bolster weak arguments.

Adoption statistics, when used as a blunt instrument are often a bad measure of design system success. Those of us that work on design systems know this, but often the people around us don’t.

On every system I’ve worked on we’ve been asked for a single adoption metric that represents how well we are doing. Conceptually, this makes total sense. The kind of reporting an org is used to are generally more tangible…number of sign ups, number of daily active users, number of transactions, number of training courses run, you get the idea.

But design systems, being extremely complex beasts and adoption being one of the most nuanced metrics you could track, we often result to providing numbers that mean nothing to us as a team. They are just for reporting up the line.

The trouble is, once you’ve been doing this a few years you are going to hit 100% and the people around you are going to ask — if we’re at 100% why does it feel like we aren’t?

Adoption is not binary

To track an adoption there needs to be a clear and universally accepted understanding of what adoption means in the context of design systems. Or at least for your design system, in your organisation.

Tiered adoption

Every design system has a tiered model of adoption.

By this we mean, some teams:

• Can use the code, design and guidance, other teams may only be able to use the design, other teams may only be able to use the guidance
• Are not supported by the primary target output of the system. For example, using a different tech stack to what’s provided centrally
• May be predominantly using design tokens and not components because they are styling an existing application or third party SaaS
• May use the system simply as a reference point for design direction

At best, only direct adoption of things like components can really be tracked. When we put an over emphasis on this, it can lead to a situation where the team builds stuff that can be directly measured and not what is most useful.

While website analytics were a useful measure of guidance adoption, as documentation moves to an “in the moment” approach, through APIs being consumed by plugins or agents this will increase the amount of touch points to track for documentation only tier too.

Bad adoption

Adoption alone is not always something to celebrate. Teams that technically use the design system may use it so badly that capturing this as a positive does not feel ethically correct.

No form of adoption tracking can truly determine how well the system has been used, only what and by how much.

Examples of bad adoption may be:

• Using every component in the system that they can, but fundamentally going against the associated guidance. This is when teams think about the system as a UI library only
• Using components in an inaccessible way — for example deciding their form inputs don’t need labels so leaving the property blank
• Overriding components — If someone overrides a design system component they can theoretically do anything to it and it would still appear on any analytics platform that they were using the system

Can you really include bad adoption in your metrics if it doesn't lead to the desired customer experience?

Lack of organisational data on potential consumers

For a team to understand adoption they need to be able to understand two things as a minimum.

How much their thing is being used and the potential opportunity for use.

The adoption metric, which is often requested as a percent requires some knowledge of what 100% is.

As is stands:

• Most big organisations don’t know how many journeys or applications they have. If you work in an organisation small enough to know this, then you probably don’t have any issues tracking adoption, you can just look
• We often don’t know how many teams we have that are making things that could consume the system — this could be because they are either not doing any frontend or design work or because they don’t use the same tech stack
• On the Figma side, the teams data can be easily skewed by a single designer and Figma teams do not always map to real teams due to potential misalignments with the workspace, team, project boundary we need to work in

The only way teams in this position have been able track adoption is relative to itself. For example, more usage than last year, more teams than last year.

I will state this again, if you have no way to determine the potential users of the design system then you cannot provide the kind of adoption metric you’re likely being asked for.

Historic adoption

The design system exists on a timeline, by that I mean it’s an evolving thing. If it’s been around a while you may have hundreds of releases under your belt.

Adoption cannot simply be about “using the design system”, surely it needs to be “using a recent version of the design system”?

If we were to ask our teams if they use the design system, the majority will confidently say they do.

However, what I’ve seen in reality is:

• Using versions of the system that are anything from 1–7 years out of date
• Basing their own design system on top of the central one taken from a certain point in time
• Not keeping up to date with brand changes because they are too big to deal with

Where do you draw the line so you don’t include past adopters in your current stats?

Level of adoption

How much adoption is enough to really call something adoption?

Does a team need to use 5 components?

Do they need to use 1 token?

Do they simply need to have the design system npm package as a dependency in their app?

This line is something that teams are going to have to decide for themselves. But you need to ask the question and you need to have an opinion on it.

Is it fair to track adoption because someone has used a token to the same degree as 40 components, 5 patterns and followed the guidance?

If you don’t think so, what is the minimum amount of usage before you can call something adoption and how might you track that?

Adoption by discipline

Many disciplines use the design system, each one uses it in either a direct or indirect way.

For example:

• Designer adoption may be through Figma usage and website visits
• Content adoption may be through guidance and website visits
• Engineering adoption may be through component tracking during a build process
• PO adoption may be through guidance informing acceptance criteria

Some of the most meaningful change from using the design system does not come through the trackable parts.

Content design adoption is rarely trackable, yet has some of the biggest impact of any system for customers. How can you make sure you don’t over emphasise the importance of UI in your adoption metrics?

In summary

We cannot provide an indication of design system adoption unless we can decide:

• What we track and where
• How we report direct and indirect adoption
• What minimum adoption means
• If the quality of adoption matters
• How up to date teams need to be

What is actually valuable?

Many Design System teams have fallen into the “Adoption trap” in the last decade, not by their own choice.

While it is good to have an idea of how many teams or how much of the real estate is using a design system I do not believe organisations always have an adoption problem.

What they more likely have is:

• Compatibility / Interoperability problems — Teams that can’t use it
• Quality problems — Teams that use it badly
• Maintenance problems — Teams that never update it
• Legacy problems — Teams that are stuck in legacy tech that will take years to resolve

Many of these things are either beyond the direct control of the design system team or are not things that can really be tracked with traditional analytics.

Focusing on outcomes

Adoption tracking can be seen as focusing on output over outcomes. It puts the emphasis on quantity of use and encourages the team to focus on output driven tasks like, providing more things.

It is often used to justify the team's existence over anything valuable to customers. This as we know, is something that can come back to bite you later.

Rather than this, many teams have moved on to measuring things like:

• Sentiment towards the system
• Case studies on how long something took to rebrand when a team was using the system, reduction in lines of code or time to market
• Increase in customer sentiment or reduction in complaints
• Scoring better in quality audits or internal assessments

Some of these things cannot be accredited directly to the system, but the system plays into the overall outcome for customers.

This after all is what really matters.

The term “freedom within a framework” has been used in the context of design systems for as long as I can remember. Usually in response to some kind of misguided comment about creativity.

But what if we really dug in to what freedom in a framework really means to both you and your consumers.

When I think about freedom within a framework my mind goes to thinking about other human relationships such as marriage, partnerships or larger societal frameworks like laws and constitutions.

Are design systems like a marriage or a rule of law?

When I think about marriage, partnerships or indeed any type of committed relationship, there are rules that are entered into and agreed upon by all parties.

Different relationships may have different rules, but the people in them understand where the boundaries are, because societal norms aside, they co-created them.

In contrast, the laws of the land are assigned to us. Simply by being born we are automatically enrolled into a framework of rules and processes that we are told we must follow consciously and unconsciously throughout our lives.

Bad relationships

While some relationships have the mutual, co-created boundaries other people may be in situations where the dynamics are imbalanced.

At one end of the spectrum this can be down to differences in personality but at the other end this can mean controlling, manipulative behaviour from one party or the other.

Breaking the law… breaking the law

While we’re born into the frameworks of law and order, governed locally, nationally and in some instances internationally, we all break the law a little bit.

Even the guy who likes all the local police Facebook posts occasionally rides his bike on the pavement.

In contrast there are people that simply do not want to adhere to the imposed “laws of the land”.

This is not so much a linear spectrum, it can include both behaviour that many people would agree is unacceptable in any type of societal framework (that also happens to be criminal in the eyes of the law).

On the other side of this, there are groups of people that intentionally opt out of expected societal norms and live in self governing communities where the community itself defines the rules in which it lives.

These communities, while self governing, have constant reminders that they are still part of a wider society when something happens that forces the two worlds to collide.

There is always a balance of boundaries at play here, people generally know how far they can push something before it becomes too big to ignore.

This balance is often the difference between being left alone or having your doors kicked in.

What type of freedom within a framework does your design system offer?

Is your design system a balanced co-designed agreement that all parties enter into or is it a one sided controlling relationship?

Is your design system a set of laws that everyone is expected to follow without question? Will you police what people do and punish them when they don’t adhere to the rules they had no part in forming?

Does your organisation have other design systems popping up that follow a different philosophical approach to your central one?

These questions will help provoke a conversation you’re likely not having.

On the whole, what I see is a conflict. Design System teams believe they have a mutually agreed upon relationship with their consumers, while the consumers themselves can feel like they’ve been opted in to a new set of rules from their first day of employment.

If the consumers of the system feel that way, just like in society, there will be those that mostly follow the rules, those that intentionally break the rules and those that want to make their own rules.

While we work in a standards space, there is likely always going to be an element of “this is the way we do things around here” baked into your work, it’s kinda the point.

But what we must focus on is our conduct. To quote one of my favourite moments from the West Wing, Leo McGarry states:

“Now, we have laws, and they are difficult and they have to be enforced and it’s right that they’re enforced. But we do not strut…ever”

The essence of this quote hits deep. When we have to enforce design system standards we must do so without arrogance, without self-aggrandising. Simply, we must not make it about us.

Let’s all try and have more of a relationship where everyone involved knows what they’re signing up for. Have deeper conversations with consumers and most of all, stay humble and let the anarchy in every now and again.

I was pretty excited about this. Reporting on token usage – whatever your flavour, fills a big old gap in reporting this side of the system.

Woah, we’re token millionaires

I was pretty blown away by the numbers of inserts and instances of styles and variables. The numbers were much bigger than I thought they would be – at times in the millions, but hey, this is the first time I’m seeing this data. Maybe this is normal.

Hang on

I noticed one of our variable libraries had usage in the hundreds of thousands and used by about 80 teams. Great!

Well, this library isn’t published to anyone. The variables in this file are used to build components that are distributed, but the variables themselves aren’t.

Dog with a bone

This began a 3 week long investigation. When I say 3 weeks, 5 minutes a day for 3 weeks.

I can’t ever let this kinda stuff go, I have to find out.

I really do apologise to Figma support for my daily emails. I’ll buy you all a coffee one day.

The question(s)

How can a library that isn’t published be recording inserts?

Can we trust the variable and style numbers?

As there is no way consumers can use this library directly, it had to be through interacting with the components that use them.

The process

To test this I had to set up multiple new Figma teams. One to author a couple of components and a few variables and a couple of other usage teams, suffixed with the date of the test.

I named everything in a way that would be easy to isolate.

Component A uses variables suffixed with “a” and not surprisingly Component B uses variables suffixed with “b”.

In the usage teams I inserted each component and ran a few tests.

For example, In one team I duplicated each component 3 times. In another I duplicated the components and detached a variable, clicked a variable, typed 99 bottles of beer into a variable. Any combination you can think of I tested it.

Because analytics only refreshes every day, any action I took I had to wait until the next morning to see the results…

It turns out variable analytics seemingly takes 3 days to come through when components are 1 day. This meant I ruined my first 3 days of tests and had to start over.

In the background I was still speaking to support and Figma experts to get some thoughts and insights.

The theories to disprove

For the last round of testing I decided to predict the results. I recorded the exact actions I made to Component A and Component B so given a few scenarios I could predict exactly what the analytics would read 3 days later. Sure enough, one of the predictions was bang on.

The results

So the answer to all of this is about what I am calling passive inserts. I called them that because the consumer doesn’t know they’ve inserted them. It’s simply happened to them.

This is of course the opposite to an active insert – where a consumer has inserted a variable by choice.

Drum roll please…

If a component that contains variables is detached, each variable that’s used counts as an insert, every time it’s duplicated.

Is that all I hear you ask? Well think about how many variables a component might contain? 8, 16, 24, 48?

Even if you have low detach rates these numbers can sky rocket.

If a single component that has 24 variables is detached and duplicated just 5 times (maybe deployment screens at 5 breakpoints) then that’s 120 inserts just from one basic component.

I have estimated this is causing hundreds of thousands of passive inserts across libraries, even if the detach data is below 1%.

So in answer to my other question – Can we trust the variable and style numbers? The answer is no, not really, not yet.

The problem is a passive inserts are not an insert, it cannot count towards a story of positive usage because it’s coming from the negative action of detaching.

It makes total sense that these variables would be captured by instances, they become real instances in use at the point of detaching. They were just never inserted.

Capturing the data

For now, we’re capturing all of the raw data anyway. But we have decided to report on only 5% of variable and style usage.

Unless we can determine active inserts from passive inserts then I would be worried about presenting insert numbers to anyone.

What has been fantastic is to see the instances data. This is going to be a really useful set of insights to have.

If we want to change that text colour, it’s good to know it’s currently in use in over a million places!

I’m hoping that we’ll be able to differentiate this usage in the future and make variable and style numbers a bigger part of our design system reporting.

The design system community get really amped up when discussing tokens. Sometimes it feels like questioning someone’s token structure is like questioning their entire belief system.

I get it, someone once (potentially correctly) criticised my overuse of “default” and our relationship hasn’t been the same since.

Have a nice life Alan.

There’s loads of blogs, threads or posts that suggest reducing the amount of tokens you have as the ultimate goal.

Other articles demand you have enough tokens to retain granular control of everything you’re ever going to need to potentially change, seemingly until the end of time.

Well, I think there is space for both, even in the the same system.

Layers of definition

Semantic tokens, put simply, are assigning meaning to a value. A semantic token is describing what it’s used for, not what the value is.

But any description can be generic or specific.

If I ask someone to describe an object on the shelf in my room they may say “a brown book”.

If I ask someone to describe the book they would say “it’s an old copy of Brave New World by Aldous Huxley”.

If I ask a vintage book store to look at it they may say “it’s a first US edition of Brave New World by Aldous Huxley with significant wear and discolouration to the spine”.

How much specificity there is in a description depends on both:

• the level of expertise someone has
• how much the object needs to be described in context

If I paint a picture of my room, the book becomes part of a larger context. The only information I need about this object is that it’s “a brown book”.

If I paint a picture with the book as the central subject, then I really do need to get into every specific detail.

How does that apply to tokens?

I think a lot of us that work in this space try and retain a single level of magnification when structuring tokens. Loosely speaking, things like text, border, icons will have a similar amount of tokens in them and they’ll follow the same conventions.

What if our semantic token layer was more like a vari-focal lens?

What if we can mix the ultra specific with the ultra generic?

Action tokens

The system I currently work on has a semantic action palette which has almost component level fidelity.

By that I mean we have specified a token for every element of an action (background, border, foreground, focus-ring etc) in every state (default, hover, pressed, focus, focus-visible, disabled).

If one brand needs to change the border of a secondary button focus state, no problem — we’ve got a token for that. 140 of them actually — half of you just fainted, the other half said “only 140?”.

These action tokens feed the obvious components, like all variants of Buttons and Links. On top of that they style the interactive parts of Accordions, Tabs, Tooltips etc too. Pretty much anything that uses an html button or <a> under the hood. It’s more efficient than component level tokens for us.

Where this approach falls down is when someone just wants “the damn action colour”.

In Figma, because you can’t use a link component inline, or assign colour to a text style, a consuming designer has to find the very specific token that styles the default link, in order to simulate a link within content. In our case this is color-action-foreground-tertiary-default.

Shut up about default Alan.

We know this is annoying and encourages people to just use the colour picker in a fit of rage.

In other systems I’ve seen a contrasting approach. Actions described in an ultra generic, much simpler way like color-background-actionor color-text-actionwhich can be used all over the place.

This approach is useful for user comprehension — they are just much easier to find and understand. On top of that, they can reduce the repetition of assigning the same value to multiple states or elements.

For example if your backgrounds and borders, default, hover, active, focus states all use the same colour it can be tedious to create a handful of tokens where one could be used.

However, to me these tokens have the semantic emphasis in the wrong place. The primary semantic importance is action, not text or background. We’re not applying action semantics to text, we’re styling the foreground or background of a semantic element like a <button> or <a> .

I find this approach also leads to components containing a mix of semantic tokens categories that don’t effectively describe how to assemble the UI.

How often have you seen something like this? Where the action text colour can’t actually be combined with the action background colour and another token has to be used in place:

.button {
  background-color: var(--color-background-action);
  color: var(--color-text-inverse);
}

Can we have it all?

Because we already have the detailed usage tokens I wanted to get some of the benefit of the generic approach too.

Perhaps to help build components in one brand that defy the rules applied to all the others, perhaps to just aid fast and loose choices in unstructured design phases or even to just have a token that indeed was “the damn action colour”.

I’ve tried a couple of different routes.

Global layer

We have a global layer of tokens, well it’s so global it lives just outside the central system as it’s own thing. Perhaps we should call it it the Stratospheric layer… anyway, the tokens recorded in this layer are the absolutely undeniable sources of truth for any consuming library.

This layer does not go into any level of detail or specificity. It contains the pre-system named brand colours and fundamental UI decisions that would be true of any platform. These may include colour of default text and the colour of the default action. It would never include states, because states are a platform level concern.

To serve our needs we could simply expose color_action token at the highest level to feed both our default (ALAN!) action states and be available to serve the needs of some custom elements directly.

Generic layer

This approach is much like the global layer but the token is treated as both a sibling and a parent of the specific action tokens within the same library.

This might be useful if you have some extra needs for action colours, for example two colours of link that are platform specific — one an accent colour and one say, the colour of body text.

Here I’ve created some generic use action tokens before we get into the detailed ones. No doubt some of you are thinking this is just standard practice for us, but these types of tokens are often for internal use only, and not actually exposed to consumers.

{
   "color":{
      "action":{
         ==== GENERIC LAYER ====
         "accent":"value",
         "subdued":"value",
         
         ==== SPECIFIC LAYER ===
         "background":{
            "primary":{
               "default":"{color.action.accent}",
               "hover":"value",
               "focus":"value",
               "pressed":"value",
               "disabled":"value"
            },
            "secondary":{
               "default":"value",
               "hover":"value",
               "focus":"value",
               "pressed":"value",
               "disabled":"value"
            },
            "tertiary":{
               "default":"value",
               "hover":"value",
               "focus":"value",
               "pressed":"value",
               "disabled":"value"
            }
         },
         "border":{
            "primary":{
               "default":"{color.action.accent}",
               "hover":"value",
               "focus":"value",
               "pressed":"value",
               "disabled":"value"
            }
 etc etc etc etc
         }
      }
   }
}

Both of these approaches give us and our consumers a generic or specific token to use when needed. But what about the other benefit, when most of the states have the same value?

Common suffix

When most of the states have the same value it can feel tedious and unnecessary to include them all.

Hey we’ve all used “default” — Alan for the last time… for more than just the default state before right?

.button, .button:hover, .button:focus {
  background-color: var(--action-background-primary-default);
}

Well it’s just a bit of a lie isn’t it? Token people hate lies!

Just because they use the same value doesn’t mean they should all use the default token, default means default state not any state I want to look like default. I’m getting tired of this Alan.

But the intent here is valid, it removes duplicate CSS declarations that aren’t necessary to produce the same output.

While this adds even more tokens I’ve toyed with specifying some state tokens with an additional common suffix. It could be used as an alias for the other relevant states — or not.

For example:

{
   "color":{
      "action":{
         "background":{
            "primary":{
               "common":"value",
               "default":"{color.action.background.primary.common}",
               "hover":"{color.action.background.primary.common}",
               "focus":"{color.action.background.primary.common}",
               "pressed":"{color.action.background.primary.common}",
               "disabled":"value"
            }
         }
      }
   }
}

.button, .button:hover, .button:focus {
  background-color: var(--action-background-primary-common);
}

While it does add yet another token, it allows the consuming CSS or indeed Figma design to just use one value and just not lie about it. There can be no confusion if someone meant to use default for all states or they just forgot.

If it works, maybe we may consider excluding the specific tokens from the build for certain things. If you need to have the granular access later down the line, then the token structure already exist to make those kind of changes immediately.

What next

Remember the goal here was to consider side by side optional levels of specificity like a vari-focal lens.

Sure, someone may use a more generic token incorrectly because they are not a token expert. But it’s better than using a colour picker or source value.

Someone may use a generic token because they are effectively painting a picture of the room, the element doesn’t require that level of specificity for their use case.

Well, what I actually expect next is about 10,000 comments on this article.

Token people like commenting.

I have only blocked Alan.

To me, it‘s felt like everyone is juggling 3 different full time roles, but deprioritising two thirds of the work. Our backlogs are full of essential things we know we’ll never get to.

You could argue this is true of any product or service but with Design Systems and their multiple, competing stakeholders, it feels like there is a minimum expected output that is always significantly greater than the capacity of the team.

While this is partly due to a misunderstanding of the work, I believe this is primarily due to people, stakeholders, users or otherwise placing higher importance on the parts of the system that will help them or their area the most. Designers aren’t too fussed about minimising breaking changes. The last thing the Development Lead wants to hear about is a UI refresh. You end up in a unique position where almost everyone thinks you’re not doing enough.

What would a team that could be enough look like?

Rather than thinking about what a team make up might be in terms of traditional job titles, I was wondering what it would look like if you designed a team around the activities that could benefit from full time attention.

This idea breaks the Design System team up into 4 smaller squads and some cross cutting roles.

• Delivery squad
• Documentation squad
• Discovery squad
• Community squad
• Cross-cutting roles

Delivery squad

This squad is responsible for the delivery and maintenance of the “live” system. This squad contains 4 roles:

• Library maintainer (UI Designer)
• Library maintainer (Frontend Developer)
• Token design and management (UI Designer)
• Token design and management (Frontend Developer)

The library maintainers are responsible for:

• Continuous improvement of the performance and features of the design system
• Investigate and implement new technical solutions. For example, how we might use new features of tooling
• Manage and fix bugs

The token design and management roles are responsible for:

• Tokenisation of design, structure and naming conventions
• Management and distribution of tokens
• Management of token tooling across platforms

The delivery team are collectively responsible for:

• Multi-brand implementations of components
• Quality assurance
• Release process management
• Versioning and breaking change support

This team is technical, it’s less concerned about the “why” of the system and more about the quality and efficiency of the output.

It may seem like a stretch to consider Tokens or Library Maintenance to be a full time job but ask yourself, how much time do you spend on it now? What does it stop you doing? What does not having someone working on this specifically mean for the overall health of your system?

Documentation squad

Small but essential, the docs squad maintain the front door to the system and ensure users of the system can find what they need.

This squad contains 2 roles:

• Documentation writer (Content designer / Tech writer)
• Documentation developer (Frontend Developer)

The documentation writer is responsible for:

• Usage and technical guidance for the documentation website
• README content in repos
• Content governance, for example A-Z of terms

The documentation developer’s activities may include:

• Maintenance of the documentation website
• Creating and managing technical examples
• Management of design system hosting requirements

Collectively they will also make continuous improvements to guidance through active research and feedback from the design system users.

Discovery squad

The discovery squad is made up of 3 roles:

• Component and Pattern Design (Interaction Designer)
• Component and Pattern Design (Content Designer)
• Component and Pattern Design (Frontend Developer)

The discovery squad will focus on activities like:

• Creation of new components and patterns in a single brand
• Scope, name and API of components
• Working with contributors of new components and patterns
• Auditing existing component usage and documenting needs
• Creating component blueprints
• Creating prototypes and templates
• Testing and Research

The discovery squad is less concerned about the delivery side of the system and more focused on the how and why of the contents. Should something exist? What should it do? What stance do we have on this?

Community squad

The community squad is more of a group of individual roles rather than people that work directly together. It includes:

• Community Manager
• Service Designer
• Service Support

The Community Manager will spend their time:

• Being the point of contact for teams
• Looking out for adoption opportunities
• Actively looking for contribution candidates
• Recording community requests and feedback
• Fostering active community channels and spaces
• Organising events
• Running drop in sessions and workshops

The Service Designer will aim to:

• Understand and record the multiple ways the organisation delivers products
• Understand blockers to adoption
• Design governance flows and processes
• Define component and pattern lifecycle and statuses
• Define the Design System eco-system and boundaries

Service Support will have one of the most important roles in the team:

• Answering and directing support queries
• Helping users get up and running
• Giving design and development advice
• Creating bug tickets
• Recording user feature requests and enhancements

Cross cutting roles

On top of the specific sub-squads there are some roles that need to either be across everything, or will not need to be full time in one sub-squad.

• Design System Lead(s) (Product Manager / Design Lead / Head of)
• Delivery Manager (Scrum master etc)
• Brand & Design Language Expert (Graphic / Digital Brand Designer)
• Accessibility Expert (A11y focused hybrid design / developer)
• User and Customer Research (User Researcher)

The Design System Lead will:

• Set the overall vision for the Design System
• Define high level priorities and initiatives
• Create and balance the team roadmap
• Be the primary point of contact for the business
• Provide guidance and mentorship to the team

The Delivery manager will:

• Run team ceremonies
• Manage team workflow and output
• Assist with organisational blockers
• Keep an eye on team health and availability

The Brand & Design Language expert activities will include:

• Being the liaison with brand team
• Develop the Digital Design Language for each brand. This will be zoomed out, no component design.
• Define core system styles (Colour, Typography, Layout etc)
• Asset creation, management and distribution
• Creation of Digital brand guidelines (wider scope than the Design System)

The Accessibility SME will work with all members of the team on:

• Creation of new Components & Patterns
• Bug triage and fixes
• Quality assurance
• Create A11y acceptance criteria and testing requirements for team activity
• Liaise with internal users on Accessibility issues relating to the Design System

The Design System Reality Team

It’s unlikely your team will have headcount for 17 roles. That’s why this is a dream team, not a reality team.

While some of the more well known systems that many of us may aspire to have 25+ people working on them, I believe the average is more like 3–5.

From my experience, I have come to the conclusion that any Design System team, whether it’s 3 people or 30 is expected to deliver everything I have described above and more. While some areas of focus may be seen as a one time thing, much of this work is actually continuous.

Of course, each organisation will be different and each stage the system goes through will be different:

You may not need 2 people working specifically on tokens if you only manage 1 brand and 1 platform, but 5 brands and 3 platforms?

You may not need to separate groups of people creating new things vs maintaining the existing. However, why do so many teams struggle to go back and improve existing components, keep the libraries and guidance up to date, successfully add new things and shepherd contributions through? Usually the most immediate concern wins — and that is often dealing with bugs.

Of course, you don’t need 15–20 people to have a design system team. If you have 3 people, maybe your focus should be 100% on maintaining a core UI kit and nothing else. If you have 6 people, maybe you can take on your own custom guidance website or accept a couple of external contributions every quarter.

But consider all of the activities thast could be full time roles and be realistic about what you can and can’t achieve with the team you have. When we try and do it all, we spread ourselves so thin that the work we do, however brilliant, goes largely unnoticed.

The recent behaviour of the billionaire boys club to fall in line with the orange one, creating an immediate end to dedicated DEI and Accessibility work in both the US government and a growing list of big tech has created a new line in the sand.

Design Principles are not a new thing, a lot of organisations have them. When done right, they really do help guide people to make good decisions.

One thing I decided to do this week was to take a moment to record what I stand for and how I approach the work I do.

I’m going to use these as a way of explaining who I am as a designer and what drives me to make the decisions I do.

I hope to use my own Design Principles to compare against organisations I interact with, understand where they align and where they don’t.

My Design Principles are:

• Don’t waste peoples time
• Don’t leave people out
• Content first, always
• Know the cost of growth
• Be the voice of the user

What are yours?

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.

When I say behavioural, I am bundling a few things together.

On a component level:

• Semantic structure
• Technical UI implementation
• Accessibility
• Hierarchical variations

On a system wide level:

• Approach to form validation and error handling
• Focus handling
• Patterns for common interactions

You get the gist. Anything that affects how an end user interacts with the thing.

Oh Buttons, not more buttons

Looking at these Buttons, with the source Design System button on the left which one do you think Is following the Design System more closely A or B?

Of course it’s a trick question, I’ve given you no indication of anything but visual but you know I’m going to choose A right? Otherwise why am I writing this blog?

Let me give you a little more non-visual information.

Button A — Behind the curtain

• Uses the correct html <button>element
• Has a border — yep your button should have a border even if it’s the same colour as the background
• Has a focus state with over 3:1 contrast
• Has the same hierarchical emphasis as the source button
• Doesn’t meet the visual design language

Button B — Behind the curtain

• Is a f’in <div> mate
• Has no border — It’s solid, why does it need a border?
• Has removed the “ugly focus ring” with outline: none;
• Looks the same as the design system — what a win!

The effect on real people

The effect on customers or end users of these two buttons is dramatic, one is usable but looks off brand. The other looks right but is a pile of steaming poo and a genuine blocker for a lot of people to use.

It’s literally no competition.

Changing perceptions of being “on brand”

Still, on the brink of 2025 “using the design system” is synonymous with just making something look on brand. In many organisations when they can’t use the full system (both in design and code — hey it happens, even if you’re in a technical monoculture hellscape) you still hear about “using the design system to skin this UI” or “We’ll update the CSS to match the guidelines”.

Well guess what, the Design System is the structure, the Design System is the behaviour. The Design System is the guidance. That’s like, the main thing we do.

I don’t know about you, but I’d prefer someone “used the code only” or “used the design system to change the underlying structure of the experience” than simply camouflage bad implementations with visually almost correct UI.

But of course, it is absolutely no debate that visual cohesion would be very nice too ;) — This of course goes without saying, despite the fact I just said it.

So much of Design System design is the stuff you do before any theming is applied.

Firstly, I really like Figma as a tool. I don’t need to explain the impact it’s had or how dominant it’s become. You already know that.

With the popularity, the expectations on Figma are absolutely huge, I do not envy them one bit.

I can’t speak for the jobbing product designer but from a Design System perspective, the role of producer and consumer feel like they have somewhat reversed lately. We used to see Figma drops and think about what possibilities they could open up for us. Now we are so often just waiting and hoping for what we see as essential features and fixes – we’re the ones at the back shouting for “more boring stuff please”. We have such high expectations of features we need, we are often left underwhelmed when they actually arrive.

The Design System team I work with test everything out. The days after a feature is released we jump into Figma and see what we can do with it — is it going to solve that problem we’ve had for the last year…or not?

While lots of teams run with everything straight away, and I do envy that a little bit, 80% of the time we choose to do nothing. Are we just stuck in our ways? Are we the luddites in this scenario? Am I the Gareth Southgate of Design System Library Management? Maybe, but more often than not it’s because the release we’ve been waiting for hasn’t materialised in the way we’d hoped.

Our Design System consumers require a certain amount of stability and predictability to be confident in us, we are not willing to risk this to use the latest features if we don’t believe they work how they should.

Figma variables were obviously the most highly desired feature of systems teams for such a long time that this expectation was absolutely through the roof. Arguably the variables solution we got works very well for people doing product design work, it is arguably not quite there for enterprise scale library maintenance.

While we’ve had quite a few issues with variables and modes (we use them but we still don’t directly publish them to consumers because of these concerns) the focus of this blog is why we haven’t used variable modes to create a single multi-brand library. I know it’s totally possible, but it is it actually practical?

Overview

The key areas of concern were:

• Design System change management process and quality assurance
• The inability to control the release of NDA projects, such as acquisitions
• The inability to work on and control the release of rebrands

I’m going to focus on these key areas of concern, but the secondary concerns were:

• Scope of existing components may need to change to reduce performance issues of larger single brand libraries
• Performance impact of multi-mode in prototypes
• Complexity. The libraries are not just for visual designers or UI experts
• All existing “evergreen” Figma projects would need to be rebuilt from scratch
• Per-brand analytics reports are not possible
• Some components (usually ones with branded assets) require multiple brand variants anyway

Design System Management

Figma recommended a multi-library approach for different layers of a system. For example, creating separate libraries for:

• Variables
• Assets
• Styles
• Components
• Patterns

Each library has a very specific remit, and each consuming library has a dependency on one or more of the libraries below it.

Simply put, a change to a foundational element such as a variable or style will need to cascade up through all consuming libraries.

It’s unclear if this is still the recommendation, but it would appear that having variables in their own file(s) is considered good practice.

Staging a style change

The only way to ensure we can roll out a style change in a stable fashion is to stage that change in the consuming libraries before it’s released.

This is good practice to ensure you don’t release a change that doesn’t work as expected or causes design system libraries to be out of sync with each other. Not to mention there’s sometimes actual changes that need to be made because of the style update that can’t be done in the gap between releasing libraries.

This QA process has proved to be essential. In the entire time our teams Figma Libraries have existed, we have not had a single issue reported regarding issues from library updates and we’re proud of that.

The staging process

How we manage this currently is based on the practical limitations of Figma and the relationship between related libraries. It is far from ideal but it works.

Staging a style change looks something like this:

• Make a change in Styles (Branch)
• Duplicate the Styles (Branch) as a new file and publish to the team only
• Swap library in Components (Branch) to the Styles (Branch) copy
• Duplicate Components (Branch) with swapped library as a new file and publish to the team
• Create Patterns (Branch) and swap library to the Components (Branch) and Style (Branch) copies

Releasing that change looks like this:

• Merge Styles (Branch) into Styles (Main)
• Release Styles (Main)
• Swap library in Components (Branch) from copy to (Main) and accept changes
• Merge Components (Branch) into Components (Main)
• Release Components (Main)
• Swap Patterns (Branch) back to Components (Main) and Styles (Main) and accept changes
• Merge Patterns (Branch) into main
• Delete Styles (Branch) copy and Components (Branch) copy

Sounds fun huh? This is the “easy version”, in reality you need to loop over this many times.

If only there was a way to publish branches to team while keeping main public. Or the idea of grouping libraries as a dependent set that can all be staged for release together.

Using variables in this staging process

Variables, whether in (Branch) or a (New mode) cannot be tested in Styles (Main), Components (Main) or Patterns (Main) because:

• Figma does not allow you to swap variables
• We are not confident in third party Swap Variables plugins after reviewing their documentation. We felt those we reviewed may be too dangerous to introduce into our libraries — after all libraries are major assets of design infrastructure in an organisation
• Variables created in a new mode will be published to any user of the system — they can only be tested “in the open”
• Variable modes cannot be independently published (e.g. Mode A to all, Mode B to team), wow that would probably solve everything!

Simply put, we cannot have any confidence in how variable changes would affect consuming libraries because we cannot test any changes to variables before they are released to everyone. The first time we see them in components is after they’ve been published.

In our opinion, this approach cannot meet our internal standards for quality assurance of the system.

The inability to control the release of NDA projects and brand changes

Because of the practical limitations outlined above, all of the below would need to happen “in the open” and be available to anyone with access to the Figma libraries:

• Any rebrands or UI changes to existing brands
• Any modes being created for unannounced acquisitions
• Any additional modes (e.g. dark mode, high contrast, low contrast)

We would not be able to release a new brand on a specific date or stop people within the organisation being aware of the rebrand as it’s happening.

This is not about being overly protective of the changes, this is about not releasing in-progress, confusing or contradictory work when it’s not ready to be consumed.

The only way to handle these changes in private would be to create an entire duplicate set of libraries. When they’re done we’d either ask all users to switch all of their files when it was ready or remake all the changes manually in the main file.

This has some serious practical challenges for users of the system. Historically, it’s only something we do for major brand changes and only for the individual brand that’s been changed. The solution for everything cannot be to make a new library.

Manually re-creating the changes in the main library after designing and testing in a duplicate set will always be prone to errors. The actual release candidate will have never been tested. It’s likely that fatigue, memory and pace will introduce issues in the released version that didn’t exist in the duplicate.

Because a single library approach covers all brands, a major change to any one brand will be a major change to every brand.

In summary, with a multi-library set, it is almost impossible to test out new variables before you release them. This is simply not good enough for us to be confident in the quality of the libraries that are being released.

Last week, Figma released what I thought would be a bit of a silver bullet for some of this, the ability to copy and paste variables between files. I’ve had this blog in my drafts for almost a year and I thought I was going to be able to delete parts of it. That release however does not solve this problem, hence why you’re reading this now. EDIT: This issue was resolved the same day as posting this. Yes!

I don’t want to pile on to Figma for stuff like this, I know that library maintainers are not actually their primary audience and they’ve got a lot of features to ship. Almost all of us work on or have worked on products where we know important features are not prioritised. It’s just the way digital products work.

But when you do become the only possible tool to use for this type of work in a large organisation, and that organisation depends on libraries, this link in the chain is incredibly important.

So what about using modes for single brand libraries?

Having modes for contextual and theme adjustments for one brand seems a lot less problematic.

Things like:

• Dark mode
• Breakpoints
• Alternate layout contexts
• Regional or Language differences
• Sub theme e.g. minor audience based modification of the brand

When I think about what Figma released modes for, I think it was for this stuff.

While using and releasing modes still has all the practical workflow problems, working in a single brand library means there will be more privacy for rebrands and less impact for consumers of existing single brand libraries.

A change to one brand, is not a change to all. Nobody sees anything they shouldn’t see. Nobody uses anything before it’s ready to be used. It is still near impossible to quality assure the output — but there is simply a lot less at stake.

Maybe the idea of adding multi-brand into the mix was perhaps, a mode too far? Or is it simply that the tooling is just not quite ready for it?

Acknowledgements

I am painfully aware that Figma modes for multi-brand is a closer representation of theming in code.

Different organisation shapes and sizes will have a different view of what is or isn’t acceptable. For some, the positives may outweigh the negatives.

Using modes is no doubt quicker and less maintenance for a library team–The counter to that is that the burden should be on us, not our consumers.

I’m not suggesting modes won’t be the way to go for this in the future, I just don’t think it’s ready right now.

Michelle and Luke discussed their changing views on AI creating documentation for Design System components.

During the recording, Luke mentioned that Scott Riley had changed their mind, or at least given them a crisis of confidence about using AI for this.

From memory, this was largely in recognition that the actual process of writing the documentation is in itself a useful act and a vital step in the process.

This rang true with me, the last component that made its way into the design system I work on used the documentation process to define the scope of the component, before we made it.

Lightbulb moment

I’ve worked with a lot of developers and test engineers over the years, my brain went ping, this is not a million miles away from the idea of Test Driven Development (TDD).

BrowserStack summarise TDD as “a software development practice that focuses on creating unit test cases before developing the actual code”.

This process has a lot of benefits, one of which being that the process of writing the tests actually helps define in more rigid terms what the code is supposed to do and helps highlight any gaps in the design early on.

The process has a secondary benefit, you don’t have all your tests to write at the end – a stage which is often missed by tight deadlines, sometimes even ignored.

What’s that got to do with Design System docs Dave?

The crossover with documentation in design systems now seems quite obvious.

You are likely already following a design approach that focuses on specs, scope and draft APIs before you put cursor to artboard.

Why not write the actual guidance before you start designing visually?

We could call this Documentation Driven Design (DDD).

Writing your documentation first will help:

• Define the scope and intent of the thing you want to make
• Expose multiple use cases and contexts you may not have considered otherwise
• Work with all disciplines within the team on something before anyone starts making anything

I believe the benefits of this approach will mean:

• Design and Development build to the long form guidance – meaning less chance for misalignment
• The team is forced into the context of how they will explain the decisions they’re making to the consumers of the system
• The guidance can be published or researched with before a design or coded component even exists. This gets valuable information out there sooner

If we go back to the original topic of the use of AI in Design Systems perhaps DDD would actually be the ultimate prompt for generating useable designs that actually met your requirements.

While I’ve been encouraging this kind of process without really realising it, next time we create something new I might try formalising Documentation Driven Design.

How about you?