Three things crossed my desk this week about naming conventions, accordion chevrons, and CSS query types. They might be the most important design reading I've done all month.
That sounds absurd. But these are the kinds of decisions that quietly determine whether a design system actually works — or just looks like it does.
What happened
A practical guide on naming UI components laid out conventions for keeping component libraries consistent and navigable. Separately, an analysis of accordion icons made the case that the chevron is the safest, most universally understood choice — and warned against split menus where an icon and its label trigger different actions. And a piece on container queries argued that most teams are using them wrong, treating them like viewport-based media queries when they're a fundamentally different tool for making components context-aware.
Three different topics. One shared insight: the decisions that feel too small to argue about are the ones carrying your entire system.
The quiet architecture nobody talks about
Here's what I've noticed after years of working with design systems: the ones that fall apart don't collapse because someone picked the wrong colour palette or chose a bad grid. They erode. Slowly. Through a thousand micro-decisions that nobody thought were worth documenting.
What do you call a card that's also a link? Is it card-link, linked-card, or clickable-card? Seems trivial. Multiply that ambiguity across two hundred components and three years of team turnover, and you've got a system where nobody can find anything and everyone's building custom variants instead of using what's already there.
The same thing happens with interaction patterns. If your accordion uses a plus icon in one place and a chevron in another, you haven't just got an inconsistency — you've got a system teaching users two different mental models simultaneously. That's not a minor visual niggle. That's a usability problem hiding in plain sight.
And now that container queries have broad browser support, the question of which responsive technique to use where has become a genuine architectural decision. Media queries respond to the viewport. Container queries let a component adapt to whatever parent it's placed inside. Get this distinction wrong, and your "reusable" components only actually work in the one context where they were originally built.
None of this is dramatic. All of it is consequential.
Why the boring stuff outweighs the big decisions
We spend enormous energy on the headline choices — which design tool to adopt, which framework to standardise on, whether to integrate AI into the workflow. Those conversations feel important because they're visible and everyone has an opinion.
But the quiet stuff compounds.
A naming convention isn't exciting, but it's the difference between a developer finding the right component in thirty seconds or rebuilding it from scratch because they couldn't. An icon choice for an accordion won't win any awards, but it determines whether users understand your interface or hesitate every time they interact with it.
These decisions are also — and this is the part I find most interesting — the ones that resist automation. No AI tool is going to name your components in a way that makes sense for your specific team's mental model and your specific product's language. No generated code will decide whether a component should respond to its container or its viewport without understanding the broader system it lives in.
This is where design craft actually lives. Not in the visual polish. In the accumulated weight of small, deliberate choices made by people who understand the context.
What compounds in the other direction, too
The good news is that this works both ways. Inconsistency compounds into chaos, but consistency compounds into something genuinely powerful — a system where every new team member can orient themselves quickly, where components actually behave the way you'd expect when you drop them into an unfamiliar layout, where the cognitive load of maintaining the whole thing stays manageable instead of ballooning every quarter.
That kind of system doesn't come from a clever architecture diagram. It comes from a team that took the boring decisions seriously enough to document them.
Takeaway
Pick one non-visual layer of your design system — naming, interaction patterns, responsive strategy — and audit it this week. Look for the inconsistencies that crept in when nobody was paying attention.
I guarantee you'll find some. We all do.
The fix isn't a massive overhaul. It's making the convention explicit so the next person doesn't have to guess. Write it down. Align your team. Move on. That's not glamorous work — but it's the work that keeps a system alive.