Skip to main content
Back

Design System & Component Automation

Codified rules for how components are constructed (variants, states, auto layout) and a Tokens Studio pipeline that keeps Figma and code in sync.

Role
UI/UX Designer (Design Systems)
Year
Platform
Figma, Tokens Studio, web front-end
Team
NSG Geospatial Services

Context

Across several products the team was rebuilding the same buttons, inputs, and cards with small differences each time, and design tokens lived in two places: Figma styles and hand-maintained CSS variables that drifted apart.

Constraints

  • Rules had to be usable by designers who are not engineers, so they were written as construction checklists, not code.
  • The token pipeline had to fit into existing repositories without a large migration.

Design decisions

  1. [PLACEHOLDER] Decision 1 — replace with the key design decision

    [PLACEHOLDER] Why this option was chosen over the alternatives. To be written by Mohammed; interview material.

    Rejected alternative: [PLACEHOLDER] What was considered and rejected, and why it lost.

  2. [PLACEHOLDER] Decision 2 — replace with the second decision

    [PLACEHOLDER] Reasoning goes here.

    Rejected alternative: [PLACEHOLDER] Rejected alternative goes here.

Outcome

A written standard for component construction: naming, variant properties, state coverage (default, hover, focus, disabled, error), and auto layout rules.

A Tokens Studio pipeline exporting tokens from Figma to a JSON source of truth and generating CSS variables, so a colour change in Figma reaches code without a manual step.

Retrospective

The construction rules had more impact than the tooling. Once every component followed the same variant and state model, automation became straightforward; before that, there was nothing consistent enough to automate.

  • Design system
  • Design tokens
  • Tokens Studio
  • Figma
  • Automation