Two companies hire the same number of designers and get opposite results. In one, the designers sit together, set a high bar, and ship a product that feels like one product. In the other, they're scattered across squads, each solving the same problem a little differently, and the experience comes out lumpy. The difference usually isn't talent. It's the operating model, where design reports, how its work flows, and whether anyone measures what it's worth.

The quick version

  • Two basic shapes. Centralised keeps designers in one team for consistency and craft; embedded puts them inside product squads for speed and context. Most mature orgs land on a hybrid that tries to get both.
  • Design grows up in stages. Maturity ladders run from "design is what happens on the screen" to "design sets strategy." Knowing your rung tells you which problem to fix next.
  • Most teams skip the plumbing. In one large survey, organisations had only about a fifth of recommended design-operations practices in place, the unglamorous coordination work that lets designers actually design.
  • Measure outcomes, not output. The strongest evidence links design to revenue and shareholder return when leaders track it with the same rigour as cost, not by counting screens shipped.

The idea in depth

"Operating model" sounds like jargon, but it's a concrete set of choices: who designers report to, how they're assigned to work, what standards they share, and how their impact is judged. Get those right and design compounds. Get them wrong and you pay for talented people who can't land their best work.

Centralised, embedded, or hybrid, pick your trade-off

Nielsen Norman Group, which runs one of the longest-standing surveys of design teams, describes three recurring structures. In a centralised team, designers sit together and report to a design manager, then get loaned to projects. In a decentralised (embedded) team, designers live inside cross-functional product squads, aligned to a feature or line of business. A hybrid (matrix) structure tries to combine the two, a designer answers to both a product lead day-to-day and a design leader for craft and growth. NN/g reports the three models split roughly a third each across the teams it surveys, which is a useful reality check: there is no single "right" answer the best companies have all converged on (Nielsen Norman Group, "Where Should UX Report? 3 Common Models for UX Teams").

Each shape buys you something and costs you something. Centralised teams protect quality and a shared craft, but can drift away from the product and feel like an order-taking service. Embedded teams get deep context and move fast, but fragment, five squads quietly invent five different date pickers, and individual designers lose the mentor and the community that a central team provides. The hybrid fixes both in theory and, in practice, can leave a designer with two bosses and a confusing set of priorities.

So pick the model that defends your current biggest weakness, not the one that sounds most modern. If your product feels inconsistent and junior designers are isolated, pull toward centralised. If design is slow and disconnected from customers, push toward embedded. NN/g's more recent writing argues for a managed middle, designers embedded in product teams for the work, but reporting to design leadership for standards and growth, precisely because it targets the failure mode of each pure model (NN/g, "Managed-UX Integration").

flowchart TB
    Q(["Where does your design hurt most?"])
    Q --> C(["Inconsistent product, isolated designers → lean centralised"])
    Q --> E(["Slow, far from customers → lean embedded"])
    Q --> H(["Both at once → hybrid: embed for work, report to design for craft"])
Choose the model that fixes your current weakness, not the trendiest box. Leaders Loop

An honest limitation: these are tendencies, not laws. Every model has teams that thrive and teams that struggle. Structure sets the odds; leadership, hiring and the day-to-day rituals decide the outcome. Reorganising the boxes without changing how people work together just moves the problem.

The maturity ladder: know which rung you're on

Operating models don't sit still, a design team grows up. The most widely cited map of that growth is InVision's design maturity research, led by Leah Buley and published as The New Design Frontier (2019), drawing on a survey of more than 2,200 organisations across dozens of countries. It sorts companies into five levels, from Producers (level 1, where "design is what happens on the screen") through Connectors, Architects and Scientists up to Visionaries (level 5, where design helps set business strategy). The headline finding is sobering: only about 5% of organisations reached the top level, and a large share were stuck near the bottom. (InVision has since shut down and the original report page no longer resolves, so it's worth knowing the study by name rather than by link.)

The ladder is useful because it sequences your problems. A Producer-stage team doesn't need a measurement dashboard; it needs design involved before the spec is frozen. An Architect-stage team, design treated as a shared responsibility across the product cycle, is usually the point where a design system starts to pay for itself, because there's finally enough shared work to make reuse worthwhile.

Maturity isn't about better screens. It's about how early design is allowed in the room.

The practical move: place your team honestly, then fix the next rung rather than leaping to the top. Ask at what point in a typical project design actually gets involved. If the answer is "after the requirements are signed off," you're nearer the bottom than you think, and the fix is a process change, not a hiring spree.

Worth a caveat: maturity models lean on self-reported data, and a vendor's survey of its own users is prone to selection bias. Treat the levels as a shared vocabulary for a conversation, "are we Architects yet, and what would Scientist-level look like?", rather than as a precise score. The independent point survives the caveat: design earns more influence the earlier it's invited in.

The plumbing problem: design operations

Whatever the shape, a growing design team runs on coordination work most leaders never see, assigning people to projects, maintaining the design system, running research consistently, onboarding, and measuring quality. This is design operations (DesignOps), and the evidence says it's badly under-built. In a 2020 NN/g survey of 557 design and UX practitioners, organisations had on average just 7.5 of 34 recommended DesignOps practices in place, about 22%, and only one in five had anyone in a dedicated DesignOps role (NN/g, "DesignOps Maturity Is Low in Most Organizations," 2020).

Treat coordination as real work with a real owner, then, even before you can justify a dedicated hire. The weakest areas in that survey were career paths and measurement, which points to two cheap, high-impact starts: a documented progression for your designers, and one agreed way to judge the quality of what ships. You don't need a DesignOps team to do either. You need someone accountable for them.

A worked example

Picture a 40-person product company, call it a fictional B2B software firm, with six designers. (Figures below are illustrative.) For two years they ran centralised: all six reported to a design lead and were assigned to projects as work came in. The product looked coherent, but engineering complained that design was a bottleneck and always arrived late, after the technical decisions were made. The team was, in maturity terms, stuck around the Connector level, a real design process, but bolted on after the important calls.

The leadership team's first instinct was to go fully embedded, one designer per squad. They held off, seeing the obvious risk: six squads quietly diverging, and their two juniors marooned without a mentor. Instead they went hybrid. Each designer embedded in a squad and joined planning from the first conversation, while still reporting to the design lead, who held a weekly craft critique and owned the shared component library.

Two things changed within a quarter (again, illustrative). Design entered projects at the idea stage instead of the build stage, the maturity jump that matters. And because the lead still owned standards, the product didn't fragment into six dialects. The unsung enabler was a small DesignOps habit: one person made the design system the default starting point. The reorganisation grabbed the headlines; the plumbing made it stick.

flowchart LR
    A(["Centralised: consistent but late, design as a service"])
    A --> B(["Risk spotted: fully embedded would fragment + isolate juniors"])
    B --> C(["Hybrid: embed in squads, report to design lead"])
    C --> D(["Design enters at idea stage"])
    C --> E(["Shared system stops drift"])
The illustrative firm's path: structure plus the operational plumbing that made it hold. Leaders Loop

Frequently asked questions

Centralised or embedded, which is better?

Neither, in the abstract. NN/g's surveys find roughly a third of teams in each model, with no single winner. Centralised protects consistency and craft; embedded buys speed and customer context. Choose the one that fixes your current biggest weakness, and expect to drift toward a hybrid as you grow.

How do I measure design's value without just counting screens?

Tie design to outcomes you already track, conversion, retention, support tickets, task success in usability tests, time-to-ship, rather than output like number of mockups. McKinsey's Business Value of Design study (2018) found the companies that pulled ahead were the ones measuring design with the same rigour as cost and revenue, not the ones producing the most artefacts.

What's the single strongest stat for design's worth?

McKinsey tracked 300 listed companies over five years and built a Design Index from more than 100,000 design actions. Top-quartile scorers outgrew industry peers by roughly 32 percentage points on revenue and 56 on total shareholder return across the period. It's a correlation, not proof of cause, but it held across medical tech, consumer goods and retail banking, a useful number to open a budget conversation, not to end one.

Do I need a DesignOps person?

Eventually, probably; immediately, no. Most organisations have only about a fifth of recommended DesignOps practices in place and no dedicated role. Start by naming an owner for the two weakest links the research flags, career progression and a shared way to judge quality, before you write a job description.

We reorganised and nothing improved. Why?

Because structure sets the odds, not the result. Moving boxes on a chart without changing when design gets involved, what standards it shares, and how its impact is judged just relocates the same dysfunction. The operating model is the rituals and the reporting together, not the diagram alone.

Related in the Toolkit

Where to go next