Dev

Google Labs Releases "DESIGN.md" Specification for AI Agent Design

Google Labs has unveiled DESIGN.md, a specification to streamline visual identity for AI agents by structuring design tokens and intentions.

6 min read Reviewed & edited by the SINGULISM Editorial Team

Google Labs Releases "DESIGN.md" Specification for AI Agent Design
Photo by Markus Winkler on Unsplash

Google Labs has introduced “DESIGN.md,” a specification format for documenting design systems tailored for coding agents. Available on the GitHub repository “google-labs-code/design.md,” this specification integrates machine-readable design tokens and human-readable design intentions (prose) into a single Markdown file. This innovation enables AI agents to generate code while maintaining a consistent visual identity.

The purpose of DESIGN.md is to provide AI agents with a “sustainable and structured understanding” of design systems. Traditionally, design systems existed as documents or Figma files for human designers, making it challenging for AI agents to accurately interpret the rules. This new specification aims to bridge that gap.

Dual-Layer File Structure

DESIGN.md is composed of two layers. The first layer is a YAML front matter, a section at the beginning of the file marked off with ”---,” where machine-readable design tokens are defined. The second layer is the Markdown body, where design intentions and application rules intended for human readers are documented in ”##” sections. The tokens provide normative values, while the prose supplies contextual explanations.

A provided sample showcases the following token structure:


name: Heritage colors: primary: “#1A1C1E” secondary: “#6C7278” tertiary: “#B8422E” neutral: “#F7F5F2” typography: h1: fontFamily: Public Sans fontSize: 3rem body-md: fontFamily: Public Sans fontSize: 1rem label-caps: fontFamily: Space Grotesk fontSize: 0.75rem rounded: sm: 4px md: 8px spacing: sm: 8px md: 16px

In this example, the color palette, typography, border radius sizes, and spacing are defined. On the prose side, a design concept called “Architectural Minimalism meets Journalistic Gravitas” is explained, with details on how each token is intended to be used. For instance, “primary” (#1A1C1E) is described as “a deep ink for headlines and body text,” while “neutral” (#F7F5F2) is characterized as “a soft, warm limestone hue, softer than pure white.”

By parsing this file, an AI agent can generate user interfaces that apply Public Sans at 3rem for headings, #F7F5F2 for backgrounds, and #B8422E for call-to-action buttons. Importantly, the agent not only uses the color codes but also understands the underlying design intentions.

Validation and Version Management via CLI Tools

DESIGN.md comes with a lint command to validate adherence to the specification and a diff command to detect differences between two versions. Both tools are available via the npm package “@google/design.md.”

The lint command analyzes the DESIGN.md file for issues like missing token references, WCAG contrast ratio compliance, and structural problems, outputting results in JSON format. A sample output shows a contrast ratio of 15.42:1 between button text color and background color, which passes WCAG AA standards, but was flagged as a warning. The summary reported 0 errors, 1 warning, and 1 informational message.

The diff command compares two versions of a DESIGN.md file, identifying regressions at both the token and prose levels. In one example, the output noted the addition of an “accent” color token and a modification to the “tertiary” token, while confirming no regressions were detected.

These tools enable seamless integration of design system changes into CI/CD pipelines. For example, DESIGN.md linting can be automated during pull requests to ensure compliance with accessibility standards.

Detailed Token Schema

The specification defines the following key token types:

  • colors: Accepts any valid CSS color value (hex, RGB, HSL, etc.).
  • typography: An object that includes fontFamily, fontSize, fontWeight, lineHeight, letterSpacing, and more.
  • rounded: Maps level names (e.g., sm, md, lg) to dimension values.
  • spacing: Similarly maps level names to dimension values, which are interpreted as pixels when numerical.
  • components: Allows token references to be defined for specific components, such as assigning “primary” color to a button background.

Token types include Color (CSS color values), Dimension (numeric or unit-specified strings), Typography objects, etc. Within the “components” section, tokens can be referenced using “$ref: colors.primary.”

A New Way to Share Design Systems

The greatest advantage of DESIGN.md is that it allows both humans and agents to access the same file for design information. Unlike Figma token exports or Storybook parameter files, the YAML front matter is optimized for machine processing, while the Markdown body is easy for humans to read and edit. This allows designers to document project intentions in natural language.

Google Labs has released this project in “alpha” stage, and as the specification stabilizes, its ecosystem is expected to grow. Tools such as Figma plugins for automatic DESIGN.md generation or converters for major CSS frameworks could accelerate its adoption.

Already gaining attention on GitHub Trending, this project offers a new option for managing design systems. When combined with foundational models like Google Research’s TimesFM 2.5 for time-series forecasting, DESIGN.md could facilitate a future where agents autonomously learn and apply design rules.

Additionally, in the context of Google’s broader UI/UX integration strategies, as demonstrated in projects like Google Wallet’s customized ticket features for Ticketmaster and Google Wallet’s real-world usability tests, DESIGN.md could contribute significantly to internal and external design standardization efforts.

Editorial Opinion

In the short term, this specification serves as a practical tool to enhance design consistency in AI-driven code generation. Currently, agents like Cursor and GitHub Copilot rely on inferring design tokens from CSS variables or component libraries within a project. With widespread adoption of DESIGN.md, agents could generate user interfaces based on explicit rules, reducing rework.

In the long term, this initiative has the potential to standardize design tokens and foster interoperability among agents. By publicly releasing this specification, Google Labs opens the door for other companies and open-source projects to adopt similar approaches or develop ecosystems that integrate DESIGN.md with tools like Figma and Storybook. However, as this is still an alpha version, real-world feedback is needed to address challenges such as namespace collisions and performance issues in large-scale projects.

From an editorial perspective, the success of this specification will hinge on how widely it is adopted as a bridge between design and development in the era of AI-driven agents.

References

Frequently Asked Questions

How does DESIGN.md differ from existing design systems?
Existing design token formats (such as Style Dictionary's JSON) are machine-readable, but design intention explanations are often kept in separate documents. DESIGN.md distinguishes itself by integrating tokens and prose into a single file and offering specialized lint/diff tools. It is particularly optimized for use by AI agents.
What specific checks can the lint command perform?
The lint command checks for token reference consistency (e.g., whether undefined tokens are referenced), compliance with WCAG color contrast ratios, token type validity, and structural issues (e.g., missing required fields). The output is in JSON format, making it suitable for integration into CI pipelines for automated checks.
How can I adopt this specification for my project?
Start by creating a DESIGN.md file in your project root and define your design tokens in the YAML front matter. Then validate it using `npx @google/design.md lint DESIGN.md`. Detailed specifications are available in the official repository's docs/spec.md. Note that this is an alpha version, so changes may occur as the specification stabilizes.
Source: GitHub Trending

Comments

← Back to Home