In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that.
But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster.
Oof. This article (duly) blasts Apple for its use of icons in macOS 26. I wish icons were the only issue with the operating system, but that’s another thing altogether. macOS 26’s use of icons is a prime example erratic execution. Usage doesn’t seem to follow any shared rules or principles. This is all the more ironic given how many rules and best practices Apple has broken from their own playbook.
Apple’s HIG has been an industry standard for as far back as I can remember. It’s served the company, its products and third-party developers well. I wouldn’t necessarily call it a design system, but it’s influenced many, if not all systems that exist today.
This case highlights why guidelines are so important–and not important at all. Guidelines can ensure large orgs have a shared set of principles to follow. So the end product can, you know, not have erratic execution. But they’re only important if they’re followed. Apple chose to throw all those principles out the window–and man, did it backfire.
When the relationship between identity and expression isn’t explicit, coherence becomes fragile and decisions drift into taste, local optimization, or politics instead of adding up to something intentional.
This line really stuck with me. I’ve often thought about why so many companies have less explicit guidelines and rules around creating experiences. Because, as the author states, things tend to get squirrelly when they don’t exist. And I’ve come to the conclusion it’s because, to many, the bug is the feature. People want to make decisions on their personal taste. People want to locally optimize for their pet project. People are fine with rules, as long as it’s their rules.
Design systems can’t fix people. They’re limited by the failings of those who use and make it. And the problems above aren’t going away anytime soon.
Yes.
Both our design and engineering outputs created value, but not in equal proportion. We understood that a significant portion of our value came from code implementation, and we staffed accordingly. Our system was heavily automated, with algorithmic token generation, sophisticated tooling, and infrastructure that required significant engineering investment to build and maintain.
The author shares his experience of flipped engineer-to-designer ratios on design system teams compared to typical teams–and why that makes no sense. For what it’s worth, have had similar experiences and share a similar opinion about how much sense it makes. Why is this a thing? I don’t know for certain, but I wouldn’t be surprised if it has something to do with design systems being called design systems. People see “design” and jump to conclusions. Sounds incredibly dumb–I know. But in Silicon Valley, the dumbest possible reason is typically the correct one.
Nowadays, I think of Claude as a very smart child — one that loves to put together legos. Good infrastructure and abstractions are the lego blocks you give it. The bigger and better they are, the more you can do.
This is why design systems–for better or worse–stand to benefit from increased AI usage. Left to its own devices, an AI agent will usually pump out a gnarly (in a bad way) interface. There are just too many opportunities to screw up. But I think an agent can perform adequately when pulling from components high up the food chain. Because most of the decisions have (hopefully) been made by a skilled human being. I also like this approach because it theoretically means less tokens and GPU-go-brrrr from the agent. Design systems are going to play a big role in forming those legos for agents to build on top of.
When I imagine a better future for the software industry, I don’t imagine one where everyone is making their own text editors, their own debuggers, or their own UI frameworks. Instead, I imagine a future where we have new “high-level” tools, built from lower in the stack. I imagine new tools that give the same high-level benefits we expect today, and in fact do more than the tools we have today, because they are freed from the constraining decisions of the past. We can build new platforms, new tools, and new libraries that learn from the past, but build on solid foundations instead of piling more on top.
There’s so much to take from this article–it’s well worth the time to read in full. For nearly 15 years, I’ve been advocating for design systems as a driver of higher-level frameworks to compose higher-level UI. I’m less convinced of its value now. Sure, I think those high-level legos will be important for AI. But what about humans? I think it’s time to reconsider how many abstractions the typical design system is built on top of. I’d love to see a walk-back, where systems try to provide more that’s closer to the bare-metal. Granted, that’s always still going to be pretty high up the chain in computing. But I question the value of React being the starting point.
Perhaps it’s time to harken back to a simpler time.
The longer I spend working in tech, the less optimistic I become about our collective ability to predict where a system is going. It’s hard enough to get your head around where a system currently is. And in fact, that’s the main practical difficulty in doing good design: getting an accurate big-picture understanding of the system. Most design is done without that understanding, and most design is thus pretty bad.
Speaking of simple… I believe to my core that the decline of quality in software is due to the fact that none of the people working on today’s behemoth products fully knows how it works. There’s so much that goes into this–from organizational politics, to experimentation-driven product development, to a cultural mindset of adding more and more features. Simple left the building a long time ago. Hell, if probably never was in the building to begin with.
A design system team should know every metaphorical nut and bolt. Everything should be accounted for and placed with intention. That sounds straight-forward, but it’s damned hard to do. Especially when they’re built within a culture allergic to simple. This is important for everyone, but it’s essential for design systems. Every over-designed or over-engineered choice is not just our problem. It shows up everywhere. Discipline and restraint are key–even if it may not be understood or appreciated.
(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.