DESIGN.md: The Design System for AI

Explore DESIGN.md, a new approach to helping AI understand and apply design systems, and see how it comes to life with Suede.


What is a DESIGN.md file?

A DESIGN.md file is a portable design specification that helps AI understand how a design system should look, feel, and behave.

Most design systems contain much of the information needed to create an interface: typography, colors, spacing, components, and styles. In WordPress, theme.json can define these decisions with considerable precision.

But implementation is not the same as intent.

A color value can tell AI which color to use. It cannot explain why that color exists, how prominently it should appear, or when another color would be appropriate. A spacing scale can provide values without explaining which relationships should feel tight and which should feel expansive.

Design requires judgment.

DESIGN.md attempts to make some of that judgment explicit. It describes the principles, constraints, and visual language behind a design system so AI does not have to infer them entirely from code or screenshots.

There is no established standard for a DESIGN.md file. I am exploring what one might look like and how it might function as AI becomes increasingly capable of designing and building digital experiences.

I recently added one to Suede, the design system behind my WordPress work and creative explorations. The distinction is quite simple: theme.json defines implementation; DESIGN.md defines intent.

View DESIGN.md on GitHub →


Principles

Suede begins with principles rather than tokens.

Before AI knows which font to use or how much space belongs between two elements, it should understand the broader ideas governing those decisions.

The DESIGN.md file establishes these rules:

These principles establish the character before its visual properties.

That matters because AI can follow specifications too literally. Giving it every capability without the underlying philosophy can result in technically correct design that still feels wrong.

The goal is not to use everything Suede makes available, but to understand what makes something feel like Suede.


Composition

A design system can easily become a collection of components.

Suede treats composition differently:

“Design relationships rather than assembling components” may be the most important instruction in the file.

AI is already capable of assembling competent interfaces from familiar patterns. The harder problem is composition: understanding what deserves attention, establishing relationships between elements, and creating hierarchy without filling every available space.

That requires more than a component library.


Design system

Principles and composition establish intent. The design system translates that intent into a more concrete visual vocabulary.

This is where DESIGN.md begins to overlap with traditional design tokens, but with an important difference: values are accompanied by guidance about how they should be used.

Typography

This is more useful to AI than simply declaring a font family and type scale.

Google Sans Flex is the foundation, not a restriction. The system encourages variation within the typeface before introducing another one, while still allowing an accent typeface when the subject or identity benefits from it.

Color

#aa6600 tells a machine what Suede’s accent color is. DESIGN.md tells it that gold should be used deliberately, should not dominate the composition, and can be replaced when another accent better serves the identity.

Layout and spacing

The last rule is important.

“Use generous spacing” is easy for AI to interpret as “use more whitespace.” But whitespace without purpose can make a design feel empty.

The spacing values matter. The relationships they create matter more.

Responsive behavior

Responsive design should preserve the hierarchy of a composition rather than merely rearrange it.

DESIGN.md does not need to prescribe every breakpoint or responsive behavior. Those belong in implementation; instead, it should explain the intent and relationships that must survive as implementation changes.

Accessibility

Shape and depth

These rules prevent another common failure of generated interfaces: reaching reflexively for rounded cards, soft shadows, and familiar visual conventions simply because they are available.

Suede can use those techniques. It just needs a reason.

Interaction

Interaction should reinforce the visual language rather than introduce a new one. The phrase I keep returning to is immediate but quiet: feedback should communicate state without becoming the experience itself.

Iconography

Even a small choice like iconography can change the character and tone.


Imagery

Imagery carries substantial visual weight in Suede, so DESIGN.md gives it more direction than simply defining aspect ratios or image sizes.

This becomes increasingly important when AI is responsible for both generating imagery and designing the interface around it.

“Use a large image” is not enough.

The image, crop, focal point, typography, contrast, and surrounding space are all part of the same composition.


Motion

Motion presents the same problem.

Telling AI to “use subtle animation” leaves substantial room for interpretation. Suede instead defines both the intent and the vocabulary:


Application

The final section of Suede’s DESIGN.md may be the most important:

A useful design system should create coherence without producing sameness.

That becomes especially important with AI. If every instruction is interpreted as an absolute requirement, the system becomes a template. If every decision is optional, it stops being a system.

The goal is controlled freedom.

Suede establishes defaults, constraints, and principles while leaving enough room for a particular subject or identity to influence the result.


Design systems for humans and machines

Design systems have traditionally been expressed through artifacts created for humans and software. Designers use guidelines and libraries; developers use CSS, design tokens, components, and files like theme.json.

AI introduces another participant. It can read those artifacts, but reading an implementation and understanding the thinking behind it are different things.

That is the territory I am exploring with DESIGN.md: a lightweight layer that explains the design intelligence behind the system—what should dominate, what should remain quiet, and which relationships matter.

That is why DESIGN.md now lives at the root of Suede. The theme contains the implementation; DESIGN.md explains the intent.

Now Suede can tell AI not just what it is, but how it wants to be designed.