“What is next for design systems?”
I was recently asked this question in an interview. It's not that I hadn’t thought about it before, but hearing it in a high-stakes setting made me dig deeper.
I’ve been laid off multiple times in tech, including from a role where I led a design systems team. It wasn’t due to a lack of actual impact, but a lack of perceived value.
That design system supported hundreds of engineers, yet leadership wasn’t fully aware of what we were producing. That disconnect, paired with a largely absent director, led to a “restructuring event.”
So yes, I’ve thought hard about what’s next. My answer is shaped by both personal experience and the rapid rise of AI and I’ve broken it down into a few key themes:
1. Bye bye busy work
The majority of component design, pattern documentation, and other repetitive workflows will be automated. This isn’t theoretical, it’s already happening. Tools like Subframe and Dessn let you visually design and export production-ready code. It’s not perfect, but it’s close enough to shift what we spend time on.
The truth is, you can only build so many components before your team becomes a production shop instead of a systems team. Automating repetitive tasks frees you up to solve real problems, like reducing inconsistency, improving accessibility, or enabling designers to move faster.
2. Monetization (Yes, you need to prove value)
Let’s be honest, “We save the company money” isn’t a compelling story if you can’t back it up. Design systems have promised ROI for years without delivering hard metrics. That’s often why they’re first on the chopping block.
Here’s what proving value can look like:
The design systems team and I automated the icon-to-code pipeline by centralizing icons in a single Figma file and writing custom code to convert them into SVGs and XML vector drawables for iOS and Android. We built a webhook and a GitHub Action to listen for Figma publish events, streamlining the workflow and cutting icon production time from three weeks to minutes. This saved the company over $100,000 annually in design, development, and project management hours and created a central source of truth for icons.
During a company-wide brand refresh, the design systems team created a new Figma library with reskinned components. I built a custom Figma plugin to automate component swapping, enabling designers to quickly migrate their files. This saved an estimated $30,000 in design hours.
The design systems team and I automated the design token-to-code pipeline using Token Studio, Style Dictionary, and GitHub Actions. This improved component development speed by 50% and reduced style-related QA bugs by 75%.
So, you built a component. Cool. Now tell me: what dollar amount can you tie to that work? It might sound harsh, but you either answer that question or start prepping for your next job search.
3. Systemizing culture
The systems skills that the design system team possesses will become universally applicable to the wider design organization. The design systems team will take on more responsibility, ironically with less manual work, and the design system will be just one of the many product areas they support.
The design systems team will be known as the “systems team” as they work to systematize all pieces of the UI and automate workflows. This will theoretically reduce feature product designers’ and engineers’ workloads, freeing them up to do things like, I don’t know…talk to the customer?
4. Automating workflows
I don’t get why more teams aren’t doing this. I’ve built multiple Figma plugins and automated pipelines myself and with teammates. I was even chatting with my friend Grant over at LinkedIn about how their team is using plugins and tooling to automate linting and streamline their design process. They are saving boatloads of cash with automation!

Systems teams need to look up and out from just component work. I’ve saved companies hundreds of thousands of dollars by automating workflows in Figma, and you can too.
It is so easy to code now and build plugins using AI. Your job as a systems designer has always been to make things faster and better for your customers: other designers and engineers. Leverage tools like Lovable or Claude.
5. Closer to code
I’ve been beating this drum and will continue to do so. Design tools like Sketch and Figma have created abstractions of what is real: code. And then companies, teams, and individuals create plugins to try and reverse engineer those abstractions back into code. A little backwards if you ask me.
Tools that allow teams and designers to leverage LLMs to rapidly iterate with existing design system infrastructure, e.g., components and tokens, will win. Those who don’t will lose.
Tying it all together
Design systems won’t disappear, they’ll evolve. The work will shift from pixel pushing to infrastructure, from component factories to workflow automation, from maintaining UI kits to enabling velocity across the org.
Design systems are becoming operating systems for design orgs.
If you’re on a systems team today, you should be thinking beyond your library. You should be thinking about how to automate, measure, and scale your impact.
Let me know what you think in the comments below!
We’re thinking along similar lines here, but I am always very leery of centralizing workflows and source-of-truth around a closed-source 3rd party tool (Figma) with no real offboarding story.
The process of transitioning our design system at Heroku from Slack to Figma took an incredibly long time due to lack of prioritization (“don’t we already have a design system?”) and a constantly moving target (so rude to keep shipping and evolving the product, right?)
My top design system principle these days is “code as source of truth”. This works OK for tokens, it’s an immense challenge for components. The guys at <div>RIOTS have put together some really interesting tools though, like html.to.design to vectorize browser screens into Figma, and story.to.design to pull in whole components and map story props to variants. We’re going to be investigating these in the PayPal merchant design org over the coming months to let us shift the role of Figma more toward rapid, ephemeral design exploration, and away from acting as a “second source of truth” that needs constant two-way syncing with the live code base.
It sounds like with automation we might lock in a model that needs repeating over time, which can be important, but then I have noticed stakeholders become risk-averse when we deviate from the model. I look for flexible components that can allow designers to implement various layouts (which CSS lets us do flexibly once JS is nailed down).
I appreciate this thought direction! I think it can help prove the business value of design to stakeholders. I remain a fan of Zeplin for preserving the human element with documentation, and it can be integrated with Storybook for live code updates. It also pings Slack for updates (similar to your GitHub integration, which also sounds powerful)