← Back to portfolio
CASE STUDY · BIBEL TV · 2025 – 2026

A design system that ships to production, not to Figma

Head of Product Design

Design-led infrastructure, with an engineering partner. Hamburg / Berlin

Most design systems are Figma libraries; engineers copy the values into their own platforms by hand. I built a deployed service instead: a Git repo, Style Dictionary, and automated sync, so a token change updates every consuming platform in seconds. Figma is one consumer, not the source.

Token repo DTCG JSON, 4 tiers Style Dictionary one build, per platform CI, on every merge Android — Kotlin values consumed at build time, not copied by hand iOS — Swift constants consumed at build time, not copied by hand Web / connected TV — CSS custom properties consumed at build time, not copied by hand Figma — plugin sync design reads the same values it ships One decision, changed once. Four platforms and Figma read the same build — nothing to keep in sync by hand.
§ 05

What changed

Sync
Four teams hand-updating tokens; platforms drifting apartOne commit in the token repo, and every consuming platform updates without anyone touching code
Reach
A platform-agnostic token API: Android, web and Figma already build on it, and reaching iOS or connected TV is an implementation task, not a system change
Structure
Four-tier token hierarchy: consistency enforced by structure, not by coordination
§ 06

What I took from it

Infrastructure work is design leadership work. This design system is not a Figma file but a running service, so I had to understand APIs, CI pipelines, and token architecture. Not to become an engineer, but because design decisions embedded in infrastructure carry further than design decisions documented in Figma.

The other lesson: choosing a standard format mattered more than building a clever custom one. It means the system can outlast the person who built it.

I would not hand this architecture to another company as a template. It answers one organisation: no design team, engineering outside the company, product managers and product owners setting direction. Somewhere with its own platform team would be right to build something simpler. What travels is the question rather than the answer, which is what this organisation can actually hold.

Read the full case study (8 min)
§ 01

The problem

Change the radius on a card at Bibel TV, and that isn't a five-minute edit. Development sits with an external agency, so it's an estimate in hours and a slot in a sprint. Small changes were not small.

That cost existed because each of the four platforms — iOS, Android, web, connected TV — kept its own copy of every design decision: Kotlin values, Swift constants, CSS variables, Figma styles. Change a color in one place and four teams had to catch it in four others. In practice, three fell behind every time, and the platforms drifted apart. The design system was a Figma library people referenced, with nothing enforcing that the reference stayed true.

There was also a budget reality underneath all of it: no platform-engineering team to own design infrastructure. If the Head of Design didn't build it, nobody would.

§ 02

The architecture

The other options each failed somewhere. A Figma-only library breaks at scale through copy-paste drift. Per-platform token sets give flexibility but make every change an N-times job. A Storybook system handles web and ignores native. Manual sync holds only as long as one person stays perfectly consistent.

What I built is a Git-based token repository that builds to a live API the platforms consume directly.

One Git repo holds the tokens, versioned and reviewed like any other code. A four-tier hierarchy keeps them sane, running from primitives (OKLCH colours, spacing, type) through semantic and component to the page and view tokens a product team works in. Style Dictionary builds platform-specific outputs from that single definition. An automation layer distributes every committed change to the platform endpoints and the Figma plugin.

The top two tiers are the part a purist would question. Component and page-or-view tokens introduce no new values at all; they alias downward to semantic and primitives. That redundancy is deliberate. Each is a place the company can reach in and change a component's spacing or type size, or border radius across the board, without going through the agency that owns the code. Read as a taxonomy it is redundant. Read as a control surface it is the whole point, and it is the first step toward server-driven UI for the streaming section of the app.

The agency backed it, which I did not take for granted. The architecture takes billable change work away from them and they were enthusiastic anyway.

§ 03

How it works in practice

  1. Change a token

    A designer or engineer opens a pull request against the token repo. Standard review, approve, merge.

  2. Style Dictionary builds

    CI runs Style Dictionary, generating platform-specific token files from the single source definition.

  3. Sync runs automatically

    Automation workflows push the built tokens to the platform endpoints and the Figma plugin. No manual step.

  4. Platforms pick it up

    The Android app reads the API on launch and stores tokens locally. The web build pulls the same tokens into Storybook. Figma updates through the plugin. None of it needs a new code deploy.

§ 04

The decisions that mattered

The repo is the source, not Figma

This flips the usual dependency. Normally Figma is the design source and each platform keeps its own copy. Here the repo is the source and Figma is a consumer, so design can change without engineering retouching every platform by hand.

A standard token format

I used the Design Tokens Community Group format rather than inventing one. New tools will read it natively, and a new hire does not have to learn a proprietary system.

Design owned the architecture

Token infrastructure is usually platform-engineering work. Owning it meant I could decide the color space, the spacing scale, and the naming semantics without negotiation, but it also meant learning style dictionaries, API endpoints, and automation workflows.

Because the system is a deployed service and not a document, it opens the door to server-driven UI: change a token on the server, and any platform already wired to it picks up the change on next launch — no rebuild, no ticket. Adjust a color for a campaign or fix a contrast issue without shipping a build.

Want to know how I got the agency that bills for every UI tweak to back a system built to make most of those tweaks free, or why two of the four token tiers were built to add nothing at all? Get in touch.