The design team metrics that don't tell you what you think they do

Design teams have gotten better at tracking metrics over the last few years. The problem is that the metrics most teams track tell you about process, not outcomes. They feel like accountability without producing any.

Velocity is the most common offender. Number of designs shipped per sprint. Tickets closed. Story points completed by design. These are real numbers. What they measure is throughput, not quality or correctness. A team can ship every ticket on time and still produce work that confuses users, misses the product strategy, or has to be redesigned three months later.

Satisfaction scores are nearly as bad

CSAT and designer satisfaction surveys are useful for morale monitoring. They're not useful for evaluating whether the design function is working. A design team that's happy because they're well-resourced and not under pressure isn't necessarily producing better work than a team that's grinding.

NPS from design partners is a version of the same thing. If PMs and engineers are happy with design collaboration, it usually means the collaboration is smooth, not that the collaboration is producing better outcomes. A design team can be beloved by its partners and consistently produce work that doesn't solve real user problems.

The metric that correlates with good partnership isn't satisfaction. It's whether partners feel comfortable telling design when the work isn't right. That's harder to survey.

The proxy problem

The reason misleading metrics persist is that the right metrics are hard to get. What you actually want to measure is the quality of design decisions and their impact on product outcomes. That requires tracking decisions over time and connecting them to results. Most organizations don't have the instrumentation for that, so they substitute something measurable for something meaningful.

This is fine as a short-term compromise and becomes a problem when the substitution becomes permanent. Once a team is reporting velocity to leadership, the conversation shifts toward maintaining velocity, and quality concerns that slow down throughput start feeling like operational problems rather than the point of the work.

What's actually informative

The metrics I find most useful for understanding whether a design function is working tend to be more qualitative and more lagging.

How often does design work get substantially revised after it ships? Not iterations and improvements, but revisits because the original direction missed the mark. A team with a high rate of post-ship redesigns is telling you something about the quality of pre-ship decisions, even if their throughput looked fine.

How far upstream is design involved in decisions? If designers are consistently brought in after the product spec is written, they're executing on a direction that was set without them. If the intervention point is moving earlier over time, that's a signal the function is gaining traction.

How often do design decisions get overridden without explanation? Not overridden after a genuine debate where the design team's perspective was considered and weighed, but overridden by a PM or executive who felt like the decision was theirs to make. A team whose decisions frequently get overturned without explanation is a team that hasn't established its decision authority.

None of these are clean numbers. But they're more honest about whether the team is doing the work well, rather than whether the team is doing a lot of work.

The leadership failure that produces bad metrics

The reason teams track bad metrics is usually that leadership asked for metrics before there was a clear theory of what good design function looks like at this company. "Show me some numbers" gets answered with whatever is countable, and the countable things become the targets.

The more useful demand from leadership isn't "give me metrics." It's "explain how I'll know if this team is working." That question forces a conversation about what design is supposed to produce, which is the conversation that should happen before any numbers get picked.

If your current metrics wouldn't tell you about a design problem until it had been a problem for six months, you're measuring the wrong things.