The Brief Design System: re-architecting the foundation

The platform had outgrown its original system. As it shifted toward AI-native workflows and an increasingly complex editor, the old library couldn't keep pace: inconsistent components, values that drifted between design and code, and no clean foundation to build new surfaces on.

The decision wasn't to patch it. It was to re-architect the whole thing on a new MUI foundation, so the system could scale with the product instead of fighting it. That meant rethinking the structure from the tokens up, not just refreshing the surface.

It started with one product. Ad Studio was the first surface built on the new system, the proving ground for the tokens, the components and the engineering workflow. Once it held up there, the same system became the design language for redesigning the rest of the platform. See Ad Studio, the product it first shipped in →

The core of the system is a three-layer token model, each layer building on the one beneath it. Primitives define the raw palette and scales; a semantic layer maps those primitives onto meaning; and components consume only the semantic layer, so the rest of the system never references a raw hex or pixel value directly. It references intent.

The system is built to compose. Atoms are the smallest sanctioned pieces: a label, a select, a text field, a toggle, an icon button, a colour control. Molecules assemble those atoms into the functional rows of the editor's properties bar. Nothing in a molecule introduces a new value; it only arranges atoms that already exist.

The hardest part wasn't any single component. It was the combinatorial problem underneath: the editor supports many element types, each with a different set of editable properties. A text layer, a video, a countdown and a particle effect don't expose the same controls.

So I mapped the whole space as a matrix: every element type against every property, with the correct property bar resolved for each combination, all from the same atoms and molecules. That's what keeps the editor coherent no matter what the user selects, and it's the structure that makes adding the next element type a known, bounded task instead of a redesign.

One family, worked hard. Inter carries the whole UI, every step a named, defined token with a fixed size, weight, line-height and letter-spacing, so type is applied by role rather than eyeballed per screen.

A system is only as strong as its boundaries. On the atoms page I split every element into “components used” versus “variants or ideas only.” Sanctioned atoms on one side, exploratory work clearly fenced off on the other.

That line matters more than it looks. It tells anyone opening the file exactly what's safe to build with and what's still thinking-out-loud, which is what stops a system from quietly sprawling into a dozen near-duplicate buttons.

A system that only lives in Figma is half a system. I worked directly with engineering to build the components in Storybook, the full set: inputs, buttons, selects and the rest, so the design source of truth and the coded source of truth were the same thing, not two drawings of it.

The shared MUI base and the semantic token layer are what made that parity practical: when design and code speak the same structural language, handoff stops being a translation exercise and the gap where drift creeps in mostly closes.

We proved the whole pipeline in Ad Studio first, design tokens to Figma components to Storybook to shipped UI, then rolled the same components out as the platform was redesigned around them.