Google standardises design for machines.

Google Labs has open-sourced DESIGN.md, a format meant to describe a product's visual identity so a coding agent can respect it without guessing. The announcement appeared on Google's official blog on 21 April 2026, alongside the publication of version 0.1.0 of the google-labs-code/design.md repository on GitHub. Worth reading for what it implies, not for what it promises.

What DESIGN.md really is

The structure is simple. A text file in two layers: at the top, a YAML block declaring the system tokens — colours in hex, sizes in px or rem, typography, border radii, component definitions — with a token cross-reference system; below, Markdown prose explaining the choices and why. Designed to be read by an agent before a human. The package ships a CLI with four essential commands: lint to validate the file and check WCAG contrast, diff to compare versions, export to emit Tailwind, CSS and W3C DTCG tokens, spec to return the format specification.

The operational point is to move information that today lives in designers' heads, in brand book slides and in Figma folders behind permissions, into a single text file that lives next to the code. An agent generating an interface no longer has to infer the palette from a screenshot or remember the right font: it reads it, and if it gets it wrong the linter tells it.

A minimal example of what a DESIGN.md actually looks like, simplified for readability:

---
brand: Acme
version: 1.2.0
tokens:
  color:
    primary: "#0066FF"
    primary-hover: "{color.primary | darken(0.1)}"
    page-bg: "#FFFFFF"
    page-text: "#0A0A0A"
  spacing:
    md: 16px
    lg: 24px
  typography:
    h1:
      size: clamp(2rem, 5vw, 4rem)
      weight: 800
      family: "Inter"
  components:
    btn-primary:
      bg: "{color.primary}"
      color: "#FFFFFF"
      padding: "14px {spacing.lg}"
      hover-bg: "{color.primary-hover}"
---

## Why primary is blue

Blue has been the colour of European public-transport networks since 1968.
Acme operates in logistics-transport: our target reads blue as "functional
reliability", not "technology". The choice is consistent with the brand
recognition tail.

## When NOT to use btn-primary

Never more than one per fold. Never in table columns (reduces legibility).
Never on top of an image without a dark overlay (contrast below WCAG AA).

Fifty lines doing the work of a sixty-page brand book PDF, with one extra benefit: an AI agent can consume it directly and generate correct code without any visual interpretation. The prose part ("Why primary is blue"), often dropped as accessory, is actually what lets the model make intelligent decisions on cases not covered by tokens: if an alert colour is needed that was never declared, the model reads the narrative and understands it must stay in the "functional reliability" register, not jump to an emotional red that scares.

What changes versus W3C Design Tokens

For those following the design-standards dossier, the obvious question is: what does DESIGN.md add beyond what already existed with W3C Design Tokens (DTCG)? Three points. First: W3C Design Tokens are tokens only — a structured JSON of colours, spacing, typography. DESIGN.md embeds the tokens in the same file but adds the narrative context no JSON naturally structures: why primary is blue, when not to use btn-primary, what the acceptable exceptions are. A competent coding agent knows the tokens tell it "what", the prose tells it "when" and "why".

Second: DESIGN.md ships a CLI to validate the file, export to different targets, and diff across versions. W3C Design Tokens leave validation to whoever adopts the standard. DESIGN.md is opinionated: it wants you to validate contrast, count orphan tokens, check circular references. Opinionated means more rigid but also more consumable out-of-the-box.

Third, and perhaps most important: DESIGN.md is written by Google. W3C Design Tokens are a consortium. Translated: the adoption curve will be very different. A format pushed by a single Big Tech with its own CLI and agents natively recognising it enters in practice within six months. A consortium standard enters in five years or doesn't enter. It isn't a judgement on quality — it's an observation about market adoption speed.

Three angles that matter

The first: we are watching the birth of a new class of artefacts, files designed to be read by machines before people. README, AGENTS.md, now DESIGN.md. Every domain of the company — sales, design, legal, internal process — will end up compressed into a declarative file with structured front matter. Whoever runs a company should get used to the idea that their brand book, today a sixty-page PDF, soon will be a two-thousand-line text document. More awkward to lay out, incomparably more useful.

The second: the fact that Google releases the spec as an open standard, with permissive licence and CLI independent of Stitch, is a precise move. They aren't selling a product, they're trying to set a protocol. Whoever adopts DESIGN.md first finds themselves aligned with any future agent trained to recognise it — and Google will train plenty of them. It's the same logic by which 1994's robots.txt determined twenty-five years of indexing: those who put the file in were respected.

The third: the spec is version 0.1.0, declared alpha, with explicit warning that the format will change. Translated: those who wait for stable 1.0 will arrive late. Those who adopt now pay a maintenance cost but buy optionality. It's a calculation to make cold, not a reason to ignore the announcement.

v0.1.0 limits (and what's needed beyond)

DESIGN.md is born for visual design: colours, spacing, typography, basic UI components. Well covered. But a complete brand system includes at least four other contracts the current spec doesn't touch:

• Complex components · anatomy + variants + states. A "btn-primary" button is easy to declare in YAML. A blog-post card with header + media + body + footer, with variants for featured / regular / sponsored, with hover / focus / loading / error states, requires a structure flat YAML doesn't naturally handle. A second file (COMPONENTS.md?) or a spec extension will be needed.
• Content types. What's a "blog post"? A "case study"? A "persona"? An agent generating content needs to know the schema of content types, not just how to render them. DESIGN.md doesn't deal with it.
• Page templates. A homepage is hero + 5 sections + footer. A blog index is grid + pagination. A FAQ is Q&A list. The sequence of components on a page is a contract in itself.
• Voice and copy. Which words to use, which to avoid, what the tone is. DESIGN.md describes the colour of a button but not what to write on it.

Anyone adopting DESIGN.md today is making a partial investment. It's a good investment — the piece it covers is the one that gets touched first — but the complete system requires a family of machine-readable files, not a single file. Expecting DESIGN.md 1.0 to cover everything would be short-sighted. Expecting 0.1.0 to be enough to replace the brand book would be overestimation.

Jigen's position

Our trade is putting AI automation into production inside a company in twenty-one days. When a small task force enters a client and has to make an agent speak with an interface, a set of components, a visual tone of voice, the real problem is always the same: the brand's source of truth is scattered. Three Figma files, two Notions, a 2022 PDF manual, a designer who remembers it. Every iteration costs reconciliation. DESIGN.md, even in its immature form, finally gives an anchoring point: a single file the agent reads every time, the linter verifies, and that stays versioned alongside the code.

The point isn't that DESIGN.md is perfect. It's that it crystallises a movement already underway: the companies that will win the next five years will have their design system, their sales system, their onboarding process written in structured formats an agent can consume without intermediaries. Everything left in PowerPoint will become inert.

We've already seen this on our own Design System. The Jigen DS consists of narrative HTML documentation pages (for humans who read) plus a family of machine-readable files (tokens.json, components.json, glossary.json, content-types.json, page-templates.json, plus an llm-porter-playbook declaring the reading order). The logic is the same as DESIGN.md, and it demonstrates something worth saying out loud: a machine producing code or copy is no less demanding than a designer. In fact, it's more rigorous, because it doesn't fill in with "common sense" — it fills in with what it finds. If the source is ambiguous, the output is ambiguous.

How to write a DESIGN.md the first time

For those starting from zero, the path is predictable. Three or four half-days spread across a week, not a project to quote:

Session 1 · Colour tokens + WCAG. The whole brand palette pulled from Figma or reconstructed from a screenshot, converted to hex, declared as tokens. For each colour, compute contrast against reference backgrounds (light, dark, possible pastel variant). Pairs below AA need correcting or annotating as "decorative only". It's the moment when brand-book inconsistencies no one had ever named come to the surface — almost always does.

Session 2 · Spacing + typography. The spacing scale (4/8/12/16/24/32/48px) declared as tokens. The type scale with font-family, size, weight, line-height, letter-spacing for each role: H1, H2, H3, body, caption, eyebrow. Publish even the tokens used in rare exceptions — better to have them written and unused than to invent them on the fly.

Session 3 · Five core components. Button (primary/secondary/ghost variants), card, form input, badge, nav. For each: anatomy, states, composition rules, known anti-patterns. This is the session that requires a designer in the flesh, because some details (how to handle a disabled button, where the focus ring lives) can't be inferred from any screenshot.

Session 4 · Companion prose. For every non-obvious choice, two-three sentences explaining why. This is the section most companies skip — "isn't it obvious from the token?" — and is actually the one that lets an agent make intelligent decisions when it hits a case outside the catalogue.

By end of week there's a file living next to the code, versioned, consumable by any coding agent. Cost: ~20 hours of work distributed. Benefit: every future brand-alignment iteration costs minutes instead of days.

Quick test · is your brand already machine-readable?

A diagnostic grid for the leadership of a company wanting to know where they stand. Five questions:

1. Does a text file (any format) declaring the complete brand palette exist? Yes → next. No → there's a first session to run.
2. Does a file declaring the complete type scale exist, with font-family + size + weight for each role? Yes → next. No → second session.
3. For each main UI component, does a structured description of variants, states, composition rules exist? Yes → next. No → third session.
4. Does a prose document exist explaining the non-obvious brand choices (why blue and not red, why Inter and not Garamond)? Yes → next. No → fourth session.
5. Can a coding agent (Claude, GPT, Gemini, an internal copilot) consume these files without first being "explained" by a person? Yes → you're machine-readable, congratulations. No → the final session consists in making them consumable, typically by converting from PDF or slides to YAML/JSON/Markdown.

Five yes out of five: the brand is ready for 2026 and beyond. Three or four yes: you're a week of work away from being ready. Two or fewer: there's structural debt that every week pays in dispersive iterations — and that, in six months, will be even more costly to settle because in the meantime agents will be doing more things, each of which will cost manual reconciliation.

Concrete implication

For a founder or CEO the question to ask this week is one: if tomorrow morning an AI agent had to generate the next landing page, the next email template, the next dashboard, which file would it read colours, typography and component rules from? If the answer is "none, we ask the designer", the company is off-standard. There's no need to adopt DESIGN.md today; there's a need to accept that tomorrow's brand book will be a text file, and to start writing it. Cost is an afternoon. Cost of not doing it is every future iteration paid in rework hours.

Google has published an alpha specification and a CLI of a few hundred lines. The event looks minor. It isn't. It's the first public standard of a protocol that, within six months, will be the silent presupposition of any design agent.

Source: Google Labs, "Stitch app's DESIGN.md format is now open-source for designers", blog.google, 21 April 2026 — read the announcement ↗ and the repository on GitHub ↗. Jigen reading: DESIGN.md isn't a tool for designers — it's a tool for coding agents that have to respect an identity without guessing. It's a step in the same direction as our internal Design System, which today already exposes a family of machine-readable files (tokens / components / content-types / page-templates / glossary / playbook). Adopting it early means aligning with the protocol that in six months will be silent default. Waiting for stable 1.0 means arriving after others have already taken their place.