First-class design systems on a Ryanair budget

I’ve never been on a private jet. I’ve never so much as been within 500 feet of one.

I think this is true for many of us, and maybe more importantly we all sort of know they’re not for us. There might be some dream in our head that we can one day go up in one for some reason, or it might be a personal goal we set for ourselves.

Really, though - it’s fine. We’re not going to fly in a plane just for us. That’s OK! It’s an expensive and pretty needless way of getting around. The relative difference between that and something far more achievable, like business class or even a really nice train ride or an expensive cruise, is pretty slim, so why fixate on it?

We don’t think the same way about design systems though - we push and push and push to get them implemented at work, to make sure that our Figma components are in sync with our frontends, to make sure that the prototypes we’re creating keep pace with frontend changes and that the PRs we’re opening with Claude match the rest of the app.

We kill ourselves to try to keep detailed documentation on how the corner radii should work, organise meetings and workflows and check-ins on how to keep ourselves aligned, fight one another about whether this thing should be an atom or a molecule.

For some light reading I had a look through zeroheight’s survey of design system adoption. The numbers aren’t pretty. For reference - something like 60% of S&P 500 companies put their executives on private jets. Only 7% of designers said their company had full adoption of their design system, and only about 30% “widespread” use through “most” teams.

Since last year satisfaction with leadership buy-in is down. Almost nobody is measuring the benefits they’re getting from them (because how do you?), and while people trust that the system is there, and for them, they’re ultimately not getting the adoption or benefits practitioners expect.

Ironically there is no better time to systematise and think strategically about how your interfaces are created and maintained, because the cost of creating something out of nothing has collapsed. Feature creation, product creation, they’re all becoming cheaper and easier.

The cost is that everything is its own thing - your Claude Design instance is an artist’s impression of your Figma design system, which is an artist’s impression of your frontend. You’re playing a game of telephone between your AI agent, its MCP, your hand-drawn Figma interpretation of the UI, and how the code actually renders in a browser. The best-case scenario is what you wanted PLUS purple monkey dishwasher.

Let’s go back to why design systems needed to exist in the first place. The point of a design system is to align intention with experience at scale: to marry what we want to create in the interface with what users are actually seeing and doing, paired with an understanding that we as individuals don’t and probably shouldn’t have the power to unilaterally change how all the drag interactions work for the whole company.

In the Olden Days this was lots of redlines and detailed notes on which pixels went where, lots of confused reviews of staging servers wondering why the form looks completely different in the browser from how it does in the Figma prototype. Today maybe it’s a PR that subtly ignores every token that the team already uses and creates a special new Mint Green that’s only visible in this one screen and doesn’t work in dark mode.

The point of the system is to make sure that what you’re creating, at whatever stage of design, looks and feels the same when you’re using it as it will when your users are interacting with it. That doesn’t mean you have to have a separate repo where you have an artfully crafted four-thousand-word manifesto for your corner radii. It just means your tooling has to accurately represent what your frontend looks like, on whatever device it’s rendering on.

My suggestion is to think about design systems the way we do about travel.

A full design system repo with a 15-person team managing it, deep investigation and investment in usage and adoption metrics, some creative accounting on how much money it’s saving the company each quarter based on them - that’s your private jet. That’s the thing we get to put in our dream book and manifest for ourselves, but we know it’s probably not going to happen for us immediately and there are plenty of good reasons why not.

The legion of Figma plugins and MCPs that you’ve had to finagle together to try to keep yourself sane: this is more like Ryanair or Spirit. It works, you get from A to B, but it’s not comfortable, the tray table is wobbly, you’re not totally convinced your seatbelt is working properly and the people around you just won’t stop screaming.

Statecraft is something like business class. Canvas-based design like in Figma, but made of the components from your frontend (or your design system repo or component library, if you’ve got one), instead of an artist’s impression. No messing around keeping stuff in sync with your frontend, because it’s already built on your frontend. AI built in, and it’s got a CLI so your PMs can use your existing components and rules to build stuff without you breathing down their necks about the tokens being wrong. Things work without you having to fight anyone.

You could build something yourself, of course. I’ve spoken to a bunch of teams who are trying to build their own renderers and prototyping tools. They very often look like the aircraft that people build at home.

You don’t need a private jet to get from A to B - but you can make life easier on yourself instead of DIYing a lawnchair strapped to some weather balloons.