A design language that survived 30 development teams

Xing, the German social network for professional life, had a recognisable consistency problem: dozens of product teams shipping interfaces that drifted apart faster than any single designer could correct. The obvious diagnosis was a missing component library. The obvious answer was to build one.

We treated the situation differently. A component library is a technical artefact. It sits in a repository, and developers either reach for it or they don’t. What Xing actually lacked was a shared language: a vocabulary that designers, product managers and engineers could use to mean the same thing when they said “card” or “primary action” or “empty state”. Without that, any library would be code nobody felt ownership of.

Our work split into two strands that ran in parallel.

The first was the visible one: building React components, setting up the tooling (Flow, Jest, PostCSS), establishing semantic versioning and a release cadence. The second was less visible and harder: embedding the vocabulary into how teams talked about UI. That meant joining design reviews, naming things in public, writing documentation that explained why a pattern existed before showing how to use it, and accepting that adoption would happen team by team rather than by decree.

The second strand is what made the first one stick.