Kaluza: Managing a design system in the age of AI

The challenge

Kaluza’s agent experience is built by multiple teams across products for Engie, AGL, Shell and OVO. Nebula provided a shared design system, but what was designed in Figma and what agents actually used were often quite different.

Outdated styles, locally built components and accessibility issues had crept into the product. The designs followed Nebula closely, but we didn’t have a clear picture of how far the build had drifted. Reviewing every journey by hand could help us find the problems, but it wasn’t something we could keep doing at scale.

Testing the build, not just the design

I started by creating a framework to assess each page against Nebula’s foundations, components and guidance. Each check included a rating and a written reason, so teams could understand what needed changing rather than just receive a score.

I tested three Payments and Collections journeys: managing payments, managing Direct Debits and setting up payment arrangements. We tested them in the running test environments, rather than in Figma, to assess the experience agents actually had.

All three failed the Nebula adherence and WCAG 2.1 AA checks. A large part of the design system failure came from older styles awaiting the rebrand rollout. The important finding was the gap between design and delivery: checking the Figma files alone would have missed much of it.

Automating the assessment with Claude

The intention was always to automate the checks. I developed a screenshot assessor as a proof of concept and explored a Figma plugin, but the real challenge was testing the build. I used Claude Code to create an automated adherence checking tool.

The early outputs weren’t reliable enough to share more widely. Rather than keep adjusting prompts, I worked towards a single source of truth: machine-readable rules in the design system repository. I implemented more concrete rules per component that follow a should, could, must framework. This gives LLMs clear guidance on how components should be used rather than making assumptions based on prose documentation.

A full test still took over an hour and the setup was cumbersome. Packaging the tool as a Claude skill made it simpler to use. Teams export screenshots into folders for each flow, zip them, upload them to Claude and request an assessment. The output is a PDF report they can review and share.

I tested the workflow on AGL journeys, shared it with colleagues to try and recorded a demo for senior leadership. It turned a process that depended on someone working through a spreadsheet into something other teams could repeat.

Fixing accessibility at the source

Alongside the checker, I worked with engineers to address accessibility issues in the system itself. The aim was to fix a problem once in a shared component, rather than ask each product team to solve it separately.

This started with reworking the navigation colours during the rebrand, keeping the more subtle blue treatment within AA requirements. I also designed an accessible ‘Page not found’ template with a clearer recovery path, which went to development in July.

The component updates included a Badge redesign using 14px medium text to address an AA contrast failure, a dedicated colour to distinguish text links from body copy, and focus containment for modals.

Making the system easier to contribute to

I wrote a setup guide to help designers with no Git experience make their first pull request to the component library. Alongside this, I developed a governance and contribution proposal to clarify who could change Nebula and how. With two key colleagues leaving by autumn, widening the contributor base mattered for keeping the system moving.

The outcome

Over ten months, the work moved beyond identifying inconsistencies to giving teams a repeatable way to find and address them. The adherence checker became a Claude skill tested by colleagues outside the Enterprise Experience team, while accessibility improvements shipped through shared components.

What I learned

The biggest lesson was to test what people actually use. Our designs scored much better than the build, and we would not have understood the gap by reviewing Figma alone.

The AI work also reinforced that the rules matter more than the prompt. Structured guidance in one place made the outputs more reliable; packaging the process as a skill made it practical for others to use. Neither replaces a full accessibility assessment, particularly for behaviour that screenshots cannot show.

Finally, maintaining a design system is as much about the people around it as the components. Clear documentation, handovers and an easier contribution process became essential as the team changed.