Every design system currently running inside a large organisation is operating on borrowed confidence. Someone, at some point, decided the tokens were consistent, the documentation was current, and that the button in the library was, in fact, the button. Nobody has gone back to check any of that in a while.
That borrowed confidence used to be a slow-burning problem. A designer would eventually notice the drift, raise it in a review, and the system would get patched before the gap became embarrassing. Hand the same system to an agent that reads the documentation as ground truth and executes on it at speed, and the gap stops being a slow-burning problem. It becomes the output.
The harder skill, for a system or for the person running it, was never producing a confident answer. It is knowing when not to give one. That is the thread running through this week’s pieces: infrastructure honest enough to say what it does not cover, token architecture that survives an actual audit rather than a demo, documentation written to remove the guesswork an agent would otherwise fill in on its own.
None of that is glamorous work. It is also the only kind that holds up once something else is relying on it. Worth asking of your own system this week: if it had to admit what it was unsure of, would it know how?
📚 Featured Articles
📰 Published in the Last Week
🎗️Support us
📝 Closing Thoughts
Must-read articles at www.designsystemscollective.com.
💡 Have an article to share? Submit it here!
I Built a Design Review Skill. The Hardest Rule Was Teaching It to Say “I Don’t Know.” by Surendar Selvaraj
Why We Like It: A rigorous, practical exploration of automating repeatable design checks with an evidence-first approach and an open source skill you can run today. It directly addresses automation risk, score honesty, and agent limits — essential reading for teams adding AI to review workflows.
Pro Tip:The article ships both a concept and a runnable repo. It explains why reviewers must distinguish judgement from verifiable checks, shows how to handle unverifiable items, and provides a defensible scoring model so teams can trust automated reports without outsourcing responsibility
.
Figma Variables in 2026: The Non-Negotiable Foundation Your Design System Can’t Skip by Madhesh P
Why We Like It: A thorough, practical case for treating Figma Variables as core infrastructure, with migration advice and real governance implications for multi-theme systems. It is exactly the kind of guidance design-system leads need to prioritise work and align with engineering.
Don’t Miss:This piece explains semantic naming, collections and modes, migration steps, and common pitfalls in a clear, actionable way. If your team is still on static styles, the article gives the business and technical arguments to make the case for change now.
Every Team Thought They Had the Right Button by John Ohio
Why We Like It: A grounded case study showing how a token-first approach (CAVIS) and tooling alignment cured real fragmentation across teams. Great lessons in governance, naming and adoption.
Perfect For:Design-system leads and engineers planning a rebuild or audit. The article combines audit methodology, token architecture, and the practical integrations (Token Studio, Storybook, version control) that actually drive adoption rather than just aesthetics.
Part 4: Scaling DESIGN.md When Your System Gets Complex by Ryda Rashid
Why We Like It: Practical, timely guidance for making DESIGN.md work at scale — theme-aware structure, ownership rules, and how to make documentation agent-friendly. Very useful for teams adopting AI-assisted workflows.
Don’t Miss:The article gives concrete file structures, contribution rules and agent-specific instructions (for example, “always declare the active theme”). It is a useful template for teams turning documentation into reliable system input.
To stay updated on the latest articles, we share every new article on our LinkedIn page.
👉 How to Build a Design System That Actually Scale by Wardharaheem
👉 Every “No” Revealed a Missing System by Carina B. Velasquez
👉 Part 4: Scaling DESIGN.md When Your System Gets Complex by Ryda Rashid
👉 Design Systems Are Fine. Defining Them Isn’t. by Alfredo Cisneros
👉 After Config 2026, the Design Systems Designer’s Job Just Got Bigger by Madhesh P
👉 “You Can Tell It’s AI.” Yes — That’s the Compliment. by Brady Starr
👉 You’ve Got One Last Shot: What Every Designer Needs to Hear About AI Right Now by Abhi Chatterjee
👉 The Missing Layer in AI-Assisted Development by Gantushig Javkhlan
👉 I Built a Design Review Skill. The Hardest Rule Was Teaching It to Say “I Don’t Know.” by Surendar Selvaraj
👉 Every Team Thought They Had the Right Button by John Ohio
👉 I stopped using Material Design & iOS Figma UI kits. Here’s why. by Vedant
👉 Figma Variables in 2026: The Non-Negotiable Foundation Your Design System Can’t Skip by Madhesh P
👉 The Overengineering Trap We All Fall Into by Masaood
👉 7 Clean Code Rules I Stopped Following Blindly by Masaood
👉 What Made Me Faster as a Developer Was Not Writing Code Faster by Masaood
👉 Flat DOMs Are the Ultimate Performance Ceiling: Why HTMX Outperforms React on Every Render by Matheus Lacerda
👉 How Chinese Color Theory Can Transform Your Digital Products by Appibara LTD
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
The best moment in a design review is rarely the confident one. It's the pause where someone admits they are not sure and suggests checking before shipping the decision. Turns out that's a difficult thing to teach an algorithm. It was never particularly easy to teach a room of confident designers either.
Founding Editor, Design Systems Collective
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.