What a design maturity model actually tells you

Design maturity models map an organization onto a curve. At one end, design is a service function that produces deliverables when asked. At the other end, design is a strategic partner that shapes product direction. The implication is that you want to be at the far end.

I've worked with organizations across that curve. The far end isn't always the right answer, and the position on the curve tells you less than the chart suggests.

What the model actually measures

A maturity model is measuring something specific: how much authority design has in product decisions. That's a useful thing to know. It tells you whether the design team is being given problems to solve or specifications to execute. It tells you whether decisions are being made with design input or in spite of it.

What it doesn't measure is the quality of the design work. A team can produce excellent craft inside a low-maturity organization because someone protected them from the process. A team can produce mediocre work in a high-maturity organization because their seat at the table doesn't compensate for weak fundamentals.

When leaders cite maturity model position as evidence of design effectiveness, they're conflating two different things. Authority is necessary for design to influence outcomes. It's not sufficient for design to do good work.

When low maturity is actually fine

There are companies where design is downstream of product, executes against specs, and produces work that is genuinely good. This is supposed to be impossible according to the maturity literature, but it happens regularly.

The pattern looks like this: product managers who deeply understand the problem space, write clear briefs, and trust the design team to handle the execution. Designers who are skilled at their craft and don't need strategic involvement to do their best work. A culture where the separation is intentional, not accidental.

This is a low-maturity setup by the conventional definition. It also works, sometimes better than the alternative. Forcing this kind of organization to "mature" can make things worse by introducing strategic involvement that nobody has the skills or time to do well.

When the curve actually matters

The curve becomes useful when the work being asked of design exceeds what a low-maturity setup can support. If product is making strategic decisions design needs to inform, but design only gets involved at the spec stage, the work will suffer. The mismatch between what's needed and what the structure supports is the real signal.

Maturity isn't a goal in itself. It's a measure of fit between the structure and the work. The right question isn't "where are we on the curve" but "is the position we're at producing the work we need."

For some teams, the answer is yes and the curve doesn't apply. For others, the answer is no, and moving along the curve is the answer. The chart doesn't distinguish between these cases.

The pitch problem

Maturity models exist partly to give design leaders a tool for pitching investment. "We're stuck at level two and we need to get to level four" is a clean story for an executive.

The trouble is that it's also a story executives have heard from other functions, and the design version of it tends to suffer in comparison. Marketing and finance maturity models point at measurable outcomes. The design version tends to point at influence and seat-at-the-table arguments that are harder to evaluate.

If you're going to use a maturity model to pitch investment, pair it with the specific outcomes that better maturity would unlock. "We could ship faster," "we could catch problems before they reach engineering," "we could stop reworking the same flows" are more useful framings than "we could be more strategic."

What to use it for

The honest use of a maturity model is internal diagnosis. Where is design currently positioned, what does that position support, and what does it prevent. That diagnosis can inform conversations about what to change and what to leave alone.

What it can't do is serve as a goal. The goal is the work. What gets built, how it performs, what customers experience. Maturity is one input into that, not the output.