Building the eLockr Design System

eLockr lets companies issue digital, fraud-proof work records — a product whose entire value is built on verification and trust. For the first year, I was the sole designer. I moved fast and kept every decision in my head: the exact blues, the button padding, which grey meant "disabled" versus "subtle."

With one person touching all the files, that worked. There was no drift because there was no divergence possible. But the system was undocumented by design, and my mental model was the only source of truth that existed.

When the design team grew, inconsistencies appeared immediately — not because new designers were careless, but because there was no shared reference. Colour usage, type scales, and spacing varied across features. Design reviews shifted from solving user problems to debating pixel values: 30–40% of review time spent on "which grey is this?" instead of outcomes.

The stakes were higher than aesthetics. eLockr sells fraud-proof verification records. Visual inconsistency directly undermines the trustworthiness the product promises to every employer and employee who uses it.

Before building anything, I set constraints that every new pattern would have to pass — the criteria for every component review, every token naming decision, every "should we add a variant?" conversation.

The system is layered. UI never touches primitives directly — it only consumes semantic tokens. This indirection is what makes the system scalable: one change at the top propagates everywhere below it automatically.

Six ramps on a 50–900 scale — Blue (brand), Dark Blue (ink/navy), Grey, Green, Red, Yellow. Step 500 is the anchor. Steps 50–100 are tinted surfaces; 200–300 are borders and fills; 600–900 hold WCAG AA contrast for text on light surfaces.

40+ tokens across three groups: Surface, Border, and Text/Icon. Designers pick by intent — "the danger surface" — never by value. This is the only layer components touch.

The same naming pattern runs across Figma Variables, component properties, and CSS custom properties. A developer reading a token name in Figma knows exactly what to write in code.

Poppins for display (H1–H4) gives eLockr its confident, geometric voice. Inter for everything below keeps dense record data legible. Three weights per level — Bold, Regular, Light — never more. Poppins never used below 20px.

A single number scale — 2, 4, 6, 8, 12, 16, 20, 24, 32, 40 — drives all padding, gaps, and margins. If a measurement isn't on the scale, it's wrong. The scale maps 1:1 to engineering CSS variables, so space-16 is always 16px with no lookup.

Smaller elements get smaller radii so curvature looks optically consistent across scales. M (8px) is the workhorse for buttons and inputs. Full (999px) for pills, badges, and avatars.

Five levels. Most of the UI lives flat at level 0 with borders. Shadows are reserved for elements that genuinely float: dropdown menus (M), toasts (L), modals (XL). Elevation communicates hierarchy — not decoration.

Every component is built entirely from semantic tokens — no local overrides, no detached instances. Variants cover state, size, and content type. If a pattern appears twice in the product, it becomes a component with a changelog entry.

Semantic versioning governs how changes propagate. Patch versions auto-adopt; minor versions are opt-in; major versions ship with a migration guide and a deprecation window. The contribution flow: propose in #design-system → build in a branch → review against the four principles → publish with a changelog entry.

Measuring a design system's value is harder than shipping it. These numbers come from sprint retrospectives and team check-ins 8 weeks after v1.0 launched.

Shipping the system was the straightforward part. Understanding what slowed it down came after.