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.”
Feedback was collected prior to work beginning. We showed stakeholders the progress but differences that existed system-wise.
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.
We used the 'Atomic Design' principals from Brad Frost, but adapted to our ownership needs
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.
Specification sheets were agreed for each component with input from an engineer from each system before building started
The Component tracker logged the status of each component on each system to keep both us and our stakeholders aligned
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.
Showcase app for iOS
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.
Separate rollout strategies for both mobile and web were decided with teams and roadmapped
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.