I wanted to build a design system the way a product team would: not as a page of polished swatches, but as a system designed to scale and adapt over time. That meant moving beyond colour styles and working with Figma variables, aliasing, modes, and reusable components.

With one-off styling, the same raw value can appear across dozens of layers, making a rebrand or new theme a manual search. In Lattice, foundational values are separated from semantic roles, so components depend on what a value means rather than the colour or number it happens to hold today.

Lattice uses atomic design as an organizational model for moving from foundations and individual controls to complete pages. It allowed me to evaluate components both in isolation and in the context of larger interface patterns.

The token layer forms part of the atomic foundation. Components and larger patterns draw from the same semantic variables, making consistency part of the system rather than something recreated at every level.

Beneath the component library sits a three-tier token architecture built with Figma variable collections rather than disconnected styles. Brand foundations feed aliases, and aliases feed semantic roles. Components then consume the semantic variables as the applied layer of the system.

Seven colour scales were developed in OKLCH to create a more consistent progression in perceived lightness across different hues.

The scales provide the foundational colour values for the system. Components do not select these values directly; they use semantic roles mapped to the foundations through aliases.

The typography layer follows the same structured approach as the colour system: two font families, a defined weight scale, and named text styles ranging from heading/h1 to body/sm/link.

More than a single button, Lattice includes buttons, icon buttons, text fields, selects, radio controls, switches, and checkboxes. Each component is built with auto layout, variants, and component properties, then styled through semantic variables.

Variants manage meaningful differences such as visual state or hierarchy, while component properties expose editable labels and optional icons without requiring designers to detach instances. Because the components reference shared semantic roles, system-level changes can flow through the library without manually restyling each component.

Change a token once, and it updates everywhere.

Building Lattice pushed me past surface-level Figma into the mechanics that make a design system maintainable: variable collections, aliasing, semantic naming, modes, and component structure.

The most challenging part was deciding where each decision should live, whether as a foundation value, an alias, a semantic role, or a component-level option. The biggest shift in my thinking was learning to name intent rather than appearance. Once a token describes action/primary instead of “blue,” its underlying value can change without changing how the component is understood.