Meridian

When I joined Meridian, the platform had eleven shades of grey, four button heights and a documentation site that was last accurate eighteen months earlier. Nobody was being careless. Teams had simply solved the same problems in isolation, many times, because the shared vocabulary was too coarse to describe what they actually needed.

Naming is the work

We rebuilt the system around a small grammar instead of a big library. Every token answers three questions: what role does it play, what context does it live in, and what state is it in. A surface token is not “grey 200”; it is the quietest plane in a panel, and it changes with the theme.

That grammar paid for itself immediately. Designers could reason about a token they had never seen, engineers could predict a name, and reviewers finally had a shared sentence to argue with.

Source of truth, singular

Tokens lived in one JSON file, transformed through Style Dictionary into CSS custom properties, Swift constants and Figma variables. Documentation was generated from the same source, so a stale page became a build failure rather than a discovery. The tooling was deliberately boring: no service to maintain, no dashboard to forget.

A system is a social contract

The governance mattered more than the components. We introduced a lightweight RFC with a two-week comment window, weekly office hours nobody was required to attend, and a deprecation policy that always named a replacement. Contribution went up, and — more importantly — the number of quiet local forks went down.

• Before: teams copied components and drifted.
• After: teams proposed changes in public and the system absorbed them.

What I carry with me

Design systems fail as products, not as libraries. The adoption curve is a trust curve: it moves when the system is easier to use correctly than it is to work around. Half the job is writing documentation people actually read — the other half is being the kind of colleague people are willing to send a rough idea to.