A design system, one person deep

When I started designing LexDoor, there was no interface yet, and no design system either. The product covered a lot of ground: service intake, data reports, a knowledge base, a form builder and incident response tools. That's a lot of screens for one designer to keep consistent from memory.

So I started the system on day one, in parallel with the product itself. Not because it's fashionable, but because I knew that future me would be very grateful, and future engineers even more so.

The brand guidelines went straight into the system: colour styles, icon weights, text styles. The interesting bit was the typeface. Poppins is rounded and generous, so at the usual sizes it looks noticeably bigger than a neutral font like Inter.

Instead of fighting it screen by screen, I changed the foundation: the base rem went from the usual 16px down to 14px. Everything that inherits from it suddenly felt right-sized.

A happy side effect of the 14px rem: paddings, margins, gutters, thicknesses, heights and widths could all line up on multiples of 7px. It gave every component and every screen the same quiet rhythm, which is the kind of thing nobody notices until it's missing.

The most important part of a design system isn't how it looks. It's whether its components are well structured, consistently named and fully reusable in every Figma file that depends on them. Pretty but fragile helps nobody.

A design system becomes really useful when it's more than a pretty file. I organised the tokens semantically, so designers and developers could look things up in the same place and speak the same language. Every token maps to a component value, and those values match the components that were actually built.

Style libraries and variables were kept in sync, so the design file and the codebase stayed close friends instead of distant cousins.

Like every design system, this one stayed home: it lives on in UnitedLex's Figma, and I kept a copy to remember how it grew.