joans.cat

Case study

Helix: winning the design system fight

How do you build contested infrastructure, with no mandate but the one you create?

Context

For years, Life Sciences & Healthcare products ran on the corporate-wide design system, built for everyone and fitting no one in our segment particularly well. Products drifted. Every team solved the same problems in slightly different ways. Consistency was a slide, not a fact.

Then Clarivate segmented in 2024, and the reorganization did what reorganizations do: dissolved old structures, including centralized UX. Most teams experience a restructuring as turbulence. I read it as a window. For the first time, the segment had the standing to own its tooling, and we took it: Helix, LS&H's own design system, built from the ground up.

The problem

Three problems, all at once, and they compound:

  1. Build production-grade infrastructure (tokens, components, pipelines, documentation) while the same team keeps shipping its product commitments.
  2. Drive adoption before the value is proven. Product teams had to invest in an unproven system while a "good enough" incumbent existed.
  3. Overcome real resistance. Teams with custom solutions questioned the investment, reasonably. A design system nobody adopts is a component graveyard.

The decisions

Bet real capacity, visibly. I committed roughly a tenth of the team's capacity to direct Helix development across the year, a deliberate, defended bet made while holding every product delivery commitment. Half measures signal to the org that you don't believe it yourself.

Make it the team's product, not my program. The single most important call: Helix was never imposed. Designers and UX engineers owned components, roadmap and reviews as a shared product. Genuine ownership converted into genuine advocacy. The people building it became the people selling it.

Sequence: foundation, then embedding. UX engineers spent the first half of the year almost entirely on the system's core. In the second half, direct system development dropped to near zero by design, and the same engineers embedded with product teams, implementing Helix in production. Infrastructure first, then hands-on adoption support, not both badly at once.

first half: foundation second half: embedding direct work on the system core embedded with product teams the dip is the strategy: the same engineers pivot into product teams year end: five products live
The sequencing bet, schematically: foundation at full intensity, then the same people move into product teams. On a status chart the drop in "system work" looks like retreat; it is the plan.

Prioritize; don't blanket. Eleven products were selected for adoption on business impact and technical feasibility, not a portfolio-wide decree. Every early product had to become a proof point, so we chose the ones that could.

Governance as a service, not a gate. A light multi-tier cadence: biweekly UX working sessions, technology alignment every two months, marketing alignment twice a year. Thirty-plus structured touchpoints a year, zero approval bureaucracy.

Bake AI patterns in from day one. AI became central to the product strategy the same year. Helix carried AI UX patterns from the start, with UX engineers embedding them directly in two AI-heavy products, which prevented the "wild west" where every team invents its own AI interface.

Treat documentation as a product. About one in twenty Helix hours went into documentation, culminating in a dedicated platform (Supernova) with 44 pages of principles, patterns and training. It launched before the scale-up year, because onboarding friction is what kills second-wave adoption.

The published Helix documentation site at helix.clarivate.io: a Helix Design System home page with a header nav (Home, Foundations, Components, Patterns, Development) and four cards introducing Foundations, Components, Patterns and Development.
The documentation shipped as its own product, live for designers and developers at helix.clarivate.io: principles, component specs with Figma links, and platform guidance. Documentation is what makes second-wave adoption stick.

What Helix looks like

Strategy is only half of it; a design system also has to be good. These plates are rendered from the real Helix components (the same token-driven library the products ship) on invented drug-pipeline data, never anything from a Clarivate system. I built the React implementation myself; the code is public on GitHub.

Helix foundations specimen: the neutral and colour ramps, the reserved blue-to-purple AI gradient, the Clarivate Regular and Source Sans 3 type scale, the 8px spacing grid, elevation and 2px radius, and the density scale. Every value is read from the library's token export.
Foundations, drawn straight from the token export: colour, type, spacing, elevation, density. The blue‑to‑purple gradient is reserved for AI, so a user can always tell what the model wrote.
Helix component specimen: the button emphasis-by-tone matrix including the AI tone, AI avatar and FAB, semantic chips, alerts, selection controls, form fields with an error state, navigation, progress and loading, and the button density scale.
One component library across the Cortellis line. The AI tone is a variant of the ordinary button, not a separate design. That is the paved path that keeps every team's AI surface consistent.
A data-dense Cortellis-style results screen composed from Helix: the two-tier Clarivate header, a filter rail, and a sortable table of synthetic drug records with phase chips, tabs, active filter chips and a paginator.
The kind of legacy, data-dense surface Helix was built to modernize: a competitive-intelligence results screen, consumer-grade patterns over a table that used to be a wall of grey.
The same screen with the Helix AI side panel open: an AI avatar, streamed reasoning steps, an answer whose every claim carries a numbered citation to a row, a sources list, and a footer disclaimer that the content is AI-generated.
The AI pattern, by Helix's own rules: transparent (avatar, streamed steps, disclaimer), assistive (the list stays in view), trustworthy (every claim cites a row, and it refuses to invent a reason the record doesn't give).

What happened

2024 2024: 38% of designer time 38% 2025 2025: 59% of designer time 59%
Share of designer time flowing through Helix-adopting products, drawn to a 0 to 100% scale.

The 2026 plan takes it from 31% of the portfolio toward 85%, with efficiency gains measured in time-to-market, because a design system's second year should start proving its ROI in business terms. And Helix's role widens as AI compresses development: its components are the paved path that non-designers already build on, so an AI-generated prototype inherits the design language instead of fragmenting it, and a quick mock-up can't skip validation by being pasted straight into the backlog as the thing to build.

What I'd tell another design leader

  1. Reorganizations are infrastructure windows. The mandate you'll never be handed in steady state is briefly available when structures dissolve. Be ready with the plan before the window opens.
  2. Adoption is earned through ownership, not decreed through standards. The team that builds the system as theirs becomes your sales force.
  3. Sequence the investment. Foundation first at full intensity, then pivot the same people to embedding. The dip in "system work" on the chart is the strategy working.
  4. Pick proof points, not coverage. Five products live and loud beat twenty products half-migrated.

Related: the playbook · the AI patterns this system carries: The AI validation gate · born from this fight: Design systems are political projects · Reorganizations are infrastructure windows