In the last piece, we talked about what DESIGN.md is.

A single file. A briefing document for the machine.

The thing that makes your design system legible to AI coding agents.

But there's a question that comes right after.

What happens when the design system changes?

Because design systems always change.

New tokens. Updated components. Deprecated patterns. A color that shifted two shades in the last sprint.

And every time something changes, two problems appear at once.

The file goes stale.

And the developers don't know.

And by the time anyone notices, three sprints have passed and the AI is still generating UI with the old primary color.

This piece is about solving both.

Want more like this? Subscribe to get my free UX prompt guide for designing with AI and join the exploration.

Most teams handle design system updates the same way.

A designer makes a change in Figma.

Publishes the library.

Then sends a message somewhere: Slack, email, a comment in Jira - saying something changed.

The developer reads it. Or doesn't.

Interprets it. Or misinterprets it.

And somewhere between that message and the codebase, the update gets lost, delayed, or applied inconsistently.

It's not a Figma problem.

It's not a developer problem.

It's a communication architecture problem.

The update lives in Figma. The code lives in GitHub. And nothing connects them.

Until now.

You don't need a complicated setup.

You need three things working together.

Tokens Studio → GitHub → CHANGELOG.md

That's it.

Each one does a specific job.

Tokens Studio moves the tokens.

GitHub holds the review.

The changelog explains what changed and why.

Let's walk through each one.

Tokens Studio is a Figma plugin.

It connects your design tokens: colors, typography, spacing, radius, effects directly to a GitHub repository.

When you update a token in Figma and push it through Tokens Studio, it doesn't send a Slack message.

It opens a Pull Request in GitHub.

A PR is a formal change proposal in code.

It shows the developer exactly what changed (before and after) in a structured diff.

color-primary: #3B82F6 → color-primary: #2563EB

Not a description of the change.

The actual change.

And the developer can review it, ask questions, approve it, or flag a concern: all inside GitHub.

Nothing gets lost in a chat thread.

The free plan covers GitHub sync for a single file, which is enough to get started.

This is the part most designers don't expect.

You don't need to notify the developer separately.

When Tokens Studio opens a PR, GitHub notifies them automatically.

They get an email. A GitHub notification. A ping if you've set up Slack integration with GitHub.

The PR is the notification.

And unlike a Slack message, it comes with full context.

The developer can see:

They review it the same way they review code.

Because it is code now.

Your design decisions, committed to the repository.

Token diffs are precise.

But they don't tell the full story.

A developer looking at a color change from #3B82F6 to #2563EB might wonder:

Is this a global rebrand? A contrast fix? A one-off exception?

That context lives in CHANGELOG.md.

A simple file in the same repository. Updated by the designer alongside every push.

The format doesn't need to be complicated.

Plain language. Written by the designer. Permanent record.

The developer reads the diff in the PR.

They read the context in the changelog.

They have everything they need to merge with confidence.

The token pipeline handles the code side.

But designers working in Figma also need to know something changed.

That's where Figma's native library publishing comes in.

When you publish an update to your shared Figma library, every file that uses it shows a quiet banner:

"Updates available from [your library name]."

Designers can review and accept the update or hold off if they're mid-sprint.

It's not as structured as a PR.

But it closes the loop on the design side of the team.

Once this is set up, here's what a typical design system update looks like.

No Slack fire. No missed messages. No "wait, when did that change?"

Just a clean, reviewable, traceable update: every time.

If you're the PIC for your design system, this is your pipeline to own.

You're the one who:

You are the bridge between design and development.

And with this setup, that bridge has structure.

Not because every tool is perfect.

But because the workflow is clear.

You don't have to set all of this up in a single afternoon.

Start with Tokens Studio and a GitHub repository.

Get one token change through the PR flow.

See how it feels.

Then add the changelog. Then formalise the library publishing cadence.

The goal isn't a perfect system on day one.

The goal is a system that makes design updates reviewable and traceable instead of announced and forgotten.

That shift alone changes how design and development work together.

And it starts with a single push.

Next in this series: Part 3: How to write a DESIGN.md that AI coding agents actually follow and what to include when your system gets complex.

Subscribe to Design x Machine for more on UX, intelligent systems, and the future of design practice.

👉 designxmachine.beehiiv.com