A useful design system doesn't live in Figma

3 min readDesign SystemProduct guidelinesProduct DesignMethod

A design system is often reduced to a Figma component library. That’s the visible part, and the easiest to show. Its real test lies elsewhere: a useful design system is measured by the autonomy it grants people who aren’t designers. The right question: “who can make a good decision without me?”

A project shipped at Homair Vacances shows how I approach it.

The real test of a design system: autonomy

On the Homair redesign, every product page opens on a photo that sets the tone of the page. With several hundred campsites in the catalogue and marketing teams feeding the site continuously, validating each photo choice was impossible. Staying that mandatory checkpoint meant becoming the bottleneck of production.

The answer was a selection guideline rather than one more component: explicit criteria for framing, light and composition, handed to the teams so they could pick visuals consistent with the art direction on their own. Design stopped being a gatekeeper and became a frame. (The detail: Formalising a visual guideline for product pages.)

Make the criterion checkable at the moment of publishing

A written criterion, on its own, decays fast: everyone interprets it. What makes it hold is making it checkable where the decision is made.

So alongside the guideline I added interactive cropping templates: they simulate an image’s responsive behaviour, mobile and desktop, and show that the key areas will never be cropped. The criterion becomes checkable by whoever publishes, at the moment they publish, not three screens later in a design review. That’s a design system that holds: fewer rules to remember, more decisions made obvious by the tool.

A design system is first a translation

Before it’s a library, a design system is a translation: going from an intention (an art direction, a vision) to something others can execute without losing it.

On the redesign, the visual direction came from a freelance art director. My role was to translate it into a system the developers and product teams could work with, then keep it consistent from page to page, to the point that other productions reused it later. A design system isn’t the deliverable of a lone designer; it’s the infrastructure that lets many hands produce the same quality. (Context: Being the thread of continuity in a many-handed redesign.)

What a design system should produce

Components are the tip of the iceberg. The real deliverable is elsewhere: reproducible decisions, an autonomous team, and a designer who is no longer a bottleneck. It’s the same reflex as with booking-funnel conversion: asking “what, once set down, will hold without me?” rather than “what do we rebuild?”

So a design system is judged by what it enables when the designer isn’t in the room. If people still have to come to you for every page, it hasn’t done its job yet.

In short

  • A design system ≠ a Figma library. Components are visible; the real deliverable is the autonomy it grants non-designers.
  • Hand over the criterion, not the arbitration. Explicit decision rules beat a design sign-off on every publish.
  • Make the criterion checkable at publish time. A tool that shows the result on the spot holds better than a rule to memorise.
  • Measure it by autonomy. If people still have to come to you for every page, the system hasn’t done its job.

← Back to notes