The Signals That Tell You Design Is Working

I keep thinking about a question that comes up in almost every conversation I have with design leaders.

How do you know it is working?

Not whether the screens are shipping. Not whether the sprint is full. Whether design is actually changing the trajectory of the product.

Most design leaders can feel the difference between a team where design is working and one where it is not. But when it is time to explain that difference — to an executive, a product partner, or a new hire — the words do not come easily. They reach for metrics. Reach. Satisfaction. NPS. Those are useful. They also arrive late. They tell you what happened, not whether the operating model is sound.

The signals that tell you design is working show up before the data does. You just have to know where to look.

The Output Trap

I have been on teams where design was clearly working. The work felt different. Conversations moved differently. Decisions resolved faster. I have also been on teams where everything looked fine on paper — the deliverables were on time, the research was thorough, the screens were polished — and yet design was not actually shaping what got built. It was decorating decisions made elsewhere.

The difference was never in the output volume or quality. It was in the patterns of interaction.

When the product manager pauses a planning conversation to ask, "What do you think?" — not as a courtesy, but because the decision genuinely needs the design perspective — that is a signal.

When engineering comes to design before the architecture is locked, not to confirm a choice already made, but to understand the intent so they can build something better — that is a signal.

When a tradeoff discussion includes design without anyone explicitly inviting them, because the team naturally considers design input part of the equation — that is the strongest signal of all.

Those moments are hard to put in a dashboard. They are also more revealing than any satisfaction score.

Three Categories of Signal

I keep landing on three categories that tell me whether design is working inside a product team. Each is observable. Each shows up before the quarterly numbers confirm it.

Decision quality

The most important signal is whether the team makes better decisions with design than without it.

This is hard to measure in aggregate but easy to observe in specific moments. Is the team catching edge cases earlier because design surfaced them before engineering hit them? Are technical decisions being made with awareness of the user impact, or does that get added later as a constraint? Are scope conversations informed by what matters to the experience, not just what is easiest to build?

A team where design shifts decision quality does not need design to defend its existence. The people around them see the difference.

I wrote about the behaviors that create this signal in The Leader Point. Reducing ambiguity before it becomes a blocker. Naming tradeoffs before they become emergencies. Making reasoning visible so the team can move without the designer in the room. These are the practices. Decision quality is the result.

Friction reduction

The second signal is whether design makes the rest of the team faster. Not by producing more screens, but by removing the questions that slow people down.

This sounds counterintuitive because design is often seen as the function that adds work. More screens to build. More states to handle. More edge cases to test. But design that is working well does not just add requirements. It removes ambiguity. It answers questions before they are asked. It gives the team enough confidence to move forward without waiting for the designer to be in the room.

The best test I know: can product and engineering make progress on a feature while the designer is unavailable? If the team stalls, the operating model is still centered on the artifact — the team needs the designer's output to proceed. If the team can keep moving with confidence, the operating model is centered on shared understanding. The designer built durable alignment, not just polished files.

I covered the cost of the alternative in The Burnout System. When handoff churn masquerades as collaboration and every decision requires reconstruction, the team burns energy maintaining alignment instead of doing the work. Friction reduction is the cure.

Learning velocity

The third signal is whether the team learns faster with design than without it.

Research findings that change the roadmap. Usability tests that redirect implementation before it goes too far. Competitive analysis that reframes the opportunity. These are the outputs of a healthy design function. The real signal is whether those insights actually reach the people making decisions — and whether they change what happens next.

I have seen teams run extensive research and then proceed as if nothing had been learned. The information existed. It just did not travel far enough. The research report was thorough. The decisions were already made. The gap was not in the quality of learning. It was in the velocity — how fast insights turned into different behavior.

Learning velocity is a function of the operating model, not the research team. It depends on whether product and engineering trust the findings enough to act, whether the timing aligns with when decisions are actually made, and whether the insights are framed in terms the team can use.

The Hardest Part

None of these signals are clean numbers. They are qualitative. They require paying attention to how the team interacts, not just what it produces.

That is the hardest part for design leaders who are asked to justify their team's existence with data. The request is understandable. Dependencies, throughput, and satisfaction are real dimensions of the work. They are also lagging indicators. They tell you what already happened.

The signals in front of them — decision quality, friction reduction, learning velocity — are leading indicators. They tell you whether the operating model is working before the quarterly report arrives.

I think the most useful thing a design leader can do is not find a better metric. It is to watch for the right patterns. Let the conversations show you whether design is working. Let the speed of the team tell you. Let the quality of the decisions the team makes without you confirm it.

If you watch for these signals, you will know long before the dashboard catches up.

The Bottom Line

Design is working when the team makes better decisions, moves faster with less friction, and learns more quickly than it would without design. Those three outcomes are the measure.

Not the number of screens. Not the NPS score. Not whether design has a seat at the table in name. Whether the team is better because design is in the room.

That is the only signal that matters.