Design system gianlucacaico.com →
MenuClose

The model · 2 real changes, traced

Operating model

How a change goes from first sign to live on gianlucacaico.com and this design system, with the record behind every step, and how the same model maps onto many product teams.

Follow one change

Two real examples

Every change leaves a trail. Here are two real ones, a token and a component, from first sign to live, with the record behind each step.

A clash caught before it shipped.

The site's new artwork called a bright cyan --cyan, the name the site already used for a darker one.

Before

  • --cyan#0E97AA
  • --cyan#12B5CB

Two colours, one name.

After, in both systems

  • --cyan#0E97AA
  • --cyan-bright#12B5CB

One name each, checked both ways.

  1. Proposed new artwork for the site, up for review.

    6 Nov, 9:22pmReview page

  2. Caught by the drift check, before the artwork went live.

    7 Nov, 10:27amDrift report

  3. Decided by the owner: it becomes --cyan-bright, logged with why.

    Decision log

  4. Proved every image came out identical after the rename.

    10:48amChange record

  5. Approved and live on the site.

    10:52amReview page

  6. Followed by the design system, approved and in step: 22 site and 17 artwork tokens match.

    10:58amReview page

Spotted on a phone, fixed in both systems.

Filters with more options than fit on a phone scroll sideways. Their glass ended partway along, leaving a hard edge.

Before

The glass ended partway when the filter scrolled.

After, in both systems

The glass stays put while the options scroll.

  1. Spotted by the owner, on a phone.

    7 Nov

  2. Fixed the same way in the kit and on the site: the filter now draws its own glass.

    8:31pmKit review pageSite review page

  3. Proved on the site, under 0.1% of pixels changed, all inside the filters, and all 22 site tokens still match the design system.

    8:36pmCheck results

  4. Approved the design system first, then the site, 17 seconds apart.

    8:37pmKitSite

Times are Melbourne time, from GitHub's own records. Each link opens the record behind that step.

What this means for your program

From one site to many teams

The same model maps onto a typical enterprise setup: many product teams sharing one design system.

  • Every team checked against one standard

    Each product team's site runs the same two-way check against the shared design system. A difference shows up on the change that caused it, and its owner decides which side is right.

    Here: 22 tokens, checked from both sides
  • Agents for pace, owners for judgement

    Agents draft and prove every change. A named owner for each product approves it at the gate, one change at a time, and decides when any agent runs.

    Here: one owner approves every change on both sites
  • An audit trail by default

    Every change is one review page with its wording, check results and approval, and can be undone in one step. Every design decision is logged with its reason.

    Here: 14 design decisions logged so far
  • No lock-in

    The templates say what happens, not which tool does it, so teams can swap in their own agent tools and delivery pipelines.

    Here: 20 templates, from request to verified live