Case study Doctor.One

Building a design system to scale.

A solo rebuild from scratch - tokenized architecture, documented components and a white-label workflow. The whole thing scales from one source of truth, and spinning up a new brand went from weeks to an hour.

Role
Sole designer
Scope
Architecture → handoff
Platform
Two apps + white-label
70%
fewer bugs
weekafternoon
white-label deployment
Doctor.One main app
The same screen as a white-label brand

The previous design system was incomplete and inconsistent. With two apps live and white-label clients on the horizon, I needed to rebuild from scratch - and do it right.

Outdated branding, no unified documentation
Implementation drift - a fragmented product
White-label projects coming - it had to scale
My role

This was a solo project. I designed the entire system from scratch: the architecture, every component, all the documentation, the white-label workflow and the developer onboarding.

No other designer was involved.

Solo, end to end
Architecture
Components
Documentation
White-label
Dev onboarding
The decision · Tokenization

An arithmetic solution for artistic consistency.

With two apps and multiple white-label clients ahead, tokens were the only foundation that could scale. Doctor.One now has its own full set of values: colors, spacing, radiuses. Creating a white-label version means swapping the entire set. One global, systematic change guarantees consistency.

System architecture

Built in layers, so a change cascades everywhere.

Tokens feed components. Each component is reused across screens or becomes the foundation for more complex ones.
A change at any level flows automatically through the entire system. One source of truth for everything.

Layer 01Primitives & tokens
Layer 02Components
Layer 03Screens · two apps
One component definition, two brands — pure token math
63
primitive variables
40
semantic tokens
22
type styles
50+
components
The token set

Every value, named and resolved by mode.

Semantic tokens point at primitives and each one resolves differently for Regular, Dark Mode and White Label. The same surface-brand is Blue Light in one context and a client's brand color in another. Nothing is hand-picked twice.

The token set — primitives, collections, semantic tokens resolved for Regular, Dark Mode and White Label, plus spacing and radius
Documentation as a deliverable

No room for guesswork. No room for interpretation.

Poor documentation was the main reason for inconsistent implementation, so I made it an integral part of every component, not a process afterthought. Each card carries the name, a usage description, labeled anatomy, padding & radius specs and every variant. Then I onboarded developers to the logic behind it all.

Component documentation card — name, usage description and labeled anatomy Padding and radius specs alongside every documented variant
White-label in practice

Someone else's brand, our logic underneath.

Every white-label client gets a separate app, its own identity and needs, but the same architecture, the same rules, the same quality. The client provides brand documentation; I introduce a new token set. One switch, and the entire app adopts the new branding.

One design system feeding the main app and every white-label client
Doctor.One main app
Main app
=
White-label brand
White-label

Same screen. Same component tree. Same spacing and radius. Only the token set changed - and the whole product reads as a different brand.

The challenge I solved: deliver the feel of another brand without losing the consistency and logic of our own.

The business argument

Clear rules are also a business argument.

Defined system rules set the scope of what white-label enables. The client knows what they get; we know what we deliver. Misunderstandings are eliminated before they happen.

Before tokenization
White-label didn't exist

Every new brand meant manual rework across the product — slow, error-prone, and impossible to promise to a client.

After tokenization
Creating it takes an hour

The client provides colors and illustrations, I introduce a new token set, and one switch adopts the new branding across the app.

The outcome

A good design system is invisible.

The user never sees tokens or components, they see a consistent product that works the way it should. Behind it: two apps, multiple white-label clients, and 15–20 developers working from one source of truth.

The system paid for itself fast. Design turnaround on a new white-label brand dropped to under an hour, deployment to under four. Reported visual and implementation bugs fell by 70%. What used to take weeks and breed inconsistency now ships in an afternoon - done right the first time.

What they say
His contribution to our Design System and the development of our white-label capabilities has been a game-changer. These initiatives didn't just
improve our design consistency; they strengthened our B2B business and enhanced the company's revenue streams.
Maciej Malenda · CEO, Doctor.One
Read the full letter
Next

UI leadership
for a global brand.