I’ve been speaking to many design and technology leaders over the past few months across consulting, automotive, financial services and telcos. They already have the answer to “How can we use AI to move from idea to delivery, faster?” The question they’re now asking is “How can we do it with better quality outcomes, consistently?”
TLDR; Skip to 8 tips to make your Design System AI-ready
Correcting AI output becomes expensive.
The ability to do things faster and in bigger volumes has increased dramatically. However, it is sometimes just as costly, if not more costly, if the design and build isn’t right after the first prompt.
The cost we’re all seeing is hours of work by your teams correcting:
- Incorrect components being used for certain tasks
- Incorrect styling, spacing, sizing being used for particular platforms or user flows
- Inconsistent language, or tone-of-voice for your organisation’s style
- Accessibility standards not being met
- Rewriting of content, labelling, error messaging, etc.
Your team can also be hit with a massive bill for AI token usage because they’re all armed to the teeth with Cursor, Codex, Claude and Copilot (why do they all start with C?). For example Uber recently capped monthly employee spending at US$1500 per coding tool after they used their entire 2026 AI coding budget in the first four months of the year.
You can turn it around. Get back to basics with your Design System.
The introduction of a new technology stack such as AI isn’t going to magically fix things if your organisation struggled to deliver consistent, quality experiences before the introduction of AI. So this isn’t an AI challenge, it’s a system quality challenge.
An LLM is often the new team member, never onboarded, that we’re constantly expecting to ‘get it right the first time’. We then become incredibly frustrated when it gives us slop. LLMs need to know what ‘it’ and ‘right’ are.
Your Design System is the ‘it’ and the context and assets it contains are the ‘right’.
“It’s the centrepiece for AI to deliver quality experiences, consistently at-scale.”
8 tips to make your Design System AI-ready
When helping organisations, here’s a checklist of things I look for in a design system before attempting to design or build using AI.
-
Figma code connect
I’ve tried to be product agnostic in this article, but let’s face it, we’re all most likely using Figma as our design tool of choice. Figma’s code connect does what it says on the box, it connects your Figma components to its coded partner, so that when an engineer switches Figma to dev mode, they get the actual component and its real properties, rather than an approximation. The benefit here is that because you are now introducing AI tools into the mix, Figma’s code connect allows your AI agents to read this same data via Figma MCP. Super important step.
-
Component contracts
These are the rules or hard facts, usually stored in a separate, per-component JSON file co-located with your components. It should also set out the naming convention for your components and ensure there is parity between the terminology used in code and Figma. A component contract contains things like the component’s purpose, composition, props, accessibility, etc. E.g. ‘the modal must have a title, a close button and a background overlay. It can contain up to 1000 characters and there are options for all window class sizes. Always use the term modal, not pop-up.’
-
Component context
The situational rules, often documented as guidance or do’s and don’ts. Traditionally these already exist in platforms such as Zeroheight, Supernova and Knapsack. If not happening already, make sure there’s a markdown equivalent of these so LLMs can easily parse them. E.g. ‘only use this modal to interrupt a user’s flow if the user is about to lose unsaved data. Do not open this modal just to show profile settings or app settings’.
-
Design Tokens
Your Design Tokens must be well structured, with semantic labelling so LLMs can understand the purpose of each token. Again, these will have contracts and situational rules. E.g. Tier 1 primitives hold raw values – red200 (maps to #C20000); Tier 2 semantics give the primitive a role – colour.brand.primary (maps to red200); Tier 3 component tokens apply a role to a specific token – button.background.primary (maps to colour.brand.primary).
Tokens also need to be published in machine readable formats for the tools you use. E.g. Figma uses Variables, code uses JSON and CSS variables. You can manually ensure parity, but there are loads of tools and Figma plugins that can help you achieve this.
-
Writing guidelines
Large Language Models (LLMs) do what they say on the box! So make sure you give them your Writing guidelines. With this they understand your brand and tone of voice, lists of phrases and words your organisation never uses, what reading level is acceptable, how to consistently write error messages, etc. It should also contain reusable content fragments so the same thing isn’t rewritten over and over again, just slightly different (e.g. Terms and conditions, constant labelling).
-
Accessibility standards
Provide your organisations accessibility standards with examples, in design, content and code. Your organisation will apply accessibility slightly differently to other organisations. What is WCAG 2.2 AA for your organisation’s experience will be interpreted differently for other products and brands. Sometimes you’ll have to go live with WCAG 2.2 A with a plan to remediate to AA within x months. Your AI tools can help with that, as long as they understand how you apply your organisation’s standards.
-
Centralised rules repository
This is a place to store all the rules your teams stick by when designing or building. Get them locked down (this is the part where you all talk to each other and decide on these rules) and point whichever tool you are using at this repository, e.g. if you're using Cursor these are stored in
.cursor/rules/or for Claude they’re inCLAUDE.md.An example of a rule set might be for Forms. You’d include rules in this for Validation (e.g. on blur), Labels (e.g. optional fields), Buttons (e.g. primary, its position etc).
Don’t create a whole separate site or system for this. The idea is to make it simple for your systems to access the rules.
Write the decisions by hand, but then let your system generate the facts by interrogating the code and designs (e.g. writing colour hex codes by hand is prone to human error and is long and boring work - and if you keep doing it by hand it will become out of date very quickly and you’ll have drift).
-
Governance and adoption
Your design system team should already have good governance in place. A few of the rules you’ve created for your AI tools now need to answer ‘At which point in the design and delivery cycle do we need a human in the loop?’, ‘How do we create a defect and who needs to check and approve it?’, ‘What is the contribution process when a new component is identified?’.
Now you’re using AI you need to update your team processes to call out the wins, name them, formalise them and adopt them into your workflows for everyone to reuse (e.g. you created an Accessibility audit skill for AI and it did a great job - that’s a win, named, and now formalised so everyone can reuse). Regular reviews as a team about what is working well will help guide what needs to go into workflows and processes.
Any new, changed or existing integrations need to be well documented so humans and machines alike understand what’s connected, who can reach what and how, and who maintains them.
Once all the above points are in place onboarding new users into your design system is now much easier. You can show a new user how it’s all set up, then they can use it to walk through your design system at all the levels of granularity.
