(Yes, I’m intentionally referencing a article that references another article. Because the original article is on X and, well, fuck that.)
AI creates a similar catch 22 situation with programming and junior talent by creating exceptionally potent people in terms of their agency, but at the same time creates big gaping holes in their knowledge of their craft that they are completely useless without AI.
People are understandably worried about the erosion of direct knowledge/skill due to AI. The same can be said about design systems. Any abstraction that removes work also removes the skill of doing that work. I’m getting more and more worried about the role design systems could play in dumbifying designers and engineers. This may be the topic I’m most interested to take head on in 2026.
There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.
They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation - often immensely.
A lot of the problems in the first article can be addressed with good documentation. I know documentation is a dirty word to many, but I think we can make using docs a great experience. This article claims it’s unlocked the “secret”. Now, I get the heeby-jeebies whenever I read claims like this. All sorts of red flags start to wave. But my internal bullshit alarm hasn’t sounded off even once after reading through a decent portion of their docs.
So much of current design documentation is barfing out all the information into a single spot as opposed to creating bite-sized guidance through key workflows. This seems like a missing piece that should be filled in with haste. I’m hopeful this is something I can explore in the near future.
For many years now, loading speed has been more important than ever because most web traffic is on mobile devices. That’s nothing new. Yet the web is still filled with a lot of bloat. We have free browser tools to test speed, performance, and slow connection speeds. And we have lightweight architectures or frameworks to choose from.
This may not seem like an article, but I can’t help but grimace when reading. Because many of the decisions design systems make around adopting frameworks/dependencies end up biting users in the ass. Namely with web performance. No, I do not think it’s acceptable to download megabytes of JavaScript to render a simple website. I don’t care how much better the developer experience is.
I think it’s time to take accounting into just how much weight we’re adding to the product through these choices. There’s no reason a design system can’t help deliver great plain text websites. Even at the expense of a little more developer friction.
Large software systems are very poorly understood, even by the people most in a position to understand them. Even really basic questions about what the software does often require research to answer. And once you do have a solid answer, it may not be solid for long - each change to a codebase can introduce nuances and exceptions, so you’ve often got to go research the same question multiple times.
I believe a lot of the challenges we’re seeing in the current generation of software comes down to this very issue. Software is so big and complicated that no one fully understands the thing they’re working on.
That is such a existential problem. I cannot overstate how destructive this is to quality.
Design systems are not immune to this. The bigger they become, the harder it is to grasp its full footprint. Now imagine working on software that no one fully understands with a design system that no one fully understands…
I cannot think of a greater responsibility for a design system team than for everyone on the team to truly grasp how their design system works. From head to tail. Resist sprawl and feature creep. Stay small, focused and understandable.
This promise is fundamentally about money. The federated model gets framed as a way to get a design system “for free.” You can save the cost of staffing a dedicated team by distributing the work across existing teams.
Yup. This is entirely about money. If companies were so bought in to the idea of federated models, they’d be pervasive in organizational operating models. But they aren’t–at least from my purview. The push for federated design systems is the push to get something without having to pay for it. Which, to be fair, is human nature. The problem is that it doesn’t work. Not only does it not work, it becomes a distraction to everyone roped in to work on it. As is the case with a lot of things, “free” ends up costing a lot of money.
The Design Tokens Community Group today announced the first stable version of the Design Tokens Specification (2025.10), marking a milestone for design systems teams and tool makers worldwide. After years of collaborative development, the specification provides a production-ready, vendor-neutral format for sharing design decisions across tools and platforms.
This is a relatively dated update, but a significant one. Design systems are ironically lacking in open standards. Design tokens represent a great starting point. My hope is that this spreads to defining standards around documentation, component specification and library structure.
I’m not a fan of blindly following what others are doing. But I’m also not fond of reinventing a half-ass wheel whenever it’s time to spin up a new design system. Standards would create a bare-minimum that teams would be held to. I think it’d go a long way to raise the floor on the quality of systems. Here’s to more standards in 2026.