For years, a design system had one job: help people build more efficiently. Now it has a second reader (I dare to say, a more thorough one), and that changes the work.
This new user is the zero-ambiguity, no-BS type. It doesn't read between the lines, it reads your tokens, your rules, and builds straight from them.
So the things we used to invest so much time in are now quietly... breaking. They were never made for machine-reading.
A design system that isn't legible to machines is one AI will get wrong.
So I changed how I work: clearer architecture and documentation, straight-forward markdown files and rules, documenting what AI didn't get right to not make the same mistakes again, and better ways to keep design and code aligned, sometimes even as one.
And that's where I am right now: building the tooling so AI can also do decent work, and helping teams make the same shift, ideally before AI makes the gaps obvious.
"An AI-native process on a messy system isn't innovation. It's chaos, automated." — a design systems proverb (that I just made up)
Creating my first command and skill, and starting to learn when AI actually helps in my day to day.
A reflection on a design system experiment, silent feedback, and what I’d do differently today with AI.
Step one: let AI do the repetitive work, but not blindly. How I turned our documentation checklist into a skill.
As part of the team, I build and maintain systems and workflows tailored to specific needs, and help people use them.
On a project basis: an audit, some governance, or untangling a system that's outgrown itself.
👻
Good design system work is often invisible. If people can focus on the actual problem instead of fighting the tool, that's success, not how polished the file looks.
🤖
AI should take the boring work off your plate: audits, first drafts, repetitive tasks. But the human touch still matters. Some things can be accelerated, not fully replaced.
📡
Tokens and docs used to onboard designers. Now they also feed AI tools, which improvise (badly) when the source is ambiguous. If your system isn't readable by machines, there's no magic command that will make it build with quality.
🔗
Design and code have often told different stories. But it's never been easier to make them tell the same one. The answer isn't choosing one over the other, but (re)creating the conditions for them to evolve together.
Hey, I'm Érica. I've been in design for 15+ years and somewhere along the way became the person who figures out how to make design systems survive contact with real teams and real problems.
I write about what I learn as I go: the wins, the awkward moments, the “well, that didn’t work” parts, at Design Systems Unfiltered. No BS.
Remote-first, AI-curious, and always looking for ways to make complex work a little simpler.
erica@portfolio:~$