Back

Case study · 002

SBT Living Showcase

Turned the system into something the team actually reads. Live component pages, design ops analytics, token maps, docs that derive themselves.

01 · Context

A registry no one reads is just a database.

Figma is the design source. Thanks to the agentic system, any published change propagates on its own: documentation, analytics and changelog update instantly. The Showcase is where that flow becomes legible.

02 · ComponentView

Every component, live.

Every component opens on its own page, alive. You can run it through any brand, theme and screen size, drive its props as if it were embedded in a real product, read its intent, its code and the tokens it consumes, and compare it against its Figma origin to confirm the render matches the design. The fast way to answer, in seconds, whether a component behaves and looks the way it should.

03 · Analytics

The system, read back to itself.

A view that surfaces what the system is leaning on. Which components are used most and where, which tokens are in circulation and which have no consumers left, how components nest inside one another. It is the honest read of the real state: what the organisation is actually using, what is dead weight and what deserves attention in the next iteration.

04 · Token usage

Every token, opened in detail.

Any token in the system opens up and explains itself: where it comes from, which other tokens lean on it, which components are consuming it and how it resolves in each mode. Traceability runs both ways, from a component to its tokens and from a token to the components that use it, so when a design decision moves, you see exactly who it affects before touching anything.

05 · Changelog

The system, in chronological order.

Every publication in the system is recorded with its level of impact, its context and the exact detail of what changed. Tokens and components carry their own history, ordered and filterable, so anyone can read the evolution of the system without opening Figma: what was added, what was adjusted, what was retired and why it matters. Version control built for the human eye, not just the commit.

06 · Lifecycle

Drafts and stable, kept apart by design.

Every component lives in two phases. While it is still being shaped, its versions are drafts (0.x.x) and carry a separate badge; once it reaches a real production state, it is promoted exactly once to v1.0.0 and every update after that is stable. The showcase makes that boundary visible: a drafts view for work in progress, a snapshots view per component and a lifecycle panel that shows where each piece stands. No one has to guess what is an experiment and what is a contract.

07 · Foundations

The primitives, with their own documentation.

The primitives that hold the system together (colour, typography, space, shadow, gradients, surfaces and icons) come with their own documentation, derived from the same code that is already in production. Every token shows up in context, with its real value, in every mode, ready to copy. It is not a separate manual that someone has to keep alive: it is the system documenting itself, so when a decision shifts or disappears, the docs follow on their own.

Traditional docs Hand-written, usually out of date. Someone has to keep them current. Drift is the rule, not the exception. Within a few months, engineers learn to ignore them.
SBT foundations Derived from the registry, always current. Every page is assembled from the tokens in Supabase on each load. The docs are a view of the system, not an artefact to maintain.

08 · Outcome

The system is finally legible.

The system stops being a promise people take on faith and becomes something anyone can read. Design verifies that its decisions made it into the product, engineering works knowing it is implementing the right version and leadership reads the system's health without having to ask for it. The conversation shifts: you no longer argue about what is deployed, you argue about what to do next.

The system is the documentation.
The showcase is the evidence.