How to keep AI aligned to your design system

Written for design system managers, with examples for brand teams too.

Your design guidelines capture years of decisions about how your organization's products should look, work, and sound. Some are immediately visible, such as typography and color. Others show up as people use the product: whether they can undo a deletion, what a button says while they wait, or how an error message helps them recover.

When someone on your team builds a screen with AI, those decisions still matter. A screen can use the right colors and miss the behavior you've carefully worked out. A delete action might skip a necessary confirmation. An error message might explain the problem without telling anyone how to fix it.

How do you make that guidance available to the tools your team is using, and keep it current as your system changes? This guide looks at the problem from a design system manager's perspective, with examples for brand teams too.

Keep accessibility and usability decisions in the build

A finished screen doesn't show all the work behind it. Your team may have tested its contrast in dark mode, checked the keyboard navigation, and revised the wording after watching people struggle with a form.

Those choices belong in the next version of the product too, whether a person or an AI tool builds it. Sharing the visual styles alone won't explain how a focus state should work, how large a touch target needs to be, or what an error message should include.

The reasoning matters as well. If your date picker behaves a particular way because of usability testing, that context helps someone understand why they shouldn't casually change it.

An AI tool needs access to those guidelines to take them into account. Without them, it may produce a reasonable interface that doesn't follow the decisions your team has already made.

Make your documentation available to AI tools

Your documentation may already cover all of this: component behavior, styles, content guidelines, and examples of what to do and what to avoid. The question is whether the tool building a screen has that guidance available when it needs it.

AI tools can read documentation when you give them access. But having a docs site doesn't mean every tool your team uses will find the relevant page or read its latest version.

For a designer, looking up a component is part of the work. With an AI tool, that step needs to be part of the workflow too. Otherwise, your guidelines can be well documented and still be absent from the request the tool is working on.

Markdown files and Notion pages get out of sync

One approach is to copy your guidelines somewhere the tool can read them: a Markdown file alongside the code, a Notion page, or a skill file containing instructions for a particular tool.

That can work well for a small project. The maintenance problem starts when the original guidelines change. If you update the spacing guidance on your docs site, someone also needs to update every copy used by an AI tool.

Skill files need the same care. A file written for one project can remain in use long after the person who created it has moved on. Without a clear owner and a review process, it's easy to lose track of which guidance is current.

The files themselves aren't the problem. It's the extra work of keeping several copies of the same guidance up to date.

It gets worse with a team

That work grows as more people and tools get involved.

A designer might prototype in one tool while an engineer builds in another. If each uses a separate copy of your guidelines, a single design-system change can mean updates across several projects.

Say you changed your focus-state guidance last week. How would you check that every tool has the new version? With separate files, someone has to find and review each copy.

If a tool uses old guidance, the difference may not show up until design review. Your team ends up correcting work using decisions it had already documented.

One place your tools read from

We built UI Rules to give connected AI tools a shared place to read your design system. Instead of maintaining a separate set of instructions for each tool, you manage the styles and guidelines together.

Your brand in UI Rules holds two things.

Your styles are the real values, your design tokens: color, typography, radius, shadow, spacing, sizing, and layout, with light and dark values where they apply.

Your rules explain how to use those styles, along with guidance for behavior and content. A primary color value tells a tool which blue to use. A rule can tell it to reserve that color for the main action on a screen.

Give a tool your brand styles and it'll look like your brand. Rules help apps work and sound like your brand.

Write rules that explain what matters

Each rule has a type: Do, Don't, Caution, or Info. It also has an importance level: Required, Recommended, or Optional. Use these to distinguish a requirement, such as minimum contrast, from a preference. They help a tool interpret your guidance, but they don't replace reviewing its work.

Write a rule as you'd explain it to a colleague. If you want help refining it, Enhance, available on Pro, suggests clearer wording and explains the changes. You review the suggestion before applying it.

Keep related rules in named groups alongside the components, styles, or content they describe. You can lock agreed rules to protect them from edits.

Guidelines for your components

UI Rules also includes components based on shadcn, an open-source collection of interface components such as buttons, cards, and dialogs. Each component can carry guidelines for how your team uses it, including spacing, behavior, and states. You can also turn off components that aren't part of your system.

Give your tools access to current guidelines

You can connect Claude Code, Cursor, v0, Lovable, Codex, and Figma Make to your brand. Connections are read-only by default, so a tool can read your guidelines without being allowed to change them.

When you update a rule, the new version is available the next time a connected tool reads your brand. That gives your team one place to check the current guidance instead of searching through separate instruction files.

Some apps need different styles. Your marketing site might use larger headings than your product, for example. In UI Rules, each connected app inherits your brand's styles and rules. You can then change values for that app without changing the shared brand or the other apps using it.

For brand managers

Brand managers can use the same approach for language and assets.

Voice and tone. Give tools guidance for the words they write, including button labels, error messages, and onboarding. Be specific about what your voice means in practice. For example: "In error messages, explain what happened and what the person can do next. Avoid jokes." Group these rules by the kind of content they apply to.

Logo and brand assets. Upload your logo and add guidance for clear space, placement, and suitable backgrounds. This gives connected tools access to the asset you want them to use and instructions for presenting it correctly.

You'll still need to review the output. The benefit is that your guidelines are available while the tool is creating the work, rather than only being used to explain corrections afterward.

Where to start

Start with one app and the guidelines you find yourself repeating most often:

1. Get your real values in. Import your existing theme rather than typing every value in by hand.
2. Write the guidelines you repeat most often in design reviews. Mark genuine requirements as Required, and use Recommended or Optional for preferences. The rules guide explains how to write and organize them.
3. Connect one tool and one project. See what comes back, then write rules for whatever it still gets wrong.
4. Add your voice guidelines and logo usage rules so the tool has guidance for both the words and the visuals.

Build a screen, review it against your guidelines, and note what still needs attention. Use that review to clarify your rules. You don't need to document every possible situation before you begin; start with the decisions your team is already making repeatedly.