From Fragmentation
to Foundation
I was brought in as the framework architect for Global UX, co-owning the end-to-end design direction for the initiative. This meant defining the layout system from first principles, co-designing the scaled DS architecture with engineering, writing the governance model, running the research program across France and Germany, and presenting at every Steerco cycle directly to CPO and VP Product. I also participate in building the team rituals, the review structures, and the tiered impact framework that made large-scale alignment possible without slowing feature teams down.
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 visual hierarchy, high cognitive friction. Every team had solved the same problems differently. While the design system helped share a common component vocabulary, there was no systematic way for feature teams to know whether their designs were spatially coherent with the rest of the product. Multiple external pressures, including the Covid crisis, reinforced a pattern of shipping fast and deferring improvements indefinitely.
The platform was visibly fragmented, and professionals noticed. As Doctolib began preparing its next generation of clinical and AI-powered features, the cost of that inconsistency (in user trust, onboarding friction and engineering debt) was no longer acceptable.
"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 framingThe Initiative
Infrastructure, not a visual refresh.
Global UX (GUX), named the Pro Redesign later down the road, was Doctolib's strategic response: a cross-functional initiative to standardize interface patterns, introduce a modular layout system, and embed AI assistance as a native part of the experience, across countries, roles, and workflows.
It started as an evolution of a wide research program initiated during the end of 2024, expanding in scope to cover the full Doctolib Pro platform.
Core goals
- Define a shared layout framework that any feature team could implement confidently
- Ship a scalable B2B design system layer (distinct from the B2C product) built on Doctolib's Oxygen design system
- Integrate AI natively into the UX framework, not as an add-on, but as a first-class design element
- Standardize 25+ core features over the coming 2 years
What We Built
A layout framework, not a screen library.
The GUX framework defines how Doctolib Pro is structured: the spatial logic that contains features, not the features themselves. Rather than prescribing individual screens, I built the structural language that all feature teams would inherit going forward.
Layout logic & panel system
The workspace is organised around a columnar model with named, purpose-driven zones. A main content column handles primary tasks; a Workflow Panel enables contextual secondary interactions without navigating away; a Focus Panel surfaces related or highlighted content inline. Each panel has defined widths, trigger conditions, and dismissal behaviors, so any team implementing a side panel inherits those decisions rather than making them from scratch.
Page templates
Instead of spec-ing individual screens, I defined reusable structural templates: an Overview template for multi-entity list views, a Record template for deep clinical or administrative detail, and a Settings template for configuration flows. Templates encode decisions that were previously made inconsistently by each feature team in isolation.
Dedicated component families
The framework ships with component families designed for B2B healthcare density: Card Collections as the primary content display unit, a DataGrid for high-density tabular data, an Action Bar for transversal controls, and a Navigation system rebuilt for professional information architecture. Each family has defined variants and layout rules, not just visual styles.
Responsive behaviors
Doctolib Pro users don't sit at a single screen size. Some are on tablets in consultation rooms; others are on clinical workstations running large displays well above 1920px; most land somewhere in between. The framework defines persona-driven responsive rules: which panels collapse first, which columns have minimum widths, and how the workspace degrades gracefully across the full range of real-world setups. For the first time, this follows a single documented contract rather than per-team improvisation.
Governance
Making decisions at scale, across teams and countries.
One of the hardest problems wasn't design. It was how to make decisions at scale, across teams and countries, with a CPO and VP Product who needed to validate every major direction. We designed an operating model built on three principles.
Any topic going to Steering Commitee (Steerco) required a completed Review Prep Form submitted 48 hours in advance. The form is the formal contract between the presenting team and the steerco. Without it, the slot doesn't exist. This eliminated half-baked reviews and kept sessions focused on real decisions.
Every track was classified by its impact on the framework, giving every team a clear contract: what they could build independently, what needed alignment, and what required a formal decision.
Every steerco and review decision was logged within 24 hours. Logged decisions are binding. Re-opening requires a written challenge, not a verbal raise in the next session. This prevented the most common failure mode of collaborative design at scale: decisions being quietly undone.
Design System as Infrastructure
From maturity level 3 to level 4: a two-layer architecture.
Scaling GUX required solving a deeper architectural problem: Doctolib's Oxygen design system was built for both B2B and B2C contexts simultaneously. That created a conflict, every B2B-specific change risked breaking the B2C experience, and vice versa. Additionaly, the B2B and B2X experiences started diverging UI-wise, as the audience and needs and code language are totally different.
We co-designed with the Oxygen Front team a Scaled Design System architecture: a two-layer model where a shared core provides foundations (tokens, base components, accessibility), while two context-specific layers handle domain-specific patterns and token overrides.
GUX components are delivered by a dedicated engineering team directly into Storybook. Feature teams import exclusively from their context layer. A new DS Committee governance was established with clear ownership across the Oxygen front team, DS Pro team, DS Patient, DS Champions embedded in domain teams, and DS Agents providing AI-powered support in Slack. For the first time, contribution paths, ownership, and escalation routes are defined and enforced rather than left to individual judgment.
AI as a First-Class Design Element
Designed into the framework from the start, not layered on top.
The Doctolib Assistant was treated as a full GUX track from day one. Not a feature owned by a single team, but a layer of the framework itself. The core design challenge: AI outputs are fundamentally different from regular UI. They're probabilistic, reviewable, and sometimes wrong. They need their own visual identity, their own interaction patterns, and their own trust signals. Not borrowed ones from a B2C chatbot.
AI language assets
- AI Cards and Binary Cards — Structured surfaces for model-generated clinical suggestions, with consistent confidence indicators, accept/reject flows, and citation patterns. Binary Cards handle quick validation decisions without interrupting the clinical workflow.
- AI text highlighting — An inline annotation system for parsing and surfacing medical rephrasing suggestions directly in the text, without breaking reading flow or requiring a modal interruption.
- AI input patterns — Standardized entry points across views: where the user triggers AI, where it responds, and how the handoff between suggestion and confirmation is handled. The answer is now never "wherever the feature team decided to put it."
- AI design tokens — A dedicated
--ai-*token layer for backgrounds, borders, and state colors. AI surfaces are visually distinct from regular UI without requiring custom CSS overrides on each implementation.
AI in the review pipeline
The GUX review process itself is partially AI-assisted. I integrated automated compliance checks that flag deviations from framework rules before designs reach human review, covering incorrect panel widths, non-standard AI surfaces, and missing token usage. This shortens feedback loops and surfaces structural issues before they become engineering rework.
The goal: any team shipping an AI feature inherits a design home with established patterns, not a blank canvas wondering where AI belongs in the interface.
Collaboration Model
Redefining how design, product, and engineering worked together.
Global UX touched every part of the product organisation. The tension we navigated: GUX needed to be a guardrail without becoming a blocker or a roadmap breaker. The Review Prep Form and tiered impact system were directly designed to address this, making the contract explicit and the escalation path clear.
Research Foundation
Design decisions were validated, not assumed.
NCE research cycles (2023–2024) validated core layout principles before GUX launched. GUX User Research Round 1 specifically de-risked the German market experience, testing layout, tab navigation, and panel interactions with German HCPs and medical assistants. Findings fed directly into framework rules: panel proportions, navigation order (Health → History → Financial → Admin), and persona-driven responsive behaviors.
Impact
A shared foundation where there was none.
France and Germany were co-designed into the framework from the start, not adapted after the fact. The research program ran both markets in parallel, and migration milestones for each country are tracked and reviewed at every quarterly planning cycle.