Design LeadershipTeams

Your design team doesn't have a craft problem. It has a clarity problem.

When design quality feels low, the instinct is to level up the team. Mostly that's the wrong diagnosis.

The instinct when design quality dips is to address craft. More senior hires. More critiques. A typography workshop. Sometimes that's the right call. Mostly it isn't.

In my experience, the thing that looks like a craft problem is usually a clarity problem. Designers don't know what they're actually solving for. The brief was vague. The feedback was contradictory. Nobody ever defined what "good" looks like for this particular surface at this particular stage of the product.

When clarity breaks down, even strong designers produce mediocre work. Not because they can't do better, but because they have no reliable signal for what "better" means here.

The symptoms

A clarity problem tends to look like:

  • Designs that are technically competent but miss the point
  • Feedback that repeats across multiple reviews without the work improving
  • Designers presenting multiple directions on everything. Not because they're exploring, but because they don't know what the right direction is
  • Critiques that feel unproductive but nobody can say why
  • Senior designers reviewing junior work and flagging different things every time

None of these are craft failures. They're navigation failures. The team doesn't have a map.

What clarity actually requires

Clarity isn't just a good brief, though a good brief helps. It's a shared understanding of the problem, the constraints, the user, the definition of done, and who has authority to call it done. That last one is the one most teams skip.

You can have a detailed problem statement and still have ten people with equal authority to redirect the work mid-flight. The brief gets honored in kickoff and ignored in review.

Real clarity means the designer knows what they're optimizing for. Not "make it better," something specific. They know which constraints are real and which are just preferences. They know who has to be satisfied for this work to be done, and they know when exploration is appropriate and when it isn't.

The feedback loop is where it compounds

Most design quality problems live in the feedback loop, not in the initial work. Designs come back from review changed but not improved. The designer dutifully incorporates what was called out. Nobody is tracking whether the original intent survived.

Then it comes back again. More changes. Eventually something ships that satisfies every piece of stated feedback but doesn't actually work.

The root cause is almost always that reviewers didn't share a framework for what they were reviewing against. They reacted. The designer incorporated the reactions. The thing that was supposed to be true about the design got lost somewhere in the middle.

What I do about it

When I see this pattern, I start by working backwards from review. What question should this review answer? Not "what's wrong with this?" but "does this solve the problem we defined?" If nobody in the room can answer that question, it means the problem was never actually defined.

From there, I look at briefs. Most design briefs at most companies are not briefs. They're feature descriptions. They say what to build, not why, not for whom, and not how we'll know when it's right.

Then I look at whether the team has shared criteria for quality on that surface. "Is this polished?" is not a question with an answer unless you've agreed on what polished means here. Often it means "does this look like the thing in my head," which is not criteria. It's wishful thinking.

The fix is usually not a workshop. It's a hard conversation about how work gets defined and reviewed, who has authority to call things done, and what the actual standard is. That conversation is slower and less satisfying than a crit on typography. It's also the one that actually moves quality.


None of this means craft doesn't matter. It does. But craft problems respond to craft investments. Clarity problems don't. If your team's output isn't improving after hiring better people or running more critiques, stop and ask what everyone is actually optimizing toward. The answer is usually not what you'd hope.

Greg Sargent
Greg SargentDirector of Design Systems, Spring Health

I write about design systems, accessibility, and the way AI is changing how we build software.

Published October 21, 2025

Be the first to rate this article.