Connecting a design system to the people who would build with it

Fielmann, Europe’s largest eyewear retailer, came to us with a design system that was already mature on one side and almost unusable on the other. The design team had invested years in building a coherent visual language: every pattern, token and component existed in their tools. But when engineering tried to use any of it, the system fell apart at the handover. Nothing was distributed as code, nothing was versioned, and there was no shared model of how a new pattern got from a designer’s screen into a production interface.

The temptation was to treat this as a tooling problem: pick a component framework, set up a registry, ship a library, done. We resisted that for a specific reason. The gap between Fielmann’s designers and developers wasn’t really technical, it was organisational. Each side had its own vocabulary, its own definition of what “a component” was, and its own implicit standards for what counted as complete. A library shipped without addressing those would have been adopted by no one.

We led the work as the Design Systems team, and “team” was a deliberate choice, because the structure needed to outlive any one engagement. The technical work was real (React components, Styleguidist documentation, a CircleCI pipeline, semantic versioning over NPM, granularity decisions about what should be a component versus a token versus a pattern), but the work that took the most time was less tangible: aligning on what “done” meant, on who could request new components, on how breaking changes got communicated, on the rituals that kept designers and engineers reading each other’s work.

The single move that shifted adoption the most was reviving a dormant frontend community of practice. It existed on paper, but nobody had been running it. We picked it back up as a standing forum: a place where component decisions could be argued in the open, patterns could travel between teams before they hit the library, and small daily frictions got named early instead of accumulating. Awareness of what the system offered stopped being something the Design Systems team had to push from outside. It became something the frontend engineers carried between teams themselves, in a room they owned.