In the previous article, I argued that before hiring designers, a business needs to understand how it competes. A Prospector needs Design to create different value than a Defender does. So the right capabilities and kinds of designer differ too.
But knowing what kind of designer you need is still not enough.
In reality, businesses don't always have the budget to hire exactly who they want. A startup may know it needs a Product Creator but can't yet afford someone very experienced. A growing company may know it needs Specialists, but the product isn't big enough to hire one for every discipline.
So building a Design Team isn't simply the question:
“Which designer do I need?”
But rather:
“Given our strategy, resources and current stage, which capabilities should I combine to create the most effective team?”
I also want to be clear from the start: if Design isn't a capability that creates a significant competitive advantage for the business, or the business doesn't want to invest in Design accordingly, there's no need to force a large Design Team. Nothing wrong with that.
But once Design is identified as an important capability, the business needs to start thinking about a team, rather than about individual designers.
From strategy to team
In Part 2, we looked at businesses and designers through these frameworks:
- Business strategy: Prospector (Exploration), Analyzer (Balance), Defender (Optimisation & Stability), Reactor (Reaction).
- Designer Archetypes: Artist (Aesthetics & Exploration), Product Creator (Logic & Exploration), Craft Designer (Aesthetics & Standardisation), Systems Designer (Logic & Standardisation).
Put the two together and the core capabilities take shape:
- Prospector: Needs a lot of exploration → Product Creators and Artists create the most value.
- Analyzer: Needs both exploration and optimisation → Product Creator, Craft and Systems can coexist.
- Defender: Needs stability, efficiency and scale → Craft and Systems are core.
- Reactor: Very hard to build an optimal Design Team because the strategy is unclear; Design mostly handles short-term issues.
This model isn't a rigid hiring formula. It just helps answer the first question: which capability is the team missing?
Before building the team, understand your “ingredients”
If strategy tells you what “dish” you want to cook, the chef also needs to know what ingredients are in the kitchen.
After many years of hiring and sitting on graduation juries at several design schools, I've noticed that the design talent pool is fairly clearly segmented.
Segmented by education
- Visual Design leaning: Students from Graphic Design, Visual Design, Illustration, Art... are outstanding at imagery, colour, typography and visual language. A good source for Artist or Visual Designer roles.
- Product Design leaning: Students trained in UX, UI, Interaction, User Flow... are familiar with digital product problems and suit Product Creator or Digital Product Designer roles.
- Exploratory thinking vs. tool skills: Some schools encourage exploration — strong on thinking but weaker on early execution; others train close to the tools, so students can work straight away but risk being limited by an approach that leans too much on tools.
Background only tells us what a candidate has been exposed to. Real capability is what you hire for.
Segmented by work environment
The work environment also shapes how a designer's capabilities develop. In many outsourcing companies, designers work across many domains, clients and types of problems, which builds breadth and a Generalist mindset. In many product companies, by contrast, designers stay with one product for a long time, digging deep into users, data and systems, which builds specialist depth.
This is a tendency, not a rule. There are excellent Generalists in product companies, especially startups and small teams. And many outsourcing companies have very deep Specialists in areas such as UX Research, Accessibility or Design Systems.
What matters is not where a designer comes from, but which capabilities that environment helped them develop.
Understanding the talent landscape helps a business decide whether to: source candidates from particular schools, hire existing capabilities, look for versatile Generalists, hire Specialists to fill gaps, or invest in training Juniors long term.
Generalist or Specialist?
This isn't a question of whether the company is big or small. It's about the complexity of the product and the kind of problems the team is solving.
- The newer the product → the more breadth it needs: Early on there are many unknowns about the User, the Product and the Business Model. A Generalist can move across many kinds of problems and work directly with Product & Engineering to experiment quickly and reduce handoffs.
- The more complex the product → the more depth it needs: As the product matures, areas like UX Research, UI, Motion, Content and other disciplines may require depth that one Generalist can't cover at once. This is when Specialists start creating more value.
Junior or Senior?
If Generalist / Specialist represents Breadth vs. Depth, then Junior / Senior represents Experience, Autonomy and the Complexity of problems someone can take on.
- Don't use a Junior to replace a capability the business doesn't have yet: Hiring a Junior when no one is setting the Design direction, then expecting them to solve strategic problems, is a false economy.
- Seniors create capability now: They bring the ability to frame problems, balance User - Business - Tech, make decisions with incomplete information and lead the team.
- Juniors are future capability: They aren't a cheaper version of a Senior. A Junior is a long-term investment that builds culture and deep product understanding.
Investing in Juniors only really makes sense when the organisation already has someone able to guide and develop them.
A good team is not a collection of the best individuals
A team of 3 designers who are very strong visually will produce a beautiful product, but may lack someone for systems or research. A team of only Generalists has good coverage but may lack specialist depth. A team of only Specialists can be very strong in each capability but struggle with ambiguous problems.
A business doesn't need to hire a collection of the best designers. It needs to build: a set of designers whose capabilities complement each other.
How the team evolves by stage
1. 1 Designer: Prioritise a Product Generalist who can work end-to-end.
2. 2–4 Designers: Increase skill diversity by adding the missing capabilities, for example:
Product Generalist + Visual/Craft
or:
UX-oriented + UI-oriented
3. Larger team: Specialists appear once workload and complexity are big enough — UXR, UI, Design System, Content Strategist, Service Designer... along with middle management such as Lead, Manager or Head. Still, a bigger team doesn't have to mean more titles.
A capability should only become its own role when it is important enough, complex enough and has enough workload to justify investing in skill depth. Or, when it needs coordination, strategic product vision and people management, management roles can be considered.
Building a team is a question of fit
Building a Design Team is a coherent chain of decisions: start from business Strategy — what strategy is the business competing with? Then choose a Design Team that fits that business's own strategy, product, resources and stage of growth.
Conclusion
Building a Design Team shouldn't start with the question: “How many more people do we need to hire?” It should start with: “What capability is the current team missing to help the business take the next step?” That's when Design starts to be seen as a system of capabilities, rather than a list of headcount.
But building the team is only the first step. When a business develops many products with many teams working in parallel, another question appears:
How do you turn each designer's capability into a shared capability of the whole organisation?
When should you choose a Centralized, Embedded or Centralized Partnership model? When does Design need to be organised as an independent function? And when do capabilities such as Design Systems, Accessibility, Service Design or Design Operations start helping the organisation scale more effectively?
That will be the subject of Part 4 – When Should Design Start to Scale?
