A team I cleaned up after had seventeen dropdown components. Not seventeen variants of one dropdown — seventeen separate components, each with its own states, its own spacing, its own quirks. The audit took longer than I expected, mostly because the team kept finding more. "Wait, this one's in a different file. So is this one."
Nobody set out to build seventeen. The first designer had a perfectly good reason — the spacing on the original was wrong for their case. The second needed a different icon slot. The third was working in a feature area where the existing dropdown's hover state didn't match the surrounding components. There was no design leadership conversation to say "let's fix the original instead." There was no shared review process to even notice a new component had been added. So another one went in, and another, and another, and the developers shipping them were doing exactly what they'd been asked to do.
The worst part isn't the count. The worst part is that every one of those dropdowns failed something. Most failed basic accessibility — no keyboard navigation, no screen reader labels, no focus management. Several were unusable on touch interfaces. A few looked fine in light mode and fell apart in dark. Building a dropdown that's accessible, reliable across browsers, responsive across input modes, and theme-correct in any context is genuine work. The team had done that work badly seventeen times instead of doing it well once.
The maintenance cost is the visible cost. The hidden cost is users silently hitting broken interfaces. A user whose screen reader trips on the wrong dropdown doesn't file a bug — they leave. A user whose touch device can't open the right menu doesn't email support — they close the tab. The savvier user, who recognizes the pattern, gets angrier — these are exactly the kind of amateurish mistakes a serious team isn't supposed to make. Seventeen separate components is a maintenance story. Seventeen separately broken components is a user story, and it's the one that should keep the team up at night.
How a Design System Fractures
The story always rhymes. A team ships a design system with components that solve the cases they imagined when they built it. Six months later somebody hits an edge case the team didn't imagine — slightly different padding, an extra slot, a state that wasn't covered — and they have a choice. Extend the existing component, or duplicate it and modify the copy.
Extension feels hard. It requires understanding how the existing component is structured, what its variants mean, which other teams depend on it, and how the change will land in every consumer file. It requires either a conversation with whoever owns the component, or enough confidence to make the call alone. It requires time the designer doesn't have, because they're trying to ship a feature, not rebuild infrastructure.
Duplication feels easy. Right-click, detach instance, rename, modify. Done in three minutes. The new component lives in the same file as the feature work. Nobody is asking permission. The original is untouched.
The local calculation looks obvious. The problem is that the team is climbing the wrong hill. The top of the hill is shipping this feature this sprint. The mountain is a design system that compounds — where every accessibility fix lands once and stays fixed, where every browser quirk gets named and never rediscovered, where the next designer two years from now stands on the work the last one already did. Duplication wins the hill. Extension is the only path up the mountain.
The seventeen-dropdown count is what happens when a team optimizes for the hill every time, for ten years, with nobody ever pulling them back to point at the mountain. Newton's "shoulders of giants" is the global-maximum version of this work. The local-max version is fifty people relearning the same browser bug, individually, in private, with nothing surviving any of those discoveries to help the fifty-first.
Multiply that decision by a hundred features across ten years and you get seventeen dropdowns. The same pattern produces five button variants, eight card layouts, four versions of the same modal. The fracture isn't visible until somebody pulls back and counts. And it outlives the people who made it — the escape key in Photoshop cancels a text edit, the escape key in Illustrator commits it, and Adobe acquired Illustrator something like thirty-five years ago. Design and tech debt are the digital equivalent of an invasive species. Once they're rooted, they're nearly impossible to extract without a coordinated effort somebody almost never wants to fund.
The Misdiagnosis
The first reaction I see when a team confronts the count is to blame the designers. "We need better discipline. We need a stricter review process. We need to enforce the system." This produces a brief flurry of consolidation, followed by another round of fracture starting six months later.
The designers aren't the bug. People follow the curb cuts of the system they're working within. If duplication is the path of least resistance, people will duplicate — not because they're undisciplined, but because they're behaving rationally inside the constraints they were given. The system is what gave them those constraints, and the system is what has to change.
This is hard to see from the inside. Joseph Heller spent five hundred pages on the point in Catch-22 — only Yossarian can see how insane the "sane" rules are, because everyone else has spent so long inside the rules that they've stopped noticing them. Most design teams are full of Yossarians who haven't realized they're Yossarians yet. The dropdowns are a symptom, not the disease.
The disease has multiple roots, and component infrastructure is only one of them. Components that don't extend gracefully are part of it — the original button wasn't built to accept a new state, so the designer forked rather than fight it. But it's also incentives: in most orgs, shipping a feature is rewarded and refactoring an existing component is invisible work, so the rational employee ships the feature and never touches the component. It's also discoverability: a designer may not know the existing dropdown is there, because nothing in the system surfaces it at the moment they're reaching for one. It's also engineering politics: the engineer who would have to refactor the underlying code knows it's been bad for years, can't get the time from their manager to fix it properly, and would rather not be the one to crack the lid on it.
Each of those is a deeper post — incentives, discoverability, refactor politics. The structural fix and the people-and-process fix have to happen together. Audits without structural change produce relapse. Structural change without addressing why people picked duplication in the first place produces beautiful unused components.
What Component Structure Has to Carry
A well-structured component does more than render correctly. It communicates how it's supposed to be used, where it's supposed to be extended, and what it's supposed to forbid — and it communicates why each of those is true. The why matters more than the what. A designer who knows the dropdown forbids inline icon overrides because the alignment math falls apart on right-to-left languages will respect the constraint and propose a real solution. A designer who only knows that overrides are forbidden will route around the rule the first time they hit a deadline.
This is a much higher bar than "the component renders." It means the component has to expose intent — touch target sizes, state layer behavior, slot semantics, padding rules — in ways the designer can read at a glance and the engineer can implement from without ambiguity. The four-layer frame architecture that does some of this is a later post. And the deeper requirement, that the why of a decision needs to live somewhere durable and attached to the component itself, is what I've been calling connective documentation — also a later post. The short version: most orgs have their design decisions trapped in three people's heads and a thousand stale documents, and AI alone isn't going to fix that without a real structure to build on.
The component also has to live somewhere appropriate to its scope. A product-specific card pattern doesn't belong in the same file as the core button. A one-off layout for a specific feature doesn't belong in the shared library at all. Without scope discipline, every component drifts toward the same file, and the file becomes unusable.
Clear separation of concerns is the most underrated discipline in design system work. Nail the separation and most of the headaches above disappear. The frameworks for finding good separation are coming from a few interesting places lately — actor-network theory and object-oriented ontology both have something useful to say about where the meaningful boundaries between concerns actually live, and I think both are going to matter for how we structure design systems and the world models that AI systems are starting to need. Another post for another day.
And scope decisions — "should the button include a loading state, a dropdown trigger, a badge?" — need to be made on something better than the gut feel of whoever shows up to the meeting first. There's a scoring system I use for that. It's the next post.
The Series
This is the first post in a short series about preventing design system fracture. The next three go into the specific frameworks.
CFS — Commonality, Frequency, Severity. A three-axis scoring system for deciding what belongs in a component and what doesn't. One-to-five score on each axis, multiplied (not added) for a logarithmic total out of 125, and a conversation that has structure instead of vibes. It's the single tool that has prevented more variant proliferation on the teams I've worked with than any other.
The three-layer architecture. Core, application, and context layers — what goes where, how components migrate between layers as they mature, and why most teams end up dumping everything into one tier until the tier collapses.
Decomposition without forking. Sub-component patterns, the underscore-versus-angle-bracket naming convention that makes component boundaries readable, and the simple test for when to decompose and when to build inline.
After the frameworks, we build the actual button — the four-layer frame architecture, the icon-system composition, and the points where Figma's limitations push back on what the system wants to express.
The seventeen-dropdown problem isn't a discipline problem. It's a structure problem. Structure is fixable.
Top comments (0)