The Brief Design System: re-architecting the foundation

The platform had outgrown its original system. As the editor grew more complex, 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.

So I re-architected the whole thing on a new MUI foundation, rebuilding the structure from the tokens up so the system could scale with the product.

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 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 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.

Underneath the components sits 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.

Type follows the same rule. Inter carries the whole UI, and every step is a named token with a fixed size, weight, line-height and letter-spacing, so type is applied by role rather than eyeballed per screen.

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.

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.

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.

After Ad Studio, Brand Kit, Templates, the share link and the Dashboard moved onto the system, with Storybook as engineering’s single source of truth.

Adoption was checked twice. Every Figma component had a matching name in Storybook, so developers could find the coded version of anything in a design. In design review we compared each build against its Figma component, down to the label’s size, colour, weight and family and the button’s size, radius and background. In code review, engineers checked that every component came from Storybook.

Before the system, several developers could each build their own version of the same thing, like a dropdown with icons and text. The system shipped one selector with its variants, the menu that opens from it and the items that menu can hold, and we saw fewer QA issues as a result.

The pushback was speed. Developers hit cases the library didn’t cover yet, and the Storybook check in code review added time. So surfaces moved onto the system when a feature touched them anyway, and a missing component was added when a story needed it. That way adoption rode along with roadmap work.

The last 5% was legacy screens, a few specialised one-offs and corners of the product that rarely saw development work. None of it mattered enough to migrate for its own sake, and users didn’t feel the difference.