XING Design System
Led a 12-person cross-platform team to build XING’s Design System (XDS) — hit 65% adoption within 6 months and 80% within 18 months across ~30 product teams, still evolving today.
Role
Design lead
Timeline
2020 — present
Discipline
Design system
Scale
24+ components · ~30 teams
In short
XDS began when XING’s three platform teams — iOS, Android and Web — were each running incompatible design and tech guidelines. I formed a 12-person cross-functional team — designers, engineers, QA and an agile coach — and set both system principles and team principles before writing a single line of code.
The challenge
Three separate platform teams each ran their own design and tech guidelines at wildly different levels of maturity — iOS had large, poorly-reused components, Web followed an atomic approach, Android wasn’t even in code yet. Platform teams gave contradictory direction, slowing every team down and blocking a consistent interface for XING’s B2C users. As one internal quote at the time put it: “We have three design systems and it’s really hard for our teams.”
[Add caption]
Approach
I formed a 12-person team — designers, engineers, QA, and an agile coach — and set both XDS Principles (to guide development) and separate Team Principles (how we work and behave) up front.
Our first attempt — building for all three platforms simultaneously in a single sprint — failed. I reset to foundations-first: tokens, then small components, then medium ones, evolving Brad Frost’s Atomic Design approach to fit XING’s needs.
[Add caption]
To keep alignment across systems and allow for 'build when ready' - every component got a detailed “spec sheet” as its architectural plan, reviewed by engineering before any build started — thorough, if slow. I deliberately scoped the system to ~30 core components to keep it maintainable, tracked openly via a public Component Tracker so any team could see progress and contribute or use components as and when ready.
[Add caption]
[Add caption]
We built showcase apps — iOS, Android, and a website — so product teams could see every component’s real variations before adopting it, and split guidelines onto a separate Frontify platform once bundling code and docs together proved too costly to maintain.
[Add caption]
The real rollout unlock came when the company decided to build a new product from the ground up on our tooling, rather than grafting the system onto the existing one. I ran NPS surveys every four months to track internal sentiment, and reported progress, risk and learnings company-wide every quarter via OKRs.
[Add caption]
Outcome
adoption within 18 months
responsive webpages (from 40%)
components delivered
faster design and build speed
The system reached 65% adoption within 6 months and 80% within 18 months across ~30 product teams. Responsive, mobile-ready webpages grew from 40% to 85% within 6 months of release, and cross-platform features that once meant three separate designs and reconciliation meetings could often be resolved in a single conversation.
What I’d do differently
Keeping code and design guidelines bundled in one bespoke site was too costly to maintain — we split off a separate Frontify solution for guidelines. I’d do that from the start next time.
Letting the design system team change components directly inside other teams’ codebases seemed efficient but was a mistake — it saved time short-term but was hard to navigate other teams’ hacky implementations. Next time I’d have teams make those changes themselves, with our support.