Nielsen Norman Group ↗ names three different common setups for design teams. All with different strengths and weaknesses, but in my experience they share a similar vulnerability to erosion. I’ve seen it set in, systemic, structural, and often quiet. At its worst, design functions get capped before the work even begins, invited in to solve problems already locked in as delivery commitments.

It isn't a consequence of whether a team is centralised or decentralised, embedded or pooled. I believe what chips it away is behavioural, which happens when any design team operates without the right organisational conditions to do anything more than respond to requests. The structure merely creates a context. The behaviour is what fills it.

Some teams operating this way manage to drive tactical conversations, and even strategic ones. Relationships get built, trust accumulates, and a capable designer can punch above the conditions they're in. But it tends to be fragile. Without the right support protecting that positioning, the same setup can quietly devolve. And when it does, the job becomes a slog. Not because the work is hard, but because it stops feeling like it matters.

InVision's New Design Frontier ↗, a survey of 2,200 organisations, found that design team size is not predictive of maturity or business impact. The banking industry is their pointed example, with large UX teams yet consistently below average on design maturity. More designers, more tickets closed, more work shipped. But without positioning, none of it compounds into anything.

This is what I'd loosely call design as infrastructure. I don't think the idea is entirely new, I’m not surprised if similar thoughts are floating and converging across the industry. It essentially positions design not as something summoned when needed, but as something already present, load-bearing, before the first request arrives.

More than a structural choice, design as infrastructure is a posture. Embedded early enough and deeply enough that it becomes part of how the organisation thinks, not just what it produces.

This isn't purely a mindset argument. The patterns tend to show up in the numbers too.

InVision's New Design Frontier ↗ found that higher design benefits are consistently correlated with deeper involvement by people outside the design organisation. The teams doing the best design work, it seems, have made design everyone's concern rather than just the designers'. Only 5% of the 2,200 organisations surveyed reached the highest level of design maturity. At that level, design had become core to business strategy, touching valuation, long-term vision, and cross-platform systems thinking, well beyond screen execution.

McKinsey's five-year study ↗ of 300 publicly listed companies found that organisations with advanced design practices grew profits roughly 2.5 times faster than their peers. The common thread, from what the research suggests, was design integrated upstream, in strategy, in research, in how product direction gets set, rather than design dispatched to fulfil requirements after the fact.

The infrastructure model is, I think, how that kind of integration tends to happen.

This shift doesn't happen through good intentions alone. From what I've seen, two things tend to matter more than anything else.

1. The first is air cover. The centralised model isn't problematic by design, but it does appear vulnerable by default. Without leaders who actively protect design's positioning, who resist the pull to collapse it back into a delivery queue when timelines tighten, the infrastructure model tends not to hold. The service model sits waiting as the path of least resistance, and under pressure, organisations often revert to it faster than anyone expects.
2. The second is earned trust from adjacent functions. Engineering and the functions that set priorities don't naturally cede ground. Getting there tends to require demonstrating repeatedly, that design's involvement makes their work better, not just that it exists. Technical fluency helps here. So does genuine curiosity about the constraints others operate under, including the organisational and commercial priorities that shape what gets decided before design is ever in the room. Borrowed authority has a shelf life. The kind that comes from engineering trusting your technical read, or stakeholders who've seen design shape a direction rather than react to one tends to stick around longer.

Neither condition is guaranteed and I won't pretend my thinking here is fully formed. In my observation and from personal experience, the teams that have managed to turn it around usually had one thing in common. Someone who refused to wait for the brief.