One System, Two Products, Zero Drift

A design system built from zero for a regulated health product and shipped by a team I never sat with.

COMPANY

Verimi

YEAR

2024-2025

ROLE

Senior Product Designer

Design Systems

0→1

iOS & Android

Regulated Health Tech

German accessibility standards

INDUSTRY

Regulated Health Tech

Role

Senior Product Designer, sole designer on the team and accessibility lead. I owned the design layer: components, tokens, layout rules, interaction and accessibility specifications, documentation. A working student supported the design work and testing; engineers implemented the system in code on both platforms.

Team

1 PO, 2 iOS engineers, 2 Android engineers, 1 QA, 1 working student.

Context

A design system for the identification app of one of Germany's largest statutory health insurers, inside Germany's Telematikinfrastruktur — the national digital health infrastructure. My team built the system; a separate team used it to ship the insurer's app.

Scope

iOS and Android, 0→1, then a cross-product governance investigation.

timeline

2024–2025 · 6 months to v1

constraints

regulatory approval · German accessibility standards (close to WCAG, but not identical) · one designer · two platforms · two products on one system.

Figures and client names generalised for confidentiality.

Same structure, two brands. The system survived a change of client without being rebuilt — which was the point.

Act 1: Building the system · 2024

Overview

Problem

The year before, we had delivered an identification app without a design system. Every screen was solved locally: components rebuilt each time, behaviour drifting between platforms, accessibility handled screen by screen — inconsistencies that are expensive to live with and hard to defend in a product that has to pass formal approval.

When the next project started, with a different client and a higher compliance bar, we were set up to repeat the pattern. So I argued for building a design system first. Our Head of Design backed it — not a mandate from above, but a decision made because we had just watched what the alternative costs.

The decision: where consistency should live

The real choice was not whether to be consistent. It was where consistency should live — in the screens, or in the system.

Consistency in the screens drifts and gets re-checked case by case; in the system it’s defined once and inherited everywhere — accessibility included.

Per-screen was the faster start and the slower finish: visible progress on day one, then drift and case-by-case accessibility forever. Building the system first meant delaying visible progress on a small team with a regulated date — the hardest conditions to argue it in. I took the delay. Whatever the system did not define, six engineers would each decide for themselves. That was the cost I was removing.

The sharp edge was the accessibility bar: German accessibility standards, stricter than the defaults most component libraries ship with. Inherited components come with accessibility attributes that look complete on paper but fall short under real screen-reader, keyboard, and 200%-zoom testing.

Per-screen was the faster start and the slower finish: visible progress on day one, then drift and case-by-case accessibility forever. Building the system first meant delaying visible progress on a small team with a regulated date — the hardest conditions to argue it in. I took the delay. Whatever the system did not define, six engineers would each decide for themselves. That was the cost I was removing.

The sharp edge was the accessibility bar: German accessibility standards, above what off-the-shelf component libraries are built for. Inherited components ship with accessibility attributes that look complete and are not sufficient at that level.

Approach

Start from a foundation, then subtract.

I built on Material — a deliberate trade: speed and a tested accessibility baseline in exchange for inheriting decisions I had not made. Then I removed everything the product did not need. A system's value is in what it refuses to offer; every unused variant is a decision someone will later make wrongly.

Reuse the structure, don’t rebuild it.

Colour, typography and branding sat as a layer over a structure that stayed intact — the separation that later made the whole system reusable.

Treat accessibility as component behaviour.

I specified alt text, hints and interaction behaviour inside the component definitions, not as annotations on screens. If it lives in the component, it ships with every use. If it lives in a screen spec, it is optional. The working student and I then tested the implemented components against the specification, closing the loop that had failed the previous year.

Accessibility written into the component definition, so it shipped with every use — not re-checked screen by screen.

What changed

230 screens → 34 page types → 12 components

My team built the design system and handed it over; a separate team used it to build the insurer’s identification app, which went through the client’s formal approval and was live as of my departure. The proof a system works is not that its makers like it — it is that another team ships with it, to German accessibility standards, and the platforms do not drift apart.

The system compressed 230 product screens into 34 reusable page types built from 12 components, so building a new screen became an assembly job, not a design-from-scratch one, and consistency held by construction instead of by review.

My team built the design system and handed it over; a separate team used it to build the insurer’s identification app, which went through the client’s formal approval and was live as of my departure. The proof a system works is not that its makers like it — it is that another team ships with it, to German accessibility standards, and the platforms do not drift apart.

230 screens collapsed into 34 reusable page types built from 12 components. A new screen became an assembly job, not a design-from-scratch one, and consistency held by construction instead of by review.

The system was the deliverable, and a separate team shipped on it.

My team built the design system and handed it over; a separate team used it to build the insurer’s identification app, which went through the client’s formal approval and was live as of my departure. The proof a system works is not that its makers like it — it is that another team ships with it, to German accessibility standards, and the platforms do not drift apart.

My team built the design system and handed it over; a separate team used it to build the insurer’s identification app, which went through the client’s formal approval and was live as of my departure. The proof a system works is not that its makers like it, but that another team ships with it, to German accessibility standards, and the platforms do not drift apart.

My team built the design system and handed it over; a separate team used it to build the insurer’s identification app, which went through the client’s formal approval and was live as of my departure. The proof a system works is not that its makers like it — it is that another team ships with it, to German accessibility standards, and the platforms do not drift apart.

And I reused it myself.

The design system was copied and re-themed as the base for our own product's design system.

Same structure, two brands. Colour, type and branding sit as a layer over a structure that stayed intact — so the system survived a change of client without being rebuilt.

Act 2: The investigation · 2025

Self-initiated. What it produced was clarity and a model on the shelf — by design, not by default.

The problem the success created

Once a second product ran on the system, a question surfaced that no one in the product organisation could answer with confidence: how is our design system built, where does it live, how is it used? Everyone held a fragment. The knowledge that existed lived in engineers' heads and developer-facing technical docs — not in a form the wider product team could act on.

Underneath was a structural gap: the components lived inside a delivery SDK with no versioning of their own, so no one could say which version each product was running, and a fix in one place did not reliably reach the other. The failure mode was not cosmetic — an input field on one platform did not announce its error state to the screen reader, a defect hiding inside a component everyone assumed was correct. Nobody could have found it on purpose, because nobody held the whole map.

What I did

I treated "no one can describe our own system" as the real risk, and made it legible. I ran working sessions with the iOS and Android engineers to establish where components actually lived, how versions were — and were not — tracked, and why the system could not simply be lifted out (dependency conflicts ruled out a one-move extraction). For the first time, the question had a single answer instead of five partial ones.

Then I designed the model to close the gap: the system extracted into an independently versioned library; a working group — design-system owner plus both platform leads — as sole approver, so no component changes without design and accessibility sign-off; every change labelled and visible; a version tagged only when design, code and documentation are all ready; and an end-to-end flow from trigger through review, accessibility testing (screen reader, keyboard, 200% resize), documentation and release.

The model I designed so a change to one component would reach every product using it — reviewed, tested, versioned, documented.

Components coupled inside a delivery SDK with no versioning — a fix in one place did not reach the other. The model I designed makes every change reviewed, accessibility-tested, versioned and documented, so one fix reaches every product.

The decision to pause

The choice was not extract-or-don't. It was build the maintenance capability now, or defer until a project justified the cost. An independently versioned library needs a team to own it, and we did not have one to spare. We chose deliberately: continue ad hoc until the first larger project genuinely required the system, then invest in a dedicated team — with the model already designed, so the answer would be on the shelf rather than improvised under deadline. Not gold-plating infrastructure ahead of demand, while no longer flying blind about what we had.

What changed

Before, "how is our design system built" had no confident answer anywhere in the product organisation. After, it had one: a shared current-state picture, a named accessibility risk that had been invisible, and a governance model ready the moment a project justified the team. The value was a blind spot removed — and a deferral chosen on purpose instead of by neglect.

Reflection

Act 1's decisive move was arguing to build the system before the product, won by pointing at the previous project rather than best practice. Act 2's was quieter: treating "no one can describe our own system" as a real risk, then deferring the fix deliberately rather than building infrastructure ahead of demand.

What I would do differently: capture the system's state as it is built, not once it has fragmented. The clarity I had to reconstruct is cheap to keep and expensive to recover.

What it reinforced: in regulated environments, accessibility and consistency are the same problem — and an organisation cannot own what it cannot describe.