How To Build A UX Team From Scratch
A practical guide on how to scale a design team, from hiring your first designer to establishing processes, systems and product teams. The only limits for tomorrow are the doubts we have today.
A while back I stumbled upon an honest, practical guide on how to scale a design team in a high-growth company, including a team’s evolution, roles, meetings, processes and systems. Kindly shared by Andrew Coyle.
Andrew raised a few useful points that I never thought of, and they I always try to consider when we need to grow the design team. Let’s see what they are — hopefully it will help you grow your design team, too.
First Steps: Scope The Design Work #
There is no universal blueprint for a team setup that works everywhere. Often we might think about a good foundation that every team needs, but it shouldn’t be defined by roles, but rather by the work that needs to be done.

Scaling a design team starts with defining the immediate challenges and hiring to solve them. Large view.
A good way to start is by listing all the design work that must be done, and figuring out what challenges you need to solve first. Your first hire ideally would be a person who is able to tackle that specific challenge well. From there, you can decide on the necessary design roles to cover the rest of the work well.
Hiring Strategy: Hire Slowly, People First #
When you start hiring, hire slowly. Choose the strengths that you want to see in your team — and the ones that are very much needed for the project. It requires identifying blindspots that need to be addressed — visual design, research, accessibility or anything-in-between.
For example, you might have a very poorly performing search that many people rely on daily. It would be wise to find a person who has a good understanding of IA, metadata, indexing and design around search UX.
It’s always incredibly valuable to hire with diversity in mind to get a wide range of perspectives. Always hire slowly, and hire for roles that you actually need. Once new members join, discuss and distribute responsibilities and ownership clearly.
Team Structure and Processes #
As the team grows, eventually you will need to establish the design team’s ways of working, including meetings, rituals, and 1:1s. Every new hire increases the need and the cost of communication. Building a set of shared design principles can help structure conversations and guide decisions.
It’s important to remember that every centralized team eventually hits its limitations. When that happens, you might need to break up the team by assigning product designers to specific product teams, but also put them together by setting up a design guild for ongoing collaboration.
Centralized UX Team #
In early days, most teams start with a centralized model where the entire UX team acts as a single, in-house agency working for existing product teams. UX team often spends a lot of time in discovery as it’s detached from a specific unit, and eventually they become a bottleneck.

In a centralized UX team, team members report to the same UX manager and are part of the same core team.
- Pro: Consistent, unified UX across products.
- Pro: Resources can be easily prioritized for key projects.
- Con: Eventually slows down product teams that are waiting for UX resources.
- Con: Designers lack specialized knowledge of any single product or domain.
- Con: UX teams can be detached from the practical realities and constraints of product teams.
Decentralized UX Team #
The decentralized model distributes designers across verticals, or product teams. There, designers are often integrated in existing product lifecycle and have deep understanding about the product and domain.

In decentralized UX teams, designers and researchers are embedded in multiple product teams throughout the organization.
- Pro: Designers gain deep product knowledge and work more closely to their teams.
- Pro: Designers have clear responsibility for the product they are working on, which eliminates UX bottlenecks.
- Con: Design often becomes inconsistent across verticals unless designers have an active design guild.
- Con: It becomes difficult to establish and enforce company-wide UX standards.
Matrix UX Team #
A matrix model is a combination of previous models where designers work in product teams but also report to a central UX lead. Often faces conflicting priorities from different teams and stakeholders.

In a Matrix UX team, designers are distributed across many product teams and report both to a centralized UX manager and an individual team lead.
- Pro: A design guild is a way of working, with designers frequently sharing best practices and design patterns.
- Con: Conflicting priorities drive designers in different directions.
- Con: Require alignment between product managers and UX lead.
- Con: Often needs high UX maturity in organization to work well.
There Is No “Right” UX Team Model #
As Kate Kaplan and Kara Pernice have noted, there is no single model that works best across different team setups. In small teams, designers are typically all over the place — decentralized. They don’t have a dedicated team, but are firefighters, resolving tickets as they occur. There aren’t enough design and research staff to support a decentralized model.
As the company grows, designers tend to move across verticals — centralized — at least having a specific team they are working with on a project-by-project basis. It also happens with in-house product teams as some realize that they need a first UX hire.
Eventually, as teams grow, many teams lean towards the matrix model, but often with various degree of attachment to product teams. Often they rotate between teams or move back and forth betwen decentralized and centralized models, depending on business pressure.
Quick Summary #
- Start by listing all design work that must be done.
- Figure out what challenges you need to solve first.
- First hire should be able to tackle that challenge.
- Decide on necessary design roles to cover it well.
- Choose strengths that you want to see in your team.
- E.g. visual/interaction design, research, accessibility.
- Hire slowly, and hire for roles that you actually need.
- Distribute and refine responsibilities and ownership.
- Design team’s ways of working, meetings, rituals, 1:1s.
- Every centralized team eventually hits its limitations.
- Break up: assign product designers to product teams.
- Put together: set up a design guild for collaboration.
Wrapping Up #
Among the many models and articles about the “perfect” team setup, personally, I absolutey love Andrew’s point about first hiring a UI engineer to bridge the gap between design and engineering. In many teams, that’s what usually causes friction, and having a dedicated person who understands both sides can help enormously.
Also, some teams seek established, first-class designers with a wide portfolio of big brands. But usually what they actually need are friendly, diverse folks who deeply care, are eager to learn, and are team players.
And: hire slowly, and for the roles that you actually need. If you give good people an opportunity and ownership for their work, you might be surprised just how quickly they will evolve in a new role, and move mountains for you and for your customers.
Useful Resources #
- How To Structure And Manage A UX Team, by Giada Gastaldello
- UX Team Models, by Kate Kaplan, Kara Pernice
- Figma Case Study, by Noah Levin
- Spotify Case Study, by Nicole Burrow
- Shopify Case Study, by Alaine Mackenzie
- How To Assemble A Winning UX Design Team, by Dovetail
Useful Books #
- The User Experience Team Of One, by Leah Buley, Joe Natoli
- Building and Managing In-House Design Teams, by Peter Merholz, Kristin Skinner
- How Top Design Leaders Build and Grow Successful Organizations, by Richard Banfield