The case for a small, generalist design team over a large specialist one

At some point in a design org's growth, someone makes the case for specialization. You hire a dedicated researcher. Then a content designer. Then a motion designer. Then someone whose title is "design systems engineer." The reasoning is sound: depth of expertise produces better outcomes in each domain.

This is often true. It's also a more expensive model than it looks, and the costs accumulate in ways that don't show up in a headcount spreadsheet.

What you trade away when you specialize

A generalist designer on a product team is responsible for understanding the whole problem. They research it, conceptualize it, detail it, write copy for it, and follow it through implementation. When something doesn't fit, they find out. Their mental model of the work is complete in a way that's unusual in specialized teams.

In a specialized model, the same work is handed between people at different phases. The researcher produces findings. The UX designer produces flows. The content designer writes the labels. The interaction designer details the micro-interactions. Each handoff is a compression: something is always lost in the translation from one person's model of the problem to another's. The researcher's understanding of what users meant doesn't transfer completely to the UX designer. The UX designer's intent doesn't transfer completely to the content designer.

The output can be very good. The process is also slower and more fragile than it looks from the outside. When a project is under pressure, the handoff is the first thing to collapse. The researcher's findings get shared in a doc nobody reads, the UX designer makes assumptions, the content designer writes copy against flows that have already changed.

The coordination tax

Large specialist design teams spend a significant amount of their time coordinating with each other. This isn't a management failure. It's the structure.

When a product team needs design support, they're not managing a relationship with one designer. They're managing a relationship with a researcher, a UX designer, a content designer, and whichever specialists are relevant to the feature. Each of those people has their own schedule, their own queue, their own sense of priority. The product team learns to treat design as a service function to manage around rather than a collaborator to work with.

Small generalist teams don't have this problem. You work with a designer. They know the problem, they have context, they can make a call. The coordination cost is near zero.

Where specialization genuinely wins

This isn't an argument that specialization is always wrong. Research is the obvious case where a specialist produces something categorically better than a generalist. A dedicated researcher who spends their time on research methodology, recruiting, synthesis, and longitudinal work will produce findings that a designer who researches occasionally won't. There's a depth of craft that comes only from doing one thing repeatedly.

Content design is similar in specific contexts. Products with high language complexity (healthcare, legal, financial) where the words matter as much as the structure benefit from someone who thinks about content full-time.

Design systems work is another case. A design systems engineer who sits at the boundary between design and engineering and understands both deeply produces infrastructure that a generalist would not.

The difference is that these roles should be small teams of deep specialists supporting generalists, not a model where generalists are replaced by specialists. A researcher supporting a team of generalists is a multiplier. A model where every project goes through a researcher and a UX designer and a content designer is a different organizational choice with different costs.

The headcount math

Growing a specialized design team is expensive in ways that don't show up immediately. Each new specialist requires a manager who understands their specialty. Each specialty creates a new queue that the product team has to manage. And as the team grows, the proportion of designer-to-product-team-member shifts. There are more designers, but the work isn't proportionally better.

A team of six generalists, each owning two to three product areas, produces a lot of coverage. A team of six specialists (two researchers, two UX designers, one content designer, one design systems contributor) produces considerably less coverage of the actual product surface because so much of the time goes to coordination and handoff.

If you're staffing a design team and trying to decide which to build, the honest version of the question is: what are the specific design problems that can't be solved by generalists, and are those problems important enough to pay the coordination cost of specialization. For most product teams at most companies, the answer is closer to "no" than the job posting templates would suggest.

The culture difference

Generalist teams have a different culture than specialist ones, and the difference goes beyond structure. When designers own the whole problem, they develop accountability for the outcome rather than just the phase they worked on. They don't hand the problem off. They follow it.

That accountability produces a certain kind of engagement that's genuinely hard to maintain in a specialized model. When your job is research, the research is your deliverable and what happens after that is someone else's problem. When your job is the product, the product is your deliverable and research is one of the things you do to get there.

Most of the designers I've most wanted to work with were generalists by temperament even when working in specialized roles. The question isn't which model produces the best specialists. It's which model produces the best outcomes for the products they're building.