We optimised for creation when the constraint was always operation. The craft of design systems has matured considerably over the past decade: better tokens, stronger governance, documented components, clearer APIs. What the community has not yet figured out, almost universally, is what to do with it all the morning after it ships.
That gap is becoming harder to ignore. AI is now surfacing it in ways that are difficult to argue with. When an agent is handed your documentation and still reaches for freshly generated code instead of your component library, the system failed a legibility test, not a tool test. The signal is uncomfortable but it is precise: if your design system cannot be understood without a human translator, it was never really infrastructure. It was craft, maintained by goodwill.
The pressure is arriving from multiple directions at once. Stakeholders want ROI. Mobile platforms fail in ways desktop never prepared us for. Consumers are multiplying, teams are distributed, and the patterns that held at small scale are quietly breaking under the weight of the real thing. Somewhere underneath all of it is the question the industry has been avoiding: we know how to build design systems, but do we know how to run them?
In this issue
📚 Featured Articles
📰 Published in the Last Week
🎗️Support us
📝 Closing Thoughts
📚 Featured Articles
Must-read articles at www.designsystemscollective.com.
💡 Have an article to share? Submit it here!
We know how to build design systems, but we don’t know how to operate them by Murphy Trueman
Why We Like It: Moves the conversation from creation to long term operation, borrowing hard-won practices from DevOps and platform engineering. A strong roadmap for moving design systems from craft project to reliable infrastructure.
Pro Tip: Practical guidance on observability, SLO-style health indicators, managed deprecation and golden paths: the article explains what to measure, how to warn consumers, and how to make the right path the easiest path. If you run a DS team, treat this as a checklist for operational maturity.
What Actually Breaks in Mobile Design Systems at Scale by George William Amalan
Why We Like It: A forensic, operational guide to real failure modes in mobile systems with concrete fixes you can apply today. Essential reading for any team shipping cross-platform at scale.
Don’t Miss: A clear, practical catalogue of the failures you will actually encounter - token format mismatches, runtime theming differences, boolean-prop bloat, snapshot testing pitfalls, performance trade-offs, multi-brand strategies and automated accessibility checks. Read it as both checklist and playbook for keeping your mobile DS resilient.
Measuring the Value of a Design System with AI by Alex Cerqueira
Why We Like It: Strong, business‑facing framework that maps AI-enabled DS work to measurable ROI and operational KPIs. Useful when you need to persuade leadership or shape a measurement programme.
Perfect For: A structured breakdown of metrics (efficiency, quality, organisational impact), ROI calculation, risks (hallucinations, loss of brand), governance needs and a forward view of conversational and IDE-integrated assistants. Read this when you want to turn DS + AI into an executive conversation with numbers.
I Gave My Agent CLAUDE.md and DESIGN.md. It Ignored My Entire Component Library. by Surendar Selvaraj
Why We Like It: Extremely practical account of the missing link between tokens and usable components for AI agents, with an actionable “system.md” pattern.
Pro Tip: Short, high‑impact recipe: fill Figma variable descriptions, use Dev Mode notes, and publish a system.md in the repo so agents can stop guessing. Includes templates and a GitHub starter to implement immediately. Great for engineering teams adopting agentised workflows.
📰 Published in the Last Week
To stay updated on the latest articles, we share every new article on our LinkedIn page.
Design Systems and AI
👉 AI makes creation easy but not responsibility – from a design system engineer perspective by Chong Lu Khei
👉 Measuring the Value of a Design System with AI by Alex Cerqueira
👉 Your team adopted AI-driven development. never knew your design system wasn’t ready for it. by The Maker’s Lab
👉 AI Generates Code. Design Systems Generate Understanding. by Angus Ewing
👉 I Gave My Agent CLAUDE.md and DESIGN.md. It Ignored My Entire Component Library. by Surendar Selvaraj
👉 Same Brief, Two Claudes by Carina B. Velasquez
👉 Why Design Systems Matter More Now That AI Writes Half Your UI by Saman Baboli
Governance and Operations
👉 Selling Your Design System to Stakeholders Who Don’t Care About Design by Madhesh P
👉 We know how to build design systems, but we don’t know how to operate them by Murphy Trueman
👉 Burning Down the House: Design Debt, UX Failure, and Scaled Exclusion by Regina McDonald Russian
Component Architecture and Scale
👉 What Actually Breaks in Mobile Design Systems at Scale by George William Amalan
👉 Custom vs Native Design Systems: Knowing What to Build vs What to Borrow by Vedant
👉 The Hidden Challenge of Bundling Styles in a Design System by German Quinteros
👉 How to Build a Design System in a Weekend (For Solo Devs and Small Teams) by Mohit Phogat
Perspective and Opinion
👉 The Web Has a Missing Layer. Nobody Is Talking About It. by Eddie Lou
👉 Design systems are contracts, not libraries by Cristian Morales Achiardi
Accessibility
👉 Where Accessibility Begins by Gantushig Javkhlan
Measurement and Impact
👉 UX Metrics for Business Impact in 2026 by Veronika Sulimova
🎗️ Support us:
If you find our content helpful, here’s how you can support us:
Forward this email to a friend and invite them to subscribe
Support our writers by visiting the Design Systems Collective website
📝 Closing Thoughts
The answer, if there is one, is probably borrowed. DevOps solved a version of this problem: software teams that could build but not operate. Platform engineering solved it again: infrastructure that could scale but not self-serve. Design systems are arriving at the same inflection point, a few years behind, and with a few additional complications.
One of those complications is that the consumers of your system are no longer just developers and designers. They include agents, assistants and automated workflows that do not share context, do not read between the lines, and will not ask for clarification. Legibility has become a design constraint, not just a documentation problem. The systems that will hold up are the ones built to be understood without a human in the loop.
None of that is reason for pessimism. It is reason for precision. The question is not whether to operate your design system. The question is whether you have been honest with yourself about what operating it actually requires. Build well. Then figure out how to run it.
Founding Editor, Design Systems Collective