Case study
Enaia
Enaia is a commercial real-estate CRM used by giants like CBRE (the world’s no. 1) and JLL (no. 2). Commercial real estate is a very specific business with plenty of unwritten rules and complex social dynamics – very hard to reflect in software. I worked in a trio with the CEO and the CTO, every day, making that happen.
Most of what follows is about the design system I built for it – one an AI agent builds from, and the instrument that measures whether it works. There is a working prototype further down.
An agentic design system, and the instrument that measures it
Enaia’s design system is built to be consumed by an AI agent as much as by a person. One authored contract per component generates about ten downstream projections – documentation, a component registry, token bindings, a Figma plan – and a malformed contract fails the build rather than shipping as stale prose. Rules carry ids, tiers and detection methods, so a review produces a citable verdict instead of a fresh opinion. I wrote the process up as Building an Agentic Design System and From Pipeline to Governed Artifacts.
The harder question is whether any of it works. In a July 2026 survey of twenty open-source design systems, only seven mention evaluation at all, and the study declines to rank anyone “because there is not enough public measurement.” So I built the measurement.
The experiment
Three screen-building tasks, given to Claude Sonnet 5 five times each, in three environments: with the design system, with its components but no written guidance, and with nothing – same stack, no system. Forty-five runs, $41. Each run happens in an isolated worktree; the diff, the transcript hash and a screenshot are recorded in an append-only, hash-chained journal, so every figure below is re-derivable rather than remembered.
The first result was that my existing checks could not see anything. Every design-system cell scored 100 out of 100, in every arm, on every task. A score bounded at 100 whose floor is also 100 is a receipt, not a measurement. So I stopped asking did it break a rule and started asking how much did the model still have to decide.
49% fewer, ranging 13–77% across the three tasks. A “design decision” is one styling choice that names a value: a colour, a size, a radius, a spacing. Layout is counted separately, because composition is the task rather than the system’s job.
Half the styling vocabulary to say the same thing.
Three quarters of the vocabulary was shared across all five guided runs; barely a third across the unguided ones.
A raw <button> painting its own background, padding and height is the component
being rebuilt from scratch. With the system it never happened.
The third number is the one that changed how I think about design systems. Here are three actual runs from the experiment – the same prompt, asking for a grid of deal cards. The first had the design system. The other two did not.
Neither of the bottom two is bad. They are both competent. They are just not the same product: different status colours, a different avatar treatment, a “Team” label that appears in one and not the other, a different button shape. The cost of having no design system is not ugly output. It is that you get a different answer every time you ask.
The part I got wrong
Between the two design-system environments sits the written guidance – the instruction file an agent loads before it touches anything, and the part I had spent the most words on. Measured against everything above, it did nothing: 1.44 versus 1.44 decisions per element, a loss on two of the three tasks. I published that.
Then I built a grader that reads composition – which component goes inside which – and the effect had been there the whole time. With the guidance, 5 of 5 runs put a settings form inside a Panel, the way every Enaia screen does. Without it, 2 of 5, and one reached for a Card. On a list of lease expirations, 0 of 5 guided runs used a Card to hold content that opens nothing – the exact confusion the Card contract exists to prevent; 3 of 5 unguided runs did.
All ten of those runs scored 100 on every check that existed at the time. The lesson is not that the guidance works. It is that a design system’s effect lives partly in a dimension most tooling – mine included, until I built it – cannot see at all.
What this does not show
The third environment has no design system, rather than a good one. So this supports “a design system beats no design system” – a weaker claim than “mine beats the alternative you would otherwise reach for.” Measuring against a well-known third-party system is the next experiment, and the one most likely to go against me. Five runs, one model, three tasks, one stack; I wrote the tasks and the graders, which makes them checkable rather than neutral; and nobody scored how the screens actually look. Publishing that list is the point – a benchmark whose asymmetries are undisclosed is a marketing instrument.
Prototypes, built in code
I don’t hand off static mockups. This is one of the working prototypes – a prospect-tracking board. Try dragging the cards between columns.
“I wish we’d had you when we started this.”
“Josef works across visual design, UX and front-end, and takes his own work from idea to shipped rather than handing off mockups. That combination is genuinely rare, and ideal for startups.”