This Component Does Too Many Things
Design reviews are full of specific feedback. The button color is wrong. The spacing is off. This section feels heavy. The copy is too long.
All of that is true. None of it is the real problem.
The real problem — and the feedback almost no one gives — is simpler than any of those things: this component does too many things.
Not “it looks wrong.” Not “it’s inconsistent.” It’s doing work that should be distributed across several different components, and because it’s overloaded, every surface-level fix you apply will just create a new surface-level problem somewhere else.
You can fix the button color. You can adjust the spacing. You’ll be back in two weeks with different problems that look unrelated but aren’t.
Why nobody says it
It’s not that designers don’t see it. Most of the time they do. The hesitation is practical: saying “this component does too many things” is an invitation to a larger conversation about architecture, and most design reviews aren’t structured for that conversation.
So you say something more specific. Something fixable in the next sprint. And then you come back in two weeks.
This is the wrong tradeoff. A good design review isn’t just a list of what needs to change before launch — it’s a diagnostic. If the diagnosis is wrong, the treatment plan is just busywork.
What the feedback actually unlocks
When you name the overload, something useful happens: the designer — or you — has to figure out what the component is for. What’s its one job? What would it look like if it only did that?
You don’t have to refactor today. The question alone is productive. It tells you where complexity is accumulating, which surfaces are carrying work they weren’t designed for, and where the product is going to keep fighting you.
That’s the whole point of a review — not to produce a task list, but to develop a shared model of the problem.
What to listen for
A few patterns that usually mean a component is doing too much:
- It has exceptions. Every version comes with a footnote about when the rule doesn’t apply.
- Its name is a conjunction. “Save and Share.” “Upload or Continue.” The “and” is a sign.
- It means different things in different contexts. Same component, two completely different interpretations depending on where you’re standing.
Each of those is a symptom. The root cause is always the same: something with one job got assigned a second one, then a third, and at some point someone added a prop to handle the edge case and now nobody knows what the source of truth is.
“This component does too many things” isn’t a blocker. It’s a direction.
The best design feedback changes how you see the problem — not just the artifact in front of you. This one does that, every time, if anyone in the room is willing to say it.