Field Notes /Design · 12 min read

Why we treat the design system like an operating room

Sterile, named, instrumented. A design system isn't a Figma library — it's the connective tissue between intent and implementation, and it deserves the same precision.

orbit system as architecture
Field Notes № 08 · Lead essay

The first time I watched a surgeon prep a tray, I understood design systems differently. Every instrument had a name. Every name lived in a known place. The placement was not aesthetic — it was muscular. A scalpel reached for in the dark had to be a scalpel, every time, or someone died. That is the standard.

We don't usually talk about design tokens this way. We talk about them like garden ornaments — pretty primitives we lay out across a Figma page and admire. But a token isn't a swatch. It's an instrument. It has a name, a place, a measurable shape. And when you reach for color.brand.500 in a hurry, it had better be the same value every time, on every surface, or someone — a customer, a contractor, future you — gets cut.

The pre-op

Before any meaningful design work, there is a checklist. Not the kind designers usually mean — "have we audited components?" — but the kind a circulating nurse runs through before a procedure. Are the instruments named? Are they in the right tray? Is anything missing?

  • Every primitive has a canonical name. portica.500, not "the yellow we use sometimes."
  • Every semantic alias points back to a primitive. color.surface.paper = portica.50.
  • Every component token references a semantic, never a primitive directly.
  • The graph is acyclic, traceable, and exportable.

This is unglamorous work. It is also the only work that compounds. Every shortcut here — a hex code committed inline, a one-off tint, a "we'll name it later" — becomes a procedure-stopping infection three months from now.

Primitives portica.50portica.500portica.900mantis.500ink.900 Semantic surface.paperbrand.fillink.primarystatus.success Component button.primarybadge.successcard.surface
Fig. 01The token graph as it appears in Studio, mid-procedure.

Naming the instruments

"Bikeshedding" is the word engineers use when teams argue about names instead of doing real work. It is one of the most damaging metaphors in our field. Naming is the work. A well-named token compresses a paragraph of intent into a single phrase, then lets that phrase travel — across files, surfaces, decades.

The names we like at UISqueezy are locating, not describing. color.brand.500 tells you where to find a thing. color.warm-orange tells you what the thing currently looks like — until brand spring '27, when it becomes pink, and now your whole codebase is lying.

A name is a promise that survives a redesign.— Notebook, 12 March

The same principle applies to spacing, type, radius, motion. space.gutter survives. space.24 survives only until you change the gutter to 28, at which point you have a token whose name is a lie.

A clean field

Surgeons keep their field clean by removing anything that isn't essential. Instruments not in use go off the table. The system rule is the same: every token in the catalog should be currently load-bearing. Tokens kept "just in case" are the design system equivalent of the intern's water bottle on the surgical tray. They aren't neutral. They're a hazard.

Tokens kept just in case aren't neutral. They are a hazard.

This is why we run the catalog as a strict subtraction game. Anything that hasn't been referenced in the last 90 days surfaces in a weekly review. The default is removal. The burden of proof is on the token to justify its place.

Q1 +18 −42Q2 +14 −36Q3 +11 −48Q4 +9 −31 added vs. removed · 2025
Fig. 02Quarterly subtraction report — tokens removed vs. added.

When the system bleeds

Sometimes a token escapes the catalog. A designer pastes a hex code into a component because the review meeting is in twenty minutes. An engineer writes a one-off color into a marketing page that the brand team didn't see. These are bleeds — small ones individually, fatal in aggregate.

Our discipline here is unsentimental. Every export pipeline runs a contrast and consistency check before it touches main. Anything not in the catalog is rejected, with a link to the right token. We treat this like a sterilization protocol: it is not a debate, it is the floor.

Closing up

I think a lot about what makes a system finished. The honest answer is: it never is. Surgeons close up at the end of a procedure, but they don't pretend the body is done. They are returning it to a state where it can heal, move, work — until the next intervention.

A design system, similarly, is never finished. It is closed up at the end of every quarter, returned to the team, and reopened the moment a new product surface demands a token nobody anticipated. The work isn't to complete the system. The work is to keep it operable.

That is what we are building UISqueezy for. Not a Figma library. Not a token vault. An operating room.

OP
Onur Pamuk
Co-founder & head of design at UISqueezy. Previously at two design-system teams that bled out.