The Layer Under Your Design System - Pt 1

It’s easy to focus on the parts of a design system that show up on screen. That’s what everyone interacts with, so it naturally steals the attention. But most of the behaviour comes from a layer sitting underneath it. That layer handles tokens, naming rules, asset prep, build steps, and all the steps that decide how design intent becomes something the product can actually use.

It's not the kind of work that ends up in a demo, which is probably why it fades into the background. Nobody gets promoted for fixing token inheritance. But when it loses structure, things start to wobble in ways that don't look connected at first. You might notice:

• colour that lands slightly off
• spacing that feels tighter or looser depending on the screen
• a component behaving differently across areas of the product
• motion timing changing even though the intent didn’t
• an asset rendering clean in one environment and odd in another

None of that starts in the UI. The UI just happens to be where it becomes visible.

How small changes begin

The source usually sits inside the workflow. It shows up as shortcuts that feel harmless at the time:

• updating a token manually
• bending a naming rule because it wasn't written down
• exporting a file by hand because it felt faster
• nudging timing locally because nothing enforced the source
• adjusting layout slightly to just get it through

Each one feels like saving time. Each one costs you later.

Each shortcut changes something. One touches spacing. One alters motion. One adjusts behaviour. They seem minor on their own, but over time they make the system harder to recognise.

You usually feel it before you see it. Something's inconsistent but nobody can point to why. Cue the meeting where everyone nods and nothing gets fixed. That's when the layer underneath starts to get noticed.

And once you start seeing it, the pattern shows up everywhere. Not because people are doing it wrong, but because the workflow left the door open for interpretation. Which is why this layer eventually needs structure instead of good intentions. "We'll just remember to do it right" has never worked, but every team tries it anyway.

What this layer actually shapes

This layer decides more than it gets credit for. It influences:

• how tokens are defined and stored
• which files count as the real source
• how assets move through the build
• how output stays consistent
• how transformations are handled
• how formatting and structure are applied
• how interaction timing stays aligned across screens

When these rules live in the workflow instead of in someone's head, things stay predictable. Otherwise you're one resignation away from nobody knowing how anything works. When they rely on habits, behaviour drifts until it's hard to trace back.

Why automation starts here

UX automation often targets this layer first because it’s where repeated work lives. The more rules move into the workflow, the less effort goes into patching tiny mismatches later.

Automation helps by taking work away from memory:

• repeated manual steps
• back-and-forth handoffs
• decisions based on whoever wrote the last thing
• "just for now" changes that become permanent because nobody remembers they were temporary

Once this moves into the workflow, the system begins to feel lighter:

• designers know which token to use
• engineers aren’t hunting for the real source file
• components behave the same way across pages
• motion and interaction don’t need constant tweaking
• spacing becomes dependable instead of improvised

This layer decides whether a system holds together over time. And once you see what it affects, it becomes easier to see where automation might actually help.

We’ll dig into this next in Part Two, and look at which decisions are better off living inside the workflow.