Draft — compressed version for comparison, not live
Case Study · Global UX · Doctolib Pro Redesign

From Fragmentation
to Foundation

RoleFramework Architect & Design System Expert
Timeline3 quarters (2024–2026)
ScopeDoctolib Pro · 500K users · France & Germany · 25+ features
My role in this initiative

I was design lead IC on the redesign and co-piloted governance for Global UX: I defined the layout system from first principles and designed the core screens myself, co-designed the scaled design system architecture with engineering, wrote the governance model, and ran the research program across France and Germany, presenting at every Steerco directly to the CPO and VP Product.

The Problem

Doctolib had built a successful product fast. Too fast for consistency.

By 2025, the Pro interface, the daily tool for thousands of doctors, nurses and medical staff, carried the weight of years of siloed feature delivery: low information density, flat hierarchy, high cognitive friction. Every team had solved the same problems differently, and the design system alone couldn't tell teams whether their screens were spatially coherent with the rest of the product. As Doctolib prepared its next generation of clinical and AI-powered features, the cost of that inconsistency, in trust, onboarding friction, and engineering debt, was no longer acceptable.

Top: the initial interfaces. Bottom: the same interfaces using the new framework
Top: the initial interfaces. Bottom: the same interfaces using the new framework.

"Inconsistent UI patterns and behaviors across the platform create confusion for users, increase cognitive load, and dilute brand identity as a professional healthcare software provider."

Internal product framing

The Initiative

Infrastructure, not a visual refresh.

Global UX (GUX) was Doctolib's strategic response: a cross-functional initiative to standardize interface patterns, introduce a modular layout system, and embed AI as a native part of the experience, across countries, roles, and workflows.

Core goals

  • Define a shared layout framework any feature team could implement confidently
  • Ship a scalable B2B design system layer, built on Doctolib's Oxygen design system
  • Integrate AI natively, as a first-class design element, not an add-on
  • Standardize 25+ core features over the coming 2 years

How I approached it

Five decisions, from layout to leadership buy-in.

01
A layout framework, not a screen library

A columnar panel system (including Workflow Panel, Focus Panel...) and several templates replaced per-team improvisation. Dedicated component families like Card Collections, DataGrid, Action Bar, ship with persona-driven responsive rules, from consultation-room tablets to large clinical displays.

The same record screen has to work for a solo GP on a consultation-room tablet and a multi-specialist team on a large clinical display. Density and panel behavior adapt per persona, the underlying grid never forks.

The framework including flexible panels (focus and workflow) with their specific responsive behaviors and expanding modes
The framework including flexible panels (focus and workflow) with their specific responsive behaviors and expanding modes.
02
A governance model that scales decisions, not headcount

Every Steerco topic needs a Review Prep Form 48 hours out. Every track is tiered by framework impact, so teams know instantly what they can ship alone versus what needs alignment. Every decision is logged within 24 hours and binding, reopening requires a written challenge, not a hallway conversation.

03
A two-layer design system architecture

I'd been pushing for this architecture for three years; the redesign became the forcing function that finally got it built. Oxygen served B2B and B2C at once, so every B2B change risked breaking B2C. With the Oxygen Front team, I co-designed a scaled architecture: a shared core with two context-specific layers that can diverge without breaking each other.

The layered architecture shipped to production and is now the default starting point for new B2B and B2C components alike
The layered architecture shipped to production and is now the default starting point for new B2B and B2C components alike

Alongside the dedicated team owning DS Core, two other teams now own DS Pro and DS Patient outright, helping other feature teams contribute directly instead of routing every change through me.

04
AI as a first-class design element, not a bolt-on

AI outputs are probabilistic and reviewable, so they needed their own identity: AI Cards for clinical suggestions, inline text highlighting for rephrasing, standardized input patterns, and a dedicated --ai-* token layer. Automated compliance checks now flag framework deviations before a design reaches human review.

05
A collaboration model that's a guardrail, not a blocker

GUX designers pair with domain teams during sprints, not just review at the end. Oxygen and DS Pro co-own component delivery against GUX's spec. A dedicated research stream keeps French and German findings feeding the framework directly, closed by a Steerco loop with the CPO and VP Product every 3 weeks.

Research Foundation

Design decisions were validated, not assumed.

60+
User tests on GUX prototypes
+150
Respondents to UX surveys
2
Markets co-designed in parallel (FR + DE)

Previous research cycles (2023–2024) validated core layout principles before GUX launched. A dedicated Round 1 de-risked the German market experience, testing layout, navigation, and panel interactions, feeding directly into framework rules: panel proportions, navigation order, and responsive behaviors.

The Numbers

A shared foundation where there was none.

25+
Features standardized
Standardized on one spatial language across the product.
500K
Users covered
Across France & Germany, covered by the framework.
2 layers DS
Split to serve every need
Oxygen grew a shared core plus two purpose-built layers — B2B and B2C — so each can evolve without breaking the other.

What it changes

One framework, inherited instead of reinvented.

France and Germany were co-designed into the framework from the start, not adapted after the fact. Fragmentation wasn't a design failure, it was the default outcome of scaling fast without shared infrastructure. Foundations are cheaper to build once than to repair twenty-five times.