```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2Fa5a4089d-0c6b-4961-937d-ea98297f4e36.jpg?alt=media&token=d1f218b7-54cc-40c6-b7d6-a58f079793da","id":"a5a4089d-0c6b-4961-937d-ea98297f4e36","width":3240,"height":2160,"filename":"atomic-design-thumbnail.jpg","type":"image/jpeg","caption":"The atomic design process with a scribble through it","border":false}]}
```

I think it might be time to reconsider whether atomic design helps or hinders the creation of designs and systems.

It’s been the de facto rule for looking at interfaces for a long time, but I find that sometimes it can actually create more confusion.

Atomic design is great! The issue we face though is that it’s best suited for frontend code architecture, and not necessarily within design files. It helped me understand the construction and component composability at a foundational level, but I want to flip the script a bit.

> Before we start, I’d encourage you to read the blog post if you haven’t yet: [https://bradfrost.com/blog/post/atomic-web-design](https://bradfrost.com/blog/post/atomic-web-design/).

### The structure

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2F50457a6c-64f5-4408-8d7c-545d3603a2a1.jpg?alt=media&token=79c51ab0-6b00-4696-9f6e-5ea16a4839bc","id":"50457a6c-64f5-4408-8d7c-545d3603a2a1","width":3240,"height":2160,"filename":"atomic-design-flow.jpg","type":"image/jpeg","caption":"The atomic design process","border":false}]}
```

Until now, we’ve followed the “atomic structure”, with the proposal being:

1. Atoms – Singular components (button)

2. Molecules – Groups of atoms (input + button)

3. Organisms – Groups of molecules (menu)

4. Templates – Page layouts

5. Pages – Template instances, custom content

I find it breaking down for a few reasons:

1. An atom in HTML isn’t an atom in design

2. Atoms are way more flexible than their definition

3. Organisation within design tooling can be confusing

4. Translating “templates” into design implies components – not technically correct

### The challenge

An atom in HTML isn’t an atom in a design tool.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2F2d9fc601-2a47-4cdd-8a9c-0fd79d92cfbc.jpg?alt=media&token=0bc61b33-1a8a-4dc1-b710-6324f2981ef0","id":"2d9fc601-2a47-4cdd-8a9c-0fd79d92cfbc","width":3240,"height":2160,"filename":"atomic-design-code.jpg","type":"image/jpeg","caption":"A vertical side by side of a code block showing an HTML input field, and the same element but in Figma.","border":false}]}
```

Call me particular, but an HTML input field in HTML is one thing, but in Figma at least two. We have the frame on the outside, and the text node inside. This is technically now a molecule, but we must convince ourselves it’s an atom.

Let’s say this input field now had an email icon.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2F8ac0c1ab-8fff-4a8f-a5b4-2167808b2a22.jpg?alt=media&token=cc9b93dd-79a8-4f9c-b09c-05d968fda6e8","id":"8ac0c1ab-8fff-4a8f-a5b4-2167808b2a22","width":3240,"height":2160,"filename":"atomic-design-layers.jpg","type":"image/jpeg","caption":"A vertical side by side showing an HTML input field with a <span> for an icon, alongside the Figma version","border":false}]}
```

```
This is just one way of coding it, and there's probably a better way!
```

Is that two elements or three? In HTML it could be either, depending on whether you position the icon within the field using CSS or have it in the HTML.

The structure in design and dev is inherently different! As we strive for 1:1 design/code parity, our ambitions fall apart when think about these (simple) atomic use cases.

This then cascades down/up to our larger component sets and the concepts become harder to grapple with.

### Props

The more we think this through, the more challenges we find.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2Fab10d71c-4024-4b25-9b4d-54447a167c40.jpg?alt=media&token=68f1fb65-4b55-41c2-aec2-eab714890465","id":"ab10d71c-4024-4b25-9b4d-54447a167c40","width":3240,"height":2160,"filename":"atomic-design-props.jpg","type":"image/jpeg","caption":"A component and instance in Figma of an input field, alongside the properties panel. The panel is showing a boolean prop for toggling on/off an icon.","border":false}]}
```

What about component props? There have been calls to include tokens/styles as a layer beneath atoms (subatomic, ions, quarks, etc) but a prop is a way to think about an "under layer" too. I'm confused.

Props can increase or decrease component contents, often changing an atom to a molecule, or a molecule to an organism. If we decide to ship the visibility on or off, we'd also be changing the composition of its atomic structure.

### Design tools

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2Ffc1ca369-23b5-4210-8e38-f121ee23f394.jpg?alt=media&token=d391cb54-f880-4777-ab3c-7d3fd6e9481a","id":"fc1ca369-23b5-4210-8e38-f121ee23f394","width":3240,"height":2160,"filename":"atomic-design-pages.jpg","type":"image/jpeg","caption":"A side by side \"or\" proposal for page structure in Figma. The left side showing an atom-based approach, the right showing a group system.","border":false}]}
```

The organisation of assets within design tooling can be confusing.

I’m asked a lot about the best way to organise an atomic system and I don’t think there is one, because we gain little benefit from introducing atomic page/frame/section structure.

With this framing, it becomes more cumbersome to navigate, rather than structure aiding comprehension.

Is it more beneficial to group by intent, or by underlying atomic concept? I’d go for the former because of how you navigate elements within design tools.

Understanding the structure of a component does not equal how it is organised, and that’s totally fine!

### Templates

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2F73374515-79d2-4936-a0c6-21fa0baa3340.jpg?alt=media&token=067e2ed6-98b6-4727-9799-22349b693395","id":"73374515-79d2-4936-a0c6-21fa0baa3340","width":3240,"height":2160,"filename":"atomic-design-screens.jpg","type":"image/jpeg","caption":"A web design mocked up in Figma, presented as a component.","border":false}]}
```

Translating “templates” into design implies components, which is not technically correct. I'm sure you've turned a full screen into a component for repeatability before!

I dream of a world where non-component templates can be built within design tools, a bit like a synced block in Notion, but we’re not there yet.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2Fdd44b7ab-a553-48ae-8140-b32331eea1d1.jpg?alt=media&token=03232089-8414-4e2b-aa1f-8a47941180c0","id":"dd44b7ab-a553-48ae-8140-b32331eea1d1","width":3240,"height":2160,"filename":"atomic-design-content.jpg","type":"image/jpeg","caption":"3 identical web designs in Figma, but with different imagery.","border":false}]}
```

It means that to follow the template workflow, all templates must be components, which disrupts the system.

### The proposal

Maybe I should propose something!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2F1xlNiLqg4sqANNtNX8xw%2Fec7fcdb2-9dd9-41ee-8b95-b3ee3d176824.jpg?alt=media&token=fd7b5102-1fe6-44bd-b9db-a2fe9dffa327","id":"ec7fcdb2-9dd9-41ee-8b95-b3ee3d176824","width":3240,"height":2160,"filename":"atomic-design-proposal.jpg","type":"image/jpeg","caption":"Luis' proposal for simplyfing atomic design","border":false}]}
```

I think we can simplify by flattening atoms, molecule, organism into a single “component”. Those component groups are then called “patterns”. Template is still tricky, but we need a term for full designs, hence “screen”.

As you can see, I haven't named this. Perhaps it doesn't need a name 🤔.

I do however, believe an acronym will work: **CPS**.

**C:** Components\
**P:** Patterns\
**S:** Screens

> Further reading
>
> This was also explored in Andrew Couldwell's book [designsystemfoundations.com](http://designsystemfoundations.com), where he proposed:
>
> 1. Screens
>
> 2. Features
>
> 3. Patterns
>
> 4. Components
>
> 5. Foundations

## **Where do tokens fit in?**

After publishing the original post, I received a few responses asking about tokens / variables and their proximity to the proposed system. I didn't include them originally for a few reasons, but most importantly:

1. Not everything is a component – this can be debated in a future post 😈

2. Tokens / variables have their own complexity when it comes to structure, organisation, syntax, and other developer-y things

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2F46ef2a9e-7d0b-4a9d-b208-220f128cb1b7.jpg?alt=media&token=e649cc51-2d79-44df-8b3a-a3bf3be52ff1","id":"46ef2a9e-7d0b-4a9d-b208-220f128cb1b7","width":6480,"height":4320,"filename":"atomic-design-tokens.jpg","type":"image/jpeg","caption":"The CPS flow alongside the same flow but with tokens at the start. There is an arrow from left to right pointing from tokens into components.","border":false}]}
```

Logically, we would insert tokens at the start of the flow. We have tokens, then components, then patterns, then screens...right? Well, not quite. Tokens flowing from the start would present us with TCPS:

**T:** Tokens\
**C:** Components\
**P:** Patterns\
**S:** Screens

The issue I immediately find is that tokens aren't **just** for components, they permeate entire products and websites, regardless of whether everything is a component or not.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2F5b6a0812-780b-4ce5-b99b-d1685bf1c30b.jpg?alt=media&token=70ba1e9a-7c9c-4dd2-aa6f-65c13a10607b","id":"5b6a0812-780b-4ce5-b99b-d1685bf1c30b","width":6480,"height":4320,"filename":"atomic-design-tcps.jpg","type":"image/jpeg","caption":"The CPS flow alongside the same flow but with tokens at the start. There is an arrow from left to right pointing from tokens into components.","border":false}]}
```

This means that instead of a single TCPS acronym, we are presenting tokens as an **and**, versus alongside.

**T:** Tokens\
**and**\
**C:** Components\
**P:** Patterns\
**S:** Screens

We now have **T+CPS**. It looks like a scientific formula, I kind of like it.

### The split

The arrows imply that tokens always flow into a component, but we might want to consider splitting tokens out and feeding them into components, patterns, and screens independently.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2Ff69481d7-b7f1-4b80-91b7-f96d1cb2367c.jpg?alt=media&token=66bb94ee-3678-4762-8afe-e75f064c7b31","id":"f69481d7-b7f1-4b80-91b7-f96d1cb2367c","width":6480,"height":4320,"filename":"atomic-design-background.jpg","type":"image/jpeg","caption":"An example website screen for an ecommerce store, with an arrow pointing to its background color. Alongside the arrow is a label \"Background/Primary\". Underneath the label reads: (not a component).","border":false}]}
```

An example: your body colour.

This isn't a component, and therefore doesn't fit into the CPS (components, patterns, screens) flow. Therefore, we need the mental model to shift and for tokens to sit outside of those guidelines.

> I will park the argument about surface vs background or default vs primary for the naming conventions here, this is more about what is or isn't a component!

The tokens for our page background, our containers, sections, or pretty much any HTML element that isn't set up as a repeatable component still needs to be stored and (re)used, and forcing ourselves into a "tokens are for components" mindset can trip us up later on.

### Functional and presentational tokens

Perhaps it's time to consider splitting out what we need on component-like elements, and what we need for non-components?

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2F9ed92e3d-5fe3-4280-b2cb-34b015c55062.jpg?alt=media&token=93c0dfb4-9a3b-4367-a3fa-0226194c5395","id":"9ed92e3d-5fe3-4280-b2cb-34b015c55062","width":6480,"height":4320,"filename":"atomic-design-functional.jpg","type":"image/jpeg","caption":"❖ Functional tokens: components, and ☀ Presentational tokens: non-components.","border":false}]}
```

This is why I'm opting to describe tokens as either:

1. ❖ Functional i.e. components

2. ☀ Presentational i.e. not for components

I'm still figuring the definitions out, but I think this makes sense to help aid the example I just shared. With this in mind, perhaps it's also time we interrogated how our aliasing system is structured to aid the two different (semantic) outputs.

As an example, would it be easier to iterate on screens and new components independently if we could use more tightly scoped tokens? The risk we always face with a more generic semantic token – for example, background-default –  is not having a wider view of the impact when you change its value. You might need a background-default that has is slightly darker for a specific use case. The temptation here might be to create a hyper specific component token, but what if it's not a component? I could ask questions all day here, but let's carry on.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2F26664ab1-c74e-483b-8f3c-af9efdde6a9d.jpg?alt=media&token=53a5b971-0887-49bf-a4ff-b12d3dffa083","id":"26664ab1-c74e-483b-8f3c-af9efdde6a9d","width":6480,"height":4320,"filename":"atomic-design-primitives.jpg","type":"image/jpeg","caption":"Mono/100 being split into a functional menu/background and a presentational screen/background.","border":false}]}
```

A functional vs presentational split could look something like:

Primitive: Mono/100\
↪️ Menu/Background\
↪️ Screen/Background

Again, the naming conventions here are examples and are probably not great. However, menus and backgrounds make up a significant part of interfaces. Popover would be another good one, or card!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Frethinking-atomic-design%2F259be22c-f0ff-4b06-8340-9b0c5fc6b2cc.jpg?alt=media&token=435f2936-f921-46f0-a97a-7cd3ce8f5ba8","id":"259be22c-f0ff-4b06-8340-9b0c5fc6b2cc","width":6480,"height":4320,"filename":"atomic-design-presentational.jpg","type":"image/jpeg","caption":"Mono/100 being split into functional and presentational tokens for a menu, action, and screen.","border":false}]}
```

Extending the logic, our primitive may be extended like this:

Primitive: Mono/100\
↪️ Menu/Background\
↪️ Action/Background\
↪️ Screen/Background

A simplification, but hopefully you are following the logic here.

### This sounds like duplication

Hang on, one primitive being split into 3 identical backgrounds, isn't that inefficient? Yes and no.

I'd wager that it's faster and easier to build a muscle memory for searching "*action-background*" than wrestling the cognitive arm of "does *background-default* mean white, or that light grey that we use, or is default something we shouldn't be using a lot?".

A generic, widely applicable token system is the dream-state, but I'm not sure we can get there in organisations that aren't very tightly intertwined. Additionally, for the scenario where you *do* need to use a light grey instead of a white, would you instinctively know that you should be applying (for example) *background-secondary*? Or is it *background-tertiary* because that's how you've split lightness within colour ramps? I don't know, and your design team likely don't either.

It's way easier to search for a **component** *background-action* or a **presentational** *background-page* than to remember that there is one token to rule them all. This supports the ability to iterate and test new concepts faster too.

Let me know what you think!

### Canonical

This was originally posted as two threads:

1. [Atomic design](https://x.com/disco_lu/status/1654479672984457217)

2. [Atomic design and tokens](https://x.com/disco_lu/status/1658475897811517442)

Loose thoughts: Rethinking atomic design

Grab a drink, we have many words to read.

If you're working in a team with either multiple brands, multiple platforms, multiple densities, or perhaps all of the above you may be stuck trying to figure out how to structure your system/s in Figma. Here are some loose thoughts on how I'd go about approaching the problem.

### **Starting with small wins**

Organising and creating tokens in a design system is a 2-month or 2-year project, and you can start anywhere from documentation to auditing to creation. A useful starting point is to try and work from a position of low hanging fruit – are there any quick wins? 

For example, are there any colours in your system that are already close to how you’d expect the end token to look?

I’m talking specifically about the Figma side here, where perhaps you’re looking at a transformation project to convert Styles into Variables. What I’ve seen is that this project seems simple, but opens large cans of worms with regards to naming conventions alone.

Perhaps you already have a `background-page` style, which will auto convert into a variable of the same name? Or you have a very consistent 4px radius on your main components – this is a moment where you could plan, create, add, and publish the radius Variable with little disruption to existing workflows. 

Log these wins and aim to tackle them first.

### **Pipelines**

A key consideration to make throughout your token project is to define what level of automation you need. Honestly, I don’t think most teams need an automated pipeline of in/out changes from the design tool to the code repository. 

Why? I doubt tokens are changing all that often! The energy to create a workflow may be better spent on other parts of your project to begin with, and trying to build better communication channels across your cross-functional partners.

### **Global or local libraries**

I believe that Variables are the “trojan horse” for a flexible system (shout out to [Giuseppe Perri](https://www.linkedin.com/in/giuseppeperri) for using the trojan horse phrase during a recent call), where we can be sure from a brand and systems point of view that the values are fixed, but introduce flexibility in their expression via team-level or local component explorations.

Knowing that all the colors, radius, sizes etc are consistent allows us to move away from the idea that the system is limiting creativity. It flips the idea so that we position components as something designers control, and tokens are something the system controls.

I believe this would promote higher adoption of consistent values and decrease the likelihood of value deviation.

At this point, we have the opportunity to consider what is indeed a global Variable, and what is more locally scoped to a platform, project, or feature. This is a significant ask, and may take time, but effectively the question is: what Variables and components does every platform use out of the box?

On a semantic level, within a multi-platform (mobile, web, car, watch, tv) system, you are likely to find that the values within each semantic Variable need to differ. For example, the screen quality of your car dashboard and mobile phone screen are likely to differ widely, so your `bg-danger` on mobile may alias `red-600`, but in the car you may need a higher contrast `red-700`. This technically can be handled by modes, but I’d like to question whether they should even be using the same primitive foundation at all?

For situations where your different brands or platforms do indeed need to use different primitive values, it might be worth considering using groups as a way to prefix Variables within Figma collections. For example, a group for Car, a group for Web, and a group for iOS. When aliasing these later on, you will be able to filter down to `Car/red-500`, which has a different contrast to `iOS/red-500`. 

> For those interested, Figma has a different light and dark primitive ramp! You can see this in the published [UI2 community file](https://www.figma.com/community/file/1271813911103366792), on the page titled Color.

The challenge central to a goal of “one semantic for all” I think lies in sizing, specifically font sizes, density, and target sizes. Comparing a watch interface with a tv one will immediately make life challenging. A `heading-hero` font size will vary massively across platforms, so we need to decide if we want to maintain separate style libraries for these different platforms, or rely on a mode-based approach to handle all of the individual values. 

A curve ball option on this too is to use components for your text styles, which might actually align tighter with your code implementation anyway!

The pro of centralising all of your values (using modes for platform switching) is that you are tightening the screws of control within the system. This is great! For you, the system maintainer 😉. You minimise risk of duplication, and align closer to code implementation.

On the con side of the equation, you expose all designers to all modes. A designer working on mobile still has access to the car, tv, and watch Variable modes. To me, that’s quite a high risk of walking into a mixed mode world, where we push a piece of work to production using the wrong colour values. 

Perhaps I’m being dramatic, but it’s potentially expensive. Additionally, depending on how clear you are with your mode names, a darker shade of red might “just look better in a different mode” for a designer, again risking mixed modes.

In a highly functioning or tightly knit team, this risk is small because communication and documentation can discourage the mixed mode approach, but it’s still a risk.

**Splitting libraries**

With these considerations, we might then want to explore splitting our platforms into separate Variable libraries. One central library is great in theory, but the volume of Variables you’d have to maintain in a single collection across many themes, brands, and platforms could soon explode.

Inefficiency is the canary in the coal mine of an ambitious systems team, but I believe that sometime debt or less efficient approaches to management can help unlock way larger efficiency in our dependent design teams.

Similar to the concept of snowflake components, we may be enabled to manage platform-specific Variables if we opt for a split library approach. Say our watch interface has a specific `pill` component for `alerts`, this doesn’t need to be global and in fact may cause disruption if it is. 

Additionally, because it’s a platform-specific component with its own behaviour, we have the opportunity to debate whether component-specific Variables would help us release and manage this too. Component Variables are given a bad rap, a lot [by me](https://youtu.be/M0NU5QFLCl4?si=ip-ijUmNuZWGXADL&t=607), but they have their place. Perhaps more on this in another article.

### **Design and code deviations** 

Within Figma right now, there’s no ability to:

1. Add percentage Variables (for things like line height)

2. Add opacity as an override to a Variable

Because of this, we have to accept that Variables in design, and tokens in code, will differ. We have a few workarounds, but fundamentally we have a deviation.

On the line height side, I currently do not use Variables for line height in my text styles. I add a % value manually, unless working with a strict pixel based system of course!

For opacity, I do one of two things:

1. Create an additional primitive. For example, our `red-500` example may need a version that’s 70% opacity. For this, I would create a new Variable called `red-500-70` and then alias this into my semantic Variable. The benefit of this is that we can remap or reconfigure the semantic Variable later, because we know where the primitive is applied

2. Alias in my `red-500` Variable to the semantic one, and then detach the Variable. I then set the 70% opacity on the raw hex value. This idea may raise your eyebrows, but it’s a quick and dirty way to prevent the need for additional primitives. This is the approach I have taken in the [shadcn UI kit](https://www.figma.com/community/file/1414738876845632189) I've been working on

Both of these options are likely not how we would be managing things in code, so do bear that in mind at the point of build. Communication between teams may be a quick way to resolve this.

### **A quick moment of existential thought**

It is an existential question, but at these points of deviation it does beg the question – do design and code *need* to be 1:1 aligned? Is Figma the exact replication of what you have in code, or is Figma the playground for ideas, perhaps in a different way? 

Parity here means we might need to bend over backwards to ensure naming conventions and values are very tightly matched, whereas answering no might mean "hey we don’t even have half of the Variables in Figma", and they have different names altogether because designers think in a different way.

All of this will also be defined by who we decide is responsible for maintaining and updating Variables and / or tokens. If it’s all the design side, you may have flexibility. If all on the developer side, you may need to align a lot closer. Or not! 

Again, a conversation may help resolve a lot of these potential concerns.

### **A Mille-Feuille of Variables**

Classically, we look at the 3 layers of Variables being primitive, semantic, and component, but in order to build truly multi-dimensional setups within Figma we might have to introduce many more. 

With Figma’s Extended Collections feature being delayed, we have to explore different ways of managing multiple dimensions within our Variable setups. 

> [Kish](https://x.com/IAmByDesign1) explores an option over on [YouTube](https://www.youtube.com/watch?v=zCCEn6zFlDY) if you want to see how he is thinking about things.

To me the simplest way to introduce complexity to enable complexity is to consider a middle layer of “brand” within our setup. Perhaps we go from primitive into brand, where we introduce light / dark, and *then* into semantic. That middle layer is where we can use modes for different brand (or perhaps platform!) specific definitions of our Variables. 

This is definitely tricky, as we could end up maintaining duplications of the same Variables across different collections, but enables us to manage primitives, colour modes, and semantic naming conventions within a single system without exhausting the modes available to us.

```
I'm fully aware that this is probably best served with a demo, so I might add one in later.
```

Once again, this is not how we would handle things in code, so bear that in mind! It is worth considering if this is actually a problem if at the point of inspection your values present on components are correct and your developers can see them.

### **Mega components?**

A central system dream state will be where you pull in a component from the library, and you’re able to switch it to a different platform, mode, or density quickly and with great performance. 

Whilst this is technically possible, there are a few ways to get there:

1. A variant component containing all brand, platform, and density expressions. AKA the *mega component*

2. Using Variables and modes build multi-dimensional setups like we mentioned before

Option 1 is definitely the pre-2023 logical approach, but do bear in mind that in Figma, every single component variant is loaded onto the canvas when you insert them. This means that a large variant set potentially has the ability to slow your file down with a large amount of inserts.

Option 2, whilst desirable, lands us in the situation mentioned before with the need to create multiple levels of aliasing to achieve the desired approach.

A third option is to maintain many, seemingly identical component libraries. This impacts every decision from text styles to component composition to library permissions to naming conventions to code parity. 

That’s a lot to consider! But, I would like to propose it at least as something to think about. Why? Versioning! 

When working on multiple different codebases and platforms, with different release cycles, you may end up in a sticky situation where a single component for everyone doesn’t allow you to release the next version for a specific platform. 

Does your card on v4 of the web app need a button at the bottom, but you don’t need it on iOS? Sure, you could introduce a boolean toggle in the main component, but nothing will prevent a designer toggling it on accidentally for the web. To me, this suggests an iOS-specific card component, even though the radius, colours, spacing, and states may be identical.

Mmm, but what about discoverability? Two seemingly identical component libraries might cause a headache when trying to find the right component. Technically yes, this is true. We can move around it with library permissions (switching on the iOS library for iOS designs), but for those that work across multiple platforms within the same file, we will still have the issue.

This is perhaps where name spacing can help. Does `card – web`, `card – iOS` allow you to manage these independently, whilst aiding discovery? It does vary on how your designers find components as well – do they use sticker sheets, copying and pasting between files? Or do they search in the assets panel for specific components? Either option may help or hinder this idea.

It’s worth mentioning – and I promise I’m not trying to sell here – that [Code Connect](https://www.figma.com/blog/introducing-code-connect/) within Dev Mode may make this redundant too. If you are connecting the correct coded component to a Figma one, naming conventions may not need to be aligned at all. `Card` may be called `Tile` in code, and that might be an issue if, when inspecting, your developers can see the correct code regardless of name.

### **Naming convention comprehension**

Something to bear in mind from a systems perspective is whether people even understand what your agreed names even mean. Of course, “naming is hard” etc, but understanding differs within seniority and interest levels. 

1. Does a junior designer understand what `bg-default` means? 

2. Does a senior designer know that `bg-danger-tertiary` should only be used in combination with `fg-danger-tertiarty`? 

We must anticipate these differing levels of knowledge when it comes to naming conventions, and try to build systems to support. Sure, the easy out here is to write documentation on how and when to use specific Variables, but I’d challenge it. 

Do we then need to be in a position where we’re managing multiple levels of naming, to aid the rapid iteration of design ideas? Is it actually *that bad* if someone prefers searching for `orange` instead of `bg-notice`?

### **Surprise! We have a design system**

Lastly, I think, is that as with any significant project rollout, we must be mindful of anticipated reception. 

Does your design team know you are working on a large Variables project, and that what they are currently doing is due to change? If they do not know, then tell them immediately! And do it so often they get bored. 

The worst thing for a project is to have the recipients feel like the rug has been pulled from underneath their feet, and especially when an organisation is moving at pace.

\--

Questions? You know where to find me 👋

Loose thoughts: Variables considerations for multi-faceted systems

The more I talk to hiring managers and senior designers about what they are looking for in designers, the more I back up the theory that portfolios shouldn't be X, Y, Z case studies, but explorations of your obsession with details.

Showing deep, deep examinations of your solutions AND what you didn't deliver is a really great way to show how you approach solving a problem. A slideshow of solutions doesn't show anything below the surface, just a public-facing polished mockup.

But! Jumping incredibly deep into your rough work can show that you really do take the end to end product process into consideration when solving a problem.

"This didn't work, because..." is a fascinating discussion that I know would be way more interesting than "here's a flow" during a conversation with a hiring manager.

The question is therefore: How can you prove that you are "obsessed" with the details? Craft is becoming a key differentiator in software products, and design (AKA you) has the power to drive this forward, how will you enable this company to push the boundaries of quality?

The good news is that I'm confident this works in designer's favour! So many designers explain that they can't build a portfolio because "they don't have much to show", but what if you flipped it?

Take a single element on a single screen from a single feature. How much detail went into this? How granular can you get with the pixel-level detail of your every move?

\-

A few examples of deep dives:

1. Building auto suggest https://www.mrbrianmorris.com/work/query-formulation

2. Spotify changing their color: https://spotify.design/article/better-in-black-rethinking-our-most-important-buttons

Portfolios: Prioritise pixels over presentations

A living, breathable list of what I believe makes great products.

 1. Trust your gut

 2. Test with the real product

 3. Craft over consistency

 4. Experience matters

 5. Focus on problems that matter

 6. No one owns ideas

 7. Technical debt is a good thing

 8. Don’t reinvent the wheel

 9. Be in the right place at the right time

10. Keep the team as lean as possible

11. Avoid over-optimisations, focus on business value

12. MVPs should not be abandoned

13. Would we be satisfied if we could never update this again?

My work in progress approach to product

Versioning components is a tricky one. Versioning files (or designs) arguably even harder, especially with design artifacts increasing on a daily basis.

Figma is "always on", so does this mean that we shouldn't even try to version? Always live, all the time sounds fantastic and gone are the days of exports and imports and PNGs and PDFs and server storage, but we still have a big problem – maybe we *want* or *need* to freeze work.

When approaching versioning, it's useful to consider both sides of the collaborative equation – designers and developers.

Here are some useful questions to ask to establish some foundations before considering what level of versioning we might need:

**Design**

*Components*

1. Do you need to manage multiple component versions at the same time?

2. Do designers need to create work using multiple component versions?

3. Do designers need future versions of components before they are committed to handoff?

4. Do we want to version by component, by pattern, or by library?

*Screens*

1. Do we need a "source of truth" of our entire product / app / website? Be careful with an immediate "yes" here; some of the largest and most respected companies do *not* maintain large truth files

2. How long should a file last? Yes, this may be an impossible question to answer

3. Do we need to reference flows within flows? For example, a log in flow that's consistently referred to from within other larger flows. Again, likely yes

For screens organisation, it's worth checking out my file structure community file: [figma.com/community/file/1004041613962064465/file-structure-best-practice-guide](https://www.figma.com/community/file/1004041613962064465/file-structure-best-practice-guide).

For the "repeat flow" problem check this one out: [figma.com/community/file/1179022882729015433/repeat-flow-components](https://www.figma.com/community/file/1179022882729015433/repeat-flow-components)

I'll likely write another post about this, as it's a lengthy topic in itself.

**Development**

1. How do your developers version components?

2. How often do you release major/minor versions?

3. Do your Figma and code libraries differ in what components are available

4. Do you create components in Figma that you don’t need in code?

5. Do you create components in code that you don't need in Figma?

This is a lot of questions, but clarifying the answers should hopefully help provide some grounding for you to approach a solid versioning system.

### The contribution process

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FIcru9vdcRCHNw8iMLSfl%2F60b19f7e-ced2-42a5-b7a1-7162ff5c2d00.jpg?alt=media&token=08a54932-d090-4f54-89e8-6365c43bfd52","id":"60b19f7e-ced2-42a5-b7a1-7162ff5c2d00","width":1080,"height":1080,"filename":"Design component process.jpg","type":"image/jpeg","caption":"Diagram showing a flow from design file to new feature to component library","border":false}]}
```

Typically, we have our central design file which we then update with new features as they are prioritised. From here, we create new components for either efficiency gains or to live within the design system eventually. Then we move these components to the design system, and publish those out to the wider team.

This in theory works great! But in practice, we enter a world where we chase our tails trying to stay on top of component creation and contribution back to the system.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FIcru9vdcRCHNw8iMLSfl%2F907589dc-3484-4f67-bf2d-0bdca58ddc0b.jpg?alt=media&token=84baa715-40cf-447f-8275-f2030bb086ed","id":"907589dc-3484-4f67-bf2d-0bdca58ddc0b","width":1080,"height":1080,"filename":"Design component process overload.jpg","type":"image/jpeg","caption":"A flowchart of the complicated process of multiple design files trying to contribute back to the design system all at the same time.","border":false}]}
```

We therefore end up in a situation of constant creation, moving, publishing. In a small team, this is manageable, but as soon as we introduce different releases per team or timezone we end up in a world of pain.

Back to the topic, it makes versioning harder too. If my team needs to ship a feature that uses version 1, and your team needs to support version 2 because you're releasing much further in the future, how do we manage that with a single component in a single library?

As soon as we update the component to version 2 in our library and hit the publish button, every single designer is grandfathered into the newest version. This should be sending alarm bells to us all!

We need the ability to maintain two separate versions of the same component, but unfortunately this isn't possible within Figma **yet**.

As a result, we need to think laterally to figure out a solution for all.

### What options do we have?

**Option #1 – More components**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FIcru9vdcRCHNw8iMLSfl%2F3adc606e-bf1d-47af-883e-4b3c49473020.jpg?alt=media&token=86c11a58-da9b-47f5-9663-87db616d0e95","id":"3adc606e-bf1d-47af-883e-4b3c49473020","width":1080,"height":1080,"filename":"Design component process more components.jpg","type":"image/jpeg","caption":"Visual showing two components being published into a single design file. The first component has a label \"version 1\" and the second \"version 2\". There is an arrow pointing towards the \"version 1\" shape with a label reading \"6 month deprecation plan\".","border":false}]}
```

It might sound counterintuitive, because of the live nature of Figma, but perhaps the easiest way to manage (major) component changes it to...make more components.

For minor updates to components, editing the same component may be just fine, but for larger structural or theming changes, it's probably best to isolate this change in a controlled way.

That might mean adding another variant to your component set, or a new component set entirely if the changes are significant.

*Pros*

1. You can independently manage versions of components, providing teams with the ability to switch to the newest version when they need to

2. Existing in progress work will not be disrupted with the newer version

*Cons*

1. It's perhaps inefficient to maintain components with the same in the same library. It could cause confusion for finding the correct version. To get around this, you could add the a label or word modifier to the new component, perhaps "future", adding an emoji to the end of the component name, or using the actual version number e.g. "Card v4"

**Option #2 – More design files**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FIcru9vdcRCHNw8iMLSfl%2F2315934b-5a76-4ad7-bc9e-3de30e359bf7.jpg?alt=media&token=4076e317-2a3a-4df5-8d97-e4b254bcf521","id":"2315934b-5a76-4ad7-bc9e-3de30e359bf7","width":1080,"height":1080,"filename":"Design component process more files.jpg","type":"image/jpeg","caption":"A flowchart showing a single component being updated twice. For each update, it is consumed within a different design file. There are design files named by quarter – Q1 2024, Q2 2024, Q3 2024. As each update of the component happens, it is pushed into a newer design file.","border":false}]}
```

I raised the question earlier about how long design files should last for. This is, most of the time, an impossible question to answer because of course project lengths differ.

Centrally though, I believe we should strive for a world where design files are throwaway deliverables, versus an ongoing "forever file" that's constantly updated. I appreciate that in larger, more traditional industries, this is more like blue sky thinking than a worthy reality, but it's definitely worth striving for.

Once the work has been done, do we really need to refer back to that piece of work again if the production product is our source of truth? How often, realistically, are we going to be updating the entirety of that user flow? As the answer gets closer to "not that often", the higher the chance we can create new files for newer features.

With this method, there might be a scenario where you can create a new design (feature) file for each major piece of work you're creating. This could align with dates, for example Q1, Q2, Q3 etc. Or it could align with flows, for example "onboarding" or "settings". As we create more files, we can more easily inherit updated component versions too.

As our table component updates to version 4, our new(er) design file can inherit it without the concern that we're conflicting versions within a legacy design file that was created 2 years ago.

Smaller and more frequent files, less headaches.

```
A word of warning: if you use pages for versions, be mindful that as soon as you update the file with changes from your component library, every single component will be updated to the latest version. This will mean your versioned pages are all in fact now the latest version.
```

### **Option #3 – Staging libraries**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FIcru9vdcRCHNw8iMLSfl%2F538fbbce-3f9c-447c-91c6-84e36d6ce649.jpg?alt=media&token=b18353cf-dd4f-4df5-9ac6-3d746832c58d","id":"538fbbce-3f9c-447c-91c6-84e36d6ce649","width":1080,"height":1080,"filename":"Design component process staging libraries.jpg","type":"image/jpeg","caption":"A visual representation of the \"production\" and \"staging\" Figma library concept, showing a publishing flow from the two separate libraries into a single Figma file. The Figma file also contains a label for \"local components\".","border":false}]}
```

This one is more likely to be possible with a larger product organisation that can't bet on small files being created for every piece of work.

There's a scenario where we want to contribute frequently to our system, but at the same time not move too far ahead what versions our developers are expecting. Designers typically work way ahead of time with new feature work compared to the designs the development team are implementing. Conflating these versions could be an expensive mistake!

With this in mind, we could introduce staging component libraries to help us stay ahead with future work, but without compromising the current state within our system.

A staging library is any components which aren't quite ready for production, but are ready to be used.

1. Future components, not ready for implementation

2. Newer major versions that you need to test in design files

3. Component tests that need to be isolated

4. A/B test components

Pulling these components into their own staging, or "sandbox" library will provide you with the flexibility or a system-wide publishing cycle, but protect your existing design flows and current component versions.

### <end>

That's all! Let me know what you think. This is possibly a work in progress article, as I formulate more thoughts on the topic.

\--

**Update 25 September 2024**

Ben Armstrong over on [LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7242198881919283202?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7242198881919283202%2C7242505040538603520%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287242505040538603520%2Curn%3Ali%3Aactivity%3A7242198881919283202%29) shared how they set up their future components with a label of "experimental". I like it!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Ffigma-versioning%2F072dd3e7-719f-45b2-bcc2-67878f86e6b5.png?alt=media&token=7ce2700c-8e05-4bb4-a080-e527161c3a13","id":"072dd3e7-719f-45b2-bcc2-67878f86e6b5","width":614,"height":664,"filename":"1726747760199.png","type":"image/png","caption":"Screenshot of the Figma component description field a description of a component that's currently experimental.","border":false}]}
```

Loose thoughts on versioning in Figma

Before June 2023, it's safe to assume that most designers hadn't even considered the word "semantic" within their work.

It has arrived as part of the design tokens / Figma variables wave, and whooshed us all into a linguistic frenzy. What even is semantic, and why does it matter to **me**?

Well, it probably doesn't matter that much to all of us, because it is a design systems topic, and we're not all working on them! We can add *primitive* and *alias* into this bucket as well; terms on terms on terms.

**The terms**

I suppose we should probably define these terms before contesting them:

*Primitive*

When talking about a design token, it essentially means the raw value. The one for the value itself. For example, if you're familiar with Google's Material design principles, they have a large set of primitive values for colour:

* Purple 50 (#F3E5F5)

* Purple 100 (#E1BEE7)

* Purple 200 (#CE93D8)

* ...more colours...

* Purple 900 (#4A148C)

These numbers represent the darkness of a colour, 50 being the lightest and 900 being the darkest.

*Semantic*

This is where we introduce intention into our colour names. This means that:

* Instead of *Purple – 50*, they use "Surface Dim"

* Instead of *Purple – 500*, they use "Primary"

* Instead of *Purple – 700*, they use "On Primary Container"

As a designer using the colour, you don't need to know or care what primary actually looks like, it's just the primary colour you will use.

Hence, semantic because it's logical and has intention.

*Alias*

This is the process of referencing one value into another. Taking our purple / primary combination we would look at it like this:

*Purple 500 -> Primary*

The value of primary is purple 500, and it has been *aliased*.

**Alright Luis, what's the point of this article**

Over the past 9 or so months, I've become obsessed with semantics. Lots of people have.

"That's not semantic, try refactoring the name"\
"Primitives shouldn't be exposed to your design team, only the semantic values"\
"Primary means nothing, don't use that"

These are probably quotes I've said at some point.

I'm starting to reconsider whether we even need this semantic layer within token/variable architecture.

**-- From this point forward, I will be specifically talking about variables within Figma --**

It's a pretty bold turnaround, but hear me out for a second.

Variables within Figma have a feature called scoping. This allows you to say, for example, "this colour should only be used within a fill".

Whilst talking to a few friends on WhatsApp (hello [Luke](https://read.cv/finch), [Henry](https://read.cv/henrydaggett), [Hugo](https://read.cv/_hraymond), [Ollie](https://read.cv/strangutan), Scott, [Karl](https://read.cv/kejk), and [Gavin](https://read.cv/gavinmcfarland)) This sparked something for me recently, where I wondered whether scoping alone was the semantic modification we've wanted all along.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FK1SH3oBardJqKvpD8sAM%2F13361cbb-e754-46d9-8e0f-f069272df843.jpg?alt=media&token=e6a8e295-a294-401e-9294-891d055543f2","id":"13361cbb-e754-46d9-8e0f-f069272df843","width":800,"height":400,"filename":"scoping-whatsapp.jpg","type":"image/jpeg","caption":"Screenshot of the original WhatsApp message from Luis","border":true}]}
```

Ultimately, semantic variables are a level of scoping, allowing us to define specific implementation of the values we want to control within a system. And if there's one thing I know, it's that agreeing on naming conventions within a design team alone is a near impossible task, and then tossing it over the fence to your engineers is another battle that may be lost as soon as you pass over the figma.com link.

Why? Developers love frameworks. I was ~~un~~fortunate enough to have been raised in the world of web development back when Bootstrap was the de facto standard. It didn't last forever, but we have other frameworks now plugging that gap, for example Tailwind CSS or Radix.

Tailwind CSS is fantastic for rapid development, because a lot of the design decisions have already been made. This is most certainly the moment where you start sweating, because I said design...decisions. For example, Tailwind CSS has a robust and well constructed set of colours, ready and warm from the oven.

These colours are primitive in nature, not semantic. In fact, here's a line from their documentation:

`Tailwind uses literal color names `*`(like red, green, etc.)`*`and a numeric scale`*`(where 50 is light and 900 is dark)`*`by default. We think this is the best choice for most projects, and have found it easier to maintain than using abstract names like`**`primary`**`or`**`danger`**`.`

Notice the callout to not use semantic naming here. Hey, this might not be that big a deal, but is almost certainly rage inducing for those that swear by the good book of semantic naming conventions. You *can* alias within something like Tailwind CSS into a more intentional semantic naming conventions, but good luck explaining why those hours of development time need to happen.

For Radix, I'd recommend reading their entire documentation [page](https://www.radix-ui.com/colors/docs/overview/aliasing) on aliasing, as they run into similar issues with naming.

What I think may be worth us thinking about is how we can become better friends with our developers, and work on their turf, rather than trying to crowbar in something that may not benefit the relationship.

**Back to Figma variables**

What's stopping us from maintaining a single, primitive set of variables, named as such (e.g. red-300) to match your developer's framework, relying on scoping alone to bridge this gap?

This also maps back to our Material design example too. Best served with a visual.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FK1SH3oBardJqKvpD8sAM%2F90daf353-8ed7-4c1e-aa6d-0c63eeadda69.jpg?alt=media&token=7adc7b9a-a39b-45f5-85bd-4b00309150e7","id":"90daf353-8ed7-4c1e-aa6d-0c63eeadda69","width":1080,"height":768,"filename":"pedantic-semantic-scope.jpg","type":"image/jpeg","caption":"Screenshot of the Figma variables window for the Google Material colours","border":false}]}
```

The visual above shows our Material design colours for purple and teal, from 50 up to their darkest 900. 500 is highlighted, and has been scoped to just be available within frames and shapes.

This is exactly the same process we would go through for **semantic** variables, but we are only maintaining one collection here. This seems...logical? And perhaps less of a headache.

What would it look like with a real component example. Enter my favourite one, the toast.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fpedantic-semantic%2Ffd9eac52-a389-4333-8cbf-6a6a733c0c8d.png?alt=media&token=45870d1d-bcb4-4f63-9e67-a3bfffc39195","id":"fd9eac52-a389-4333-8cbf-6a6a733c0c8d","width":1920,"height":960,"filename":"pedantic-tokens.png","type":"image/png","caption":"Toast component showing a comparison between the variables used. Left side is semantic, right side is scoped primitives.","border":false}]}
```

There is a drawback here that you can't scope deeper. For example, "this colour should only be available in these specific components". But what's stopping that from becoming an eventuality if it saves us time?

Another potential issue is "what about dark mode?" This for me isn't necessarily a null point, but something definitely worth contesting. If modes should eventually "come for free" within our designs, does it matter if purple-50 is very light in light mode, and dark in dark mode? I'm not sure if it does. Within Figma, this would mean creating two modes at this primitive level instead. Visual below.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FK1SH3oBardJqKvpD8sAM%2Ff0e63527-949d-4da3-af42-71b79b5fb2cf.jpg?alt=media&token=b4796a5b-2f90-4a5f-a2c0-a3f11329d8fd","id":"f0e63527-949d-4da3-af42-71b79b5fb2cf","width":1080,"height":768,"filename":"pedantic-semantic-scope-2.jpg","type":"image/jpeg","caption":"Screenshot of the Figma variables window for the light / dark mode example.","border":false}]}
```

Let me know what you think,\
Luis.

Are we too pedantic with semantic

With every change to a variable, style, or component, we must anticipate the downstream impact to a design file that is already consuming it.

If we reorder the elements within a component or change its visual appearance during the time at which a feature is being developed, we may disrupt the "handoff" process significantly, impacting the development costs and planned estimation time for build.

\-

A major version changes (in Figma) can happen in a bunch of different situations, here are a few:

1. A rebranding

2. A significant restructuring, with either styles or components

3. Naming convention changes

4. Keeping up with feature releases, for example changing from styles to variables for color

5. Asset locations are changing e.g. one component moves to a new library with different permissions / access levels

And a quick summary of each:

1. **Rebranding**

Significant visual identity change will impact color contrast, spacing, typography, and often impacts component structure too.

2. **Significant restructuring**

This is related to, but also separate from rebranding.

A visual refresh of a page within the same brand guidelines will often change how a component is architected, and therefore downstream changes in any instance of the previous component will break or change the layout considerably.

3. **Naming convention changes**

A pretty straightforward one! *Card* may become *Tile*, *Card* may become *Card – Product* etc.

4. **Updating for feature releases**

Variables are the most recent significant update here, but previous releases included component properties, or variants.

5. **Asset location change**

This one comes with an asterisk, because it's unlikely to happen but is worth bearing in mind. If you move a component to a library with different user permissions, consumers may lose *or* gain access. 

\--

### **Friction**

There will need to be friction introduced with a change like this. I repeat, **need**. 

A question we must ask ourselves is *where* we want this friction to occur.

**Another important thing to think about**

We need to know whether the business has a requirement to support concurrent versions. 

* Does one team work on version 1 and another version 2? 

* How do we plan to manage this?

Here are a few options to think through for mitigating this friction:

**Option 1: Friction for the library**

When playing out the idea of a major version introduction, there are a few options for components:

1. A new variant within the same component

2. A new component

3. An entirely new library

The severity of change here increases as we go from 1 to 3, but the control increases too. In order to make a decision about which option we might want to investigate, we need to know if this major change is affecting just a single component, or the entire library. AKA, do we version individually, or as a whole?

1. A new variant

A new variant within the same component is pretty simple to manage at an atomic level, but as soon as we introduce that new version into a larger pattern which *aligns to a previous version*, we are packing our bags and moving to Trouble Town, Ohio.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FQrtQdzEv0F1bcf6DWBMj%2F2a52b18f-3d24-4403-a9a3-308c8a3914de.jpg?alt=media&token=cb2a1387-1fad-4c46-81fb-05e288dd4b3c","id":"2a52b18f-3d24-4403-a9a3-308c8a3914de","width":1920,"height":1080,"filename":"mixed-versions-variant.jpg","type":"image/jpeg","caption":"An accordion item variant component which has had a new variant added, styled differently. Underneath the accordion item is an accordion, which has the item nested inside.","border":false}]}
```

It's this fragility which could make or break a rollout.

2. A new component

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FQrtQdzEv0F1bcf6DWBMj%2F75304d54-1650-4347-b864-50c583245fb4.jpg?alt=media&token=87026544-2874-4f5a-ba92-6150b165b150","id":"75304d54-1650-4347-b864-50c583245fb4","width":1920,"height":1080,"filename":"mixed-versions-instance.jpg","type":"image/jpeg","caption":"A \"current\" accordion item component alongside a \"future\" version, which has a different visual treatment. Below is a full accordion component, with the open accordion item selected, alongside a screenshot of the Figma properties panel instance swapper. In here, you can see there are two accordion items listed: the current and future versions.","border":false}]}
```

A new, replacement component provides you with the ability to split versions and provide a longer term deprecation / rollout. I might write about this in a different article.

Perhaps we create a new component, and add a suffix of "– Future", to indicate to consumers that it's coming soon.

The word "future" is TBC but right now it makes sense to me as a way to detach from a fixed version number, but to indicate it is *new*.

3. A new library

An entirely new library is a drastic change, and probably best served as part of a brand refresh where the entire visual direction is changing for every consuming design file too. I like this option though!

**Option 2: Friction for the design files**

Some design teams use files as throwaway artifacts – once a piece of work is finished, the file is retired.

Some design teams maintain single files forever, with ongoing overrides to existing assets, a branching workflow for managing changes, or a new page for each version. 

`🚨 If you use pages for versions, bear in mind that each time you inherit a library update, your file will be automatically updated to the latest. This will overwrite your pseudo versions and will give you a headache.`

Try to be the former! Files could, and possibly should, be snapshots in time, with our production product acting as the truth and not a file with 10,000 frames. 

(I was speaking to a designer at a very popular code repository management tool recently who told me that their files are often literal screenshots of the production app and designers draw over the top to create new features. I didn't tell you that 🤫)

**Inherited versions**

If we overwrite our components to upgrade their versions, and then embed these as instances in a larger pattern, we run the risk of inheriting a version before we're ready.

Take the image below showing an *accordion* item's visual appearance changing, and then being nested into an *accordion* component. Does *accordion* automatically become version 2 as well?  Or are we working with mixed versions? A question to discuss.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FQrtQdzEv0F1bcf6DWBMj%2F0969be0a-410a-4a95-b648-391a37fdf923.jpg?alt=media&token=e05b0577-3ff1-409a-9234-4980abb96ec3","id":"0969be0a-410a-4a95-b648-391a37fdf923","width":1920,"height":1080,"filename":"mixed-versions.jpg","type":"image/jpeg","caption":"An accordion item and an arrow showing it embedded in an accordion, presented vertically. Both of these have a label above them reading \"version 1\". This is repeated on the right side of the image, but the accordion item has been changed visually, and the label reads \"version 2\". The accordion underneath this one still reads \"version 1\", with a red circle around that label.","border":false}]}
```

**The choice**

The preferred route here is option 1 (friction in the system), even though it's your systems life which will incur said pain. Why? Because there are less people affected by the changes within the systems team compared to the amount of consumers of it.

Loose thoughts: Managing major versions in Figma design systems

There's something bugging me about icons.

Take a look at these two components, what's wrong? 10 points are on offer.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F0a3d9bbb-3e66-4ef9-ab3e-73142ae7ff98.jpg?alt=media&token=d1b82ee6-79a1-4557-b349-37867217c6d2","id":"0a3d9bbb-3e66-4ef9-ab3e-73142ae7ff98","width":1080,"height":640,"filename":"icon-bounding-boxes-comparison.jpg","type":"image/jpeg","caption":"Two light blue components with icons inside and a text string reading \"label\". The left component has a horizontal 3 dot icon, the right component has a vertical 3 dot icon.","border":false}]}
```

That's right! There are two problems:

1. The left padding is optically too large

2. The gap is too loose

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F12242bd4-668f-42ec-98f1-bd214db891e1.jpg?alt=media&token=e198f55f-f1d7-4bb4-b230-c6fe1c8afe82","id":"12242bd4-668f-42ec-98f1-bd214db891e1","width":1080,"height":640,"filename":"icon-bounding-boxes-annotation.jpg","type":"image/jpeg","caption":"Visual of the same two previous components, with a yellow annotation pointing to the issues described in the tweet","border":false}]}
```

When composing components like this (with an icon), the process is:

1. Nest an icon

2. Set preferred instances

3. Bubble up the icon to the top level for instance swapping

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F2fda08b1-d17a-4df6-ae88-d04f5309e8dc.jpg?alt=media&token=7c9cf157-9685-425f-9dc0-d44027798f4c","id":"2fda08b1-d17a-4df6-ae88-d04f5309e8dc","width":1080,"height":640,"filename":"icon-bounding-boxes-component-composition.jpg","type":"image/jpeg","caption":"A visual showing the process of nesting an icon inside another component. It also shows two overrides to the icon, one showing the original horizontal three dot icon and the second showing the vertical 3 dots.","border":false}]}
```

This is because of...bounding boxes.

They make sense because "consistency", but in practice introduce complications to consistent systems-oriented design.

What can be a perfectly set up grid of 24x24 icons in your system can create problems for pixel perfection in designs.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F3da86ce8-ea4a-482a-8e1f-4bf485bc5836.jpg?alt=media&token=14de24a0-db85-49fd-9518-e0696eb43dbf","id":"3da86ce8-ea4a-482a-8e1f-4bf485bc5836","width":1080,"height":640,"filename":"icon-bounding-boxes-outlines.jpg","type":"image/jpeg","caption":"A set of icons laid out on a black background. The icons are presented twice, once plainly and secondly with a red background and border. The previously used \"more vertical\" icons has a yellow arrow pointing towards the bounding box space with a label \"gross\".","border":false}]}
```

We're then forced to create specific space overrides for when bounding boxes are too large. This is optical design running its course, but as a systems person you scratch your head because of the magic numbers requirement for "Left padding 8, right 16", as an example.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2Fe85dfd4f-ac30-471d-afff-a0d552c70740.jpg?alt=media&token=19fd7dc6-f38f-446a-93d5-38be08069b25","id":"e85dfd4f-ac30-471d-afff-a0d552c70740","width":1080,"height":640,"filename":"icon-bounding-boxes-custom-padding.jpg","type":"image/jpeg","caption":"A comparison of the problem icon within a bounding box and the solution – creating custom padding around the icon within the component..","border":false}]}
```

What **is** useful is height. There's an argument to suggest a height-based bounding box could create consistent touch point size (for accessibility).

The likelihood for horizontal sizing is that your icon will always be nested, for example in an icon button with a width anyway.

This could mean that icons are sized with their inherent width in the system, versus a consistent X rule It would remove the need for pixel overrides, and mean that icons should "just work" when placed as instances It feels like scalability.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F9e880e52-10c0-4d17-adf3-ff0d9ed4f462.jpg?alt=media&token=f7a77da4-de59-463b-8054-b1150f33300e","id":"9e880e52-10c0-4d17-adf3-ff0d9ed4f462","width":1080,"height":640,"filename":"icon-bounding-boxes-removing-space.jpg","type":"image/jpeg","caption":"Layout showing the proposal – horizontal bounding boxes are set to the width of the icon, not a consistent one. This means instances of both the horizontal and vertical three dot icons fit within the original component without manual spacing tweaks.","border":false}]}
```

### **Other things to think about**

**Inheritance tax**

When setting fixed sizes at the icon level (within the system) we're kind of making future decisions without the context.

Should the icon button be the place we decide on the icon's size, versus inheriting a choice?

**What if we need a fixed size?**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FTADes7puH6QzEQGQ8r83%2F4f82f6a9-1d6e-4265-9400-2d59efdf4aa9.jpg?alt=media&token=068257fd-d428-4bff-8dc4-4734f1357ad3","id":"4f82f6a9-1d6e-4265-9400-2d59efdf4aa9","width":1080,"height":640,"filename":"icon-bounding-boxes-icon-wrapper.jpg","type":"image/jpeg","caption":"An annotation showing two illustrations horizontally. The left one has an icon button component selected in Figma, with a red arrow highlighting the width and height settings in auto layout, showing they are set to \"hug contents\". The right illustration shows outline mode within Figma, with the icon itself selected inside of the icon button. There's a red circle over the height and width settings, showing they are set to a fixed size.","border":false}]}
```

Taking a common example, an icon button. The likelihood is that your component is set to a fixed (or minimum) size in order to meet tap target sizes for accessibility.

This is a specific instance where we need the icon at a perceived fixed size too. But is that true? Is the size not defined by the wrapping button element?

To protect optical sizing, we can manage this by wrapping the icon in a div (in HTML) or frame (in Figma) to manually set its vertical or horizontal position.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Ficon-bounding-boxes%2F4a95d53e-337f-41e6-a401-8c92470010e7.jpg?alt=media&token=183be2b3-c666-4b5a-87d7-9d110a97a949","id":"4a95d53e-337f-41e6-a401-8c92470010e7","width":1080,"height":640,"filename":"icon-bounding-boxes-annotation-icon-list.jpg","type":"image/jpeg","caption":"An illustration showing an iconList component with a dotted pseudo bounding box.","border":false}]}
```

This would be the same if we were looking at something like an icon list, as demonstrated in the above asset.

\--

This article will likely be ongoing.

Thanks!

Do we really need icon bounding boxes?

Having played around with typography variables *quite a lot*, here's some structure advice!

Set up two collections:  

1. Typography primitives

2. Typography 

Number 1 will save you a tonne of time later on because of how efficient aliasing can be.

### Typography primitives

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2Fefeefbd9-dc78-4206-a7a4-cc4ddb8dce7d.jpg?alt=media&token=24812301-83f6-4c97-9d26-3edf8f223f5a","id":"efeefbd9-dc78-4206-a7a4-cc4ddb8dce7d","width":2160,"height":2160,"filename":"font-families.jpg","type":"image/jpeg","caption":"Showing the Figma interface for a \"typography primitives\" variables collection","border":false}]}
```

Within the **Typography Primitives** collection, set up variables for your system's font families. The easiest naming convention here is to follow the font type e.g. *Font Sans*, *Font Serif*, and *Font Mono*.

**Font scale**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2Fd954c18b-4b46-4091-8cb8-e300ddce9b6b.jpg?alt=media&token=b78dbf77-1ea1-4866-9e37-203850507bcf","id":"d954c18b-4b46-4091-8cb8-e300ddce9b6b","width":2160,"height":2160,"filename":"font-scale.jpg","type":"image/jpeg","caption":"A screenshot of the font scale group within the typography primitives collection","border":false}]}
```

Additionally, within this collection, create variables for font *Scale*. These match your lower and upper limit font sizes, which will be defined by how your brand is set up. 

Scale here is a useful more generic word compared to size, which also won't confuse size within your larger system. For example, a small or large component may be confused with your type primitives. This also aligns a lot closer to font size scale factors e.g. golden ratio.

> Scale will typically match a calculation-based system in your code setup (usually REMs in CSS). A bit more info about this can be found over on [CSS Tricks](https://css-tricks.com/almanac/properties/f/font-size/). There are many different units for fonts, but that's a rabbit hole for another time.

You may need 3, 5, 10...100 variables for your scale, depending on how wide your system goes. Do you have mobile / web / tv? This will increase the amount of variables that you need to support here, but you can see the power of supporting many different outputs from a single primitive collection.

**Font weight**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2Fc11e23be-9668-4555-9cbe-5b7456a9b2ba.jpg?alt=media&token=39132560-297f-4d02-b008-8a3aff488eee","id":"c11e23be-9668-4555-9cbe-5b7456a9b2ba","width":1080,"height":1080,"filename":"font-weight.jpg","type":"image/jpeg","caption":"Screenshot of the Figma variables panel showing a Font Weight group within a collection","border":false}]}
```

Within Typography Primitives, I advise including *Font Weight* variables too. 

The easiest way to look at this is that you will need:

1. Number variables for weight e.g. 100, 200, 300. This matches the CSS number scale, more information over on [Mozilla](https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-weight)

2. String variables for style e.g. italic, bold, oblique

This is confusing to begin with, because font weights work with both number and string variables! Additionally, Figma works differently to CSS.

In CSS, you can write:

```
p {
    font-style: italic;
    font-weight: bold;
}
```

However, in Figma, these are a *single field*. This presents us with a decision and/or a challenge – we **can't** write *700 italic* as a single number variable, but we **can** write *Bold Italic* as a string variable. 

Hopefully this helps when trying to plan out what variables you will need to create for your text styles. 

But wait! There is one more thing. Not every font sets up their font weights and styles in the same way, meaning *Semi Bold* in Inter, is actually *SemiBold* in Roboto 🤯. This means we would need to create two variables.

> This is explored more in my community file [Typography variables: System fonts boilerplate](https://www.figma.com/community/file/1364979538897082048).

### Typography collection

**Font groups**

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2Fd2d2ac03-aef3-4414-b7a8-63db31bc9d5a.jpg?alt=media&token=7a8cbb7f-3534-4910-906e-688f2cc772de","id":"d2d2ac03-aef3-4414-b7a8-63db31bc9d5a","width":2160,"height":2160,"filename":"font-groups.jpg","type":"image/jpeg","caption":"The typography collection, showing groups for each font style","border":false}]}
```

For efficiency, in the main *typography* collection we create groups for each of our composed styles – for every *text style*, we create a variable group.

This looks like duplication, but will save you a lot of time later on. I promise! We can alias each primitive that we created earlier into these more semantic variables.

This is beneficial in a few ways:

1. If the brand sans serif font changes, instead of altering every single text style's definition, we change a single primitive

2. If a style's size needs to change, we remap to a variable within its group, or change the primitive scale value. This reduces the need to change individual style values, which in a large system may be out of your hands

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2F73776a66-10b1-4a40-a16f-e3bcdd8718a4.jpg?alt=media&token=8132d707-b9c8-467a-9f0e-f479d45f058b","id":"73776a66-10b1-4a40-a16f-e3bcdd8718a4","width":3200,"height":2160,"filename":"type ramp.jpg","type":"image/jpeg","caption":"The variables collection and corresponding type styles. There are arrows pointing from the variables into the type style that uses them","border":false}]}
```

With this approach, our variables are piped straight into the text style! We outsource the heavy lifting to the variables panel, and the type style becomes the user-facing end result.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FlSonxE9PEThEl2hzL4kc%2F69e307cf-bf5f-402f-8883-a4777a673fe5.jpg?alt=media&token=61d22353-02d3-42ab-ad01-b03d30da8fb1","id":"69e307cf-bf5f-402f-8883-a4777a673fe5","width":3200,"height":2160,"filename":"type ramp styles.jpg","type":"image/jpeg","caption":"A swatch style layout for 3 type styles, showing how their variables are used for their values.","border":false}]}
```

This is all explored in the [Simple Design System](https://www.figma.com/community/file/1380235722331273046) kit, available on the Figma community too.

See you next time 👋

\--

\~ [Original Tweet thread](https://x.com/disco_lu/status/1816860352090636555) \~

Loose thoughts: Typography variables structure

* Bias for action

* Talk to the room you're in: kick acronyms and buzzwords to the kerb

* Over-communicate project status

* Bullets, not paragraphs

* Talk slower

* Share everything you know

* Build a consistency muscle

* Ask for help

* Less "I", more "we"

Original tweet: https://x.com/disco\_lu/status/1781316093052629064

Career advice

## An idea 💡

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2Fce479095-92be-4a16-af82-8547185029b5.png?alt=media&token=5d420385-ced4-4f40-a5db-1fc948924030","id":"ce479095-92be-4a16-af82-8547185029b5","width":3840,"height":2160,"filename":"F8FW3mcXUAA28uG.png","type":"image/png","caption":"","border":false}]}
```

If your hover states are consistently within the same colour range e.g. adding 30% black to \*anything\* that is hovered, then instead of creating variables for every single variable's hover state, you create a single ––hover variable and use it within a composite style.

### With a card and tab example

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2F585f5aac-1922-46ac-a030-a14e433c70d0.jpg?alt=media&token=63059478-20f3-4748-b34f-335014a5134d","id":"585f5aac-1922-46ac-a030-a14e433c70d0","width":2160,"height":2160,"filename":"F8FZNKNXoAAvSn-.jpeg","type":"image/jpeg","caption":"","border":false}]}
```

Where it quickly falls apart is if your colour adjustments are more manual, or if your colours don't fall within the same visual range.

My initial palette differed wildly, meaning that manual adjustments were a requirement.

You could have several composite hover **rules** though 🧐

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2F76e08c86-5b4d-4735-b084-10995691e4f7.jpg?alt=media&token=f3ced441-27ae-4279-92de-62f3f790da25","id":"76e08c86-5b4d-4735-b084-10995691e4f7","width":3840,"height":2160,"filename":"F8Fbh9iWoAAtTQh.jpeg","type":"image/jpeg","caption":"","border":false}]}
```

If anything, this approach it can highlight the differences in your colours. If you can bring your colours all within the same saturation range, this idea would work.

### Further thoughts

Thinking about this a bit more, I don't think a specific --hover variable is needed, it might be too specific to that interaction.

If your system uses a single mode (light / dark), then you could get away with something like this:

`––darken-interactive` \
`––darken-subtle` \
`––darken-strong` \
`––lighten-interactive` \
`––lighten-subtle` \
`––lighten-strong` \
`––brand-subtle` \
`––brand-strong` \
`––accent-subtle` \
`––accent-strong`

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2Fc55c6aba-6f05-4591-b9f1-19d62c5272d0.jpg?alt=media&token=5d5a5f86-9bd7-4321-8db2-8dd0e1fa062d","id":"c55c6aba-6f05-4591-b9f1-19d62c5272d0","width":2880,"height":2160,"filename":"F8UZhuJXoAAJ4ww.jpeg","type":"image/jpeg","caption":"","border":false}]}
```

It introduces two groups into the variable structure: 

1) Modifier – System: This is where you store the fixed darken / lighten variables \
2) Modifier – Brand: Any brand coloured tints you might need

They are both offered in subtle, interactive (for the previous hover), and strong.

If you are using multi modes (light **and** dark), then abstracting the names out will probably work.

So instead of lighten/dark – because they don't make sense in the other mode – we use `--overlay` and change the values in each mode.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2F7c81448d-c958-45ce-a259-7206f9b53fbb.jpg?alt=media&token=bb2314cd-3635-4a81-9432-01d76ae7bf5b","id":"7c81448d-c958-45ce-a259-7206f9b53fbb","width":3840,"height":2160,"filename":"F8UaWI2WoAEbvKs.jpeg","type":"image/jpeg","caption":"","border":false}]}
```

But what about when we need `black 6%` to always be `black 6%`? 

This would likely call for a fixed variable value across modes, so we'd get: 

`––overlay-fixed-dark-subtle`\
`––overlay-fixed-dark-strong`\
`––overlay-fixed-light-subtle`\
`––overlay-fixed-light-strong`

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2Fplo9LTyXyc7S74aji55Q%2F95c28aa3-2dab-4fa6-9e86-3d5e6af42662.jpg?alt=media&token=fd9dbe4a-a355-44ff-870b-b22f079d1c1d","id":"95c28aa3-2dab-4fa6-9e86-3d5e6af42662","width":2880,"height":2160,"filename":"F8Uaqj-XsAAnZdq.jpeg","type":"image/jpeg","caption":"","border":false}]}
```

Let me know what you think!

Thinking out loud: Variables – Consolidating states

I have a consistent routine when I work with a new designer. I head to Google, search "8px grid Medium.com", pull up Elliot Dahl's comprehensive guide and send it to them. Here's the guide: <https://medium.com/built-to-adapt/intro-to-the-8-point-grid-system-d2573cde8632>.

This guide is fantastic, and would highly recommend. I have, until this year, treated multiples of 4 (not 8!) as practically my design bible. New element? Surely the left padding is 16, the top is 12? Every...single...time.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2F67cec03d-7cd2-4d79-b14c-02d3520d9ce9.jpg?alt=media&token=8f5b4747-bd4a-47fb-9219-efac769b0fd4","id":"67cec03d-7cd2-4d79-b14c-02d3520d9ce9","width":1920,"height":1080,"filename":"badges-12-16.jpg","type":"image/jpeg","caption":"A pill component with labels pointing to the padding values. The left and right padding is 16, the top and bottom is 12.","border":false}]}
```

Whilst this approach to designing can help with predictability, and becomes muscle memory for setting components up really quickly, I can't help but think we've ran ourselves into a world where unfortunately everything looks the same.

### Odd numbers

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2Fc80e9352-62a4-40af-9e79-118a47aa06c5.png?alt=media&token=4da3581a-1f46-4b8b-b8b2-05d94401bfa0","id":"c80e9352-62a4-40af-9e79-118a47aa06c5","width":1920,"height":1080,"filename":"badges-comparison.png","type":"image/png","caption":"A comparison between a pill component set with even numnbers for padding against one that has been set with odd numbers.","border":false}]}
```

Perhaps it might be worth us considering using odd numbers for spacing instead of even, in order to shake things up and keep us all sane.

```
I'm prepared to go to grid system jail.
```

The issue I have with the even number 4px calculation grid systems is that they can feel a bit loose, either vertically or horizontally. Although this is the de facto standard in product design now, I find myself getting focussing on what feels like a few pixels of extra flab within our components.

### Comparing

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2F3ae39fdd-e57b-46f6-92ac-df8b6eff042e.jpg?alt=media&token=7596090b-2ca7-4e4e-a7c1-9cebdd3594e7","id":"3ae39fdd-e57b-46f6-92ac-df8b6eff042e","width":1920,"height":1080,"filename":"badges-comparison-values.jpg","type":"image/jpeg","caption":"The same comparison of pill components using either the traditional spacing logic, or the odd one, but with their padding values overlaid on top.","border":false}]}
```

Let's look at a comparison. On the left of the above image we have the traditionally spaced components in their 4px system. On the right, we're tweaking to be odd numbers. Personally, they **feel** better. What do you think?

What I've done here, is tweaked things manually up or down by a pixel or two in order to refine the padding to feel tighter. This stands out particularly well in the second and fourth pills from the top, where when comparing you can see that the odd number approach feels way more consistently padded.

### What about fonts?

The first pushback against this idea may come from the difference in how fonts would disrupt the spacing because of their inherit sizes. 

Let's take a look!

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2F0b28c031-dabc-401e-ad64-39628f0b5d74.jpg?alt=media&token=efae97da-f66a-4f9b-9127-f971e9672882","id":"0b28c031-dabc-401e-ad64-39628f0b5d74","width":11514,"height":4320,"filename":"badges-fonts.jpg","type":"image/jpeg","caption":"A comparison of 6 fonts using the 4px system or the odd system: Oxygen Mono, Noto Serif, Roboto, Poppins, Palatino, Koulen.","border":false}]}
```

Interesting! There is little difference in how things feel. You still get the same tighter end result on the odd spacing whether it's a mono or serif font.

What is important to note here is that line height would have an impact on how this all comes together. This works fine for single line text, set at 100% line height, but for larger areas of copy we would need to experiment.

> Important
>
> Within these pills, all of the font sizes and icons were set to an even size! So perhaps the combination of even inner and odd outer can provide us with harmony.

### In the wild

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2Fae6a333e-9fa6-4e82-915f-83ec5c0184d0.jpg?alt=media&token=8d003fbf-7d8b-4ae7-80a1-69941973aa83","id":"ae6a333e-9fa6-4e82-915f-83ec5c0184d0","width":4096,"height":2626,"filename":"notion-mail.jpg","type":"image/jpeg","caption":"Screenshot of the Notion Mail landing page hero, with annotations on top of the form showing their pixel perfection.","border":false}]}
```

I came across Notions approach to this recently whilst looking at their new [mail landing page](https://www.notion.so/product/mail). 

They have approached this by mixing even and odd numbers to great effect. They have fine tuned the padding of the button to be odd numbers for *feel*, but then used the classic border radius calculation to have fine tuned but calculated radii for the inner and outer elements.

### Systematising it – Introducing Fibonacci

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2Faee09b77-e54f-41be-ad49-d8f9801703fd.jpg?alt=media&token=10c81dad-f413-414f-8c4f-e62524fd8601","id":"aee09b77-e54f-41be-ad49-d8f9801703fd","width":4096,"height":2048,"filename":"fibonacci.jpg","type":"image/jpeg","caption":"A comparison of the 4px grid system against the Fibonacci scale.","border":false}]}
```

If I were to try and roll this idea out into a system, I'd probably want to at least try to build in a method to the madness. This is where we can lean on systems like the Fibonacci sequence to handle the heavy lifting.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2F93eaab70-dfee-4e83-ab64-cce6c2869d35.jpg?alt=media&token=8bd1ae46-60ba-4a8e-9ed8-5408e65d5368","id":"93eaab70-dfee-4e83-ab64-cce6c2869d35","width":3780,"height":3760,"filename":"4px-system.jpg","type":"image/jpeg","caption":"The 4px grid.","border":false}]}
```

In the 4px system, we space like this – A base unit of 4, then multiple it by 1 (or x.5 if we're being funky) to get our system: 

1. 2 (0.5x)

2. 4 (base)

3. 8 (2x)

4. 12 (3x)

5. 16 (4x)

6. 20 (5x)

7. 24 (6x)

8. etc

But the Fibonacci system would work by adding the two previous values together.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2Fdc489035-5699-4f59-936c-5b5337fe9e7d.jpg?alt=media&token=6bd80414-6a03-474a-92ea-1eac8a098457","id":"dc489035-5699-4f59-936c-5b5337fe9e7d","width":3780,"height":3760,"filename":"fibonacci-system.jpg","type":"image/jpeg","caption":"The Fibonacci spacing system.","border":false}]}
```

1. 1

2. 2

3. 3

4. 5

5. 8

6. 13

7. 21

8. etc

Like we discovered earlier, it's definitely...odd, but there's something here I like.

```cv
gallery
{"layout":"hscroll","images":[{"src":"https://firebasestorage.googleapis.com/v0/b/maitake-project.appspot.com/o/pages%2FSMCOShPFoYg3m7Hf7Sfs7MDDg6j2%2FqcpDfxm43wYEh97rbCNl%2F369696fc-d669-4762-af37-fbe4fba975c2.gif?alt=media&token=559376d9-72e8-423c-a1d7-5b4ad9e1cf48","id":"369696fc-d669-4762-af37-fbe4fba975c2","width":2048,"height":1025,"filename":"4px-vs-fibonacci.gif","type":"image/gif","caption":"A comparison of the 4px grid system versus the Fibonacci one, using a slider.","border":false}]}
```

When comparing the systems on an example component, the differences are minor, but isn't that what we're here for? That's a rhetorical question 🤣

### Further reading

Some very clever folk in the industry have made tools I'd recommend checking out:

1. <https://utopia.fyi/>

2. <https://symbols.app/docs/sequence>

3. <https://proportio.app/>

\~

This was originally posted as two separate [threads](https://x.com/disco_lu/status/1653395731451969537) over on [Twitter](https://x.com/disco_lu/status/1759641396846239795).

Loose thoughts: Saying bye to 4px spacing and hello to Fibonacci

Published a variable starter kit file to the community! https://www.figma.com/community/file/1256624568359563073/Variable-starter-kit