all servicesF̶aramarznia
service 04 — Design System Specialist

Your team has rebuilt the same button five times.

I build the token and component layer so changing one variable updates the whole product — and so a new screen assembles instead of being drawn from scratch.

This is the whole pitch, running live: change a token, every component below updates at once.
Active
Account

One token change, four components updated.

primitive   --hue-brand   : 310
            --radius-md   : 10px
            --space-unit  : 16px

semantic    --color-action: hsl(310 82% 60%)
            --color-onact : hsl(310 60% 8%)

component   --btn-radius  : var(--radius-md)
            --btn-pad-x   : calc(var(--space-unit) * 1.5)

Hire me for this when

  • 01several squads ship UI that no longer looks related
  • 02a rebrand or a dark mode would mean touching hundreds of files
  • 03design and engineering argue about handoff every sprint
  • 04you are going from one product to a family of them

Where this starts and stops

starts at

When inconsistency costs more than it saves — usually the second product or the third designer.

ends at

With tokens, components, documentation, and evidence that people are actually using them. Adoption is the deliverable, not the file.

  • This is not a UI kit dropped in a folder. An unadopted system is a cost, not an asset.
  • This is not deciding what to build — that is Product Design.
  • I build it with your engineers in their stack, or it will not survive me leaving.

How I work

  1. 01

    Inventory the truth

    Every button, every input, every shade in production. The number is always worse than the team expects.

  2. 02

    Three token layers

    Primitive to semantic to component. A colour is never used raw, so theming later is a variable change and not a rewrite.

  3. 03

    Components with every state

    Default, hover, focus, disabled, loading, error. A component missing states just moves the work downstream.

  4. 04

    Document where engineers read

    In the repo, next to the code. Documentation in a design tool nobody opens is a system that quietly dies.

  5. 05

    Measure adoption

    Percentage of screens on system components. If it is not climbing, the system has a usability problem of its own.

Proof

On Developica screens now assemble from documented primitives instead of bespoke layouts. On IranBroker semantic colour tokens gave gains, losses and pending states one meaning across the whole platform. My honest lesson: I under-documented early, and it only paid off once the rules lived where engineers could reach them.

developicaread case study iranbrokerread case study

Need a system that survives you?

Tell me how many products it has to serve and which stack it lives in.

Talk about your system