Every time we plan a team structure or take on a new design project, we face the same question: should designers work alone, or alongside other designers?

There are good reference points out there — Spotify's take on building design teams and Superside's breakdown of design team structures are worth reading. But most of what I've seen written on this comes from large organizations in the US or Europe.

This article draws from my own experience and conversations with design leaders and practitioners across Latin America, with a focus on experience design, interfaces, and digital products. Take it as a reference — not a universal rule.

How can designers work with other designers?

Based on my experience, there are three main configurations for how design teams participate in a product or development environment:

  1. Solo designer
  2. Pairs
  3. Trios or squads

1. Solo designer — "you against the world"

You've probably been on a team where you were the only person dedicated to experience or interface design — whether at a small company, as the lone designer embedded in a multidisciplinary squad, or on your own freelance project.

The solo designer works for freelance projects. But in complex product environments, carrying the full load alone is hard. I'm not saying it can't be done — only that it tends to take longer, that specialized areas like content design get less attention, and that you lose the friction and richness that comes from design debate.

There are also cases where a single designer makes sense: short-scope projects, or work with very well-defined tasks. Even in teams with Product Designers owning end-to-end work, they still need specialist support for interaction, information architecture, and content.

2. Pairs

"Two heads think better than one." Assigning two designers or specialists to analyze a solution, run a research study, or build a prototype gives you several advantages:

  • Better-executed activities — in user interviews, one person leads and asks questions while the other takes notes
  • Richer analysis — two different points of view and different backgrounds means more surface covered
  • Design challenged from the start — during build and prototyping, both people push back on each other's decisions
  • More speed — once everything is defined, both designers can split tasks and move faster in parallel
  • Keep one owner — for each project, one member of the pair should be the designated point of accountability; this keeps the process clean

3. Trios or squads

Less common are projects where three or more designers attack the same stages simultaneously. Some leaders turn to this configuration for urgent or high-priority work. The challenges and tradeoffs:

  • Requires serious synchronization — too many hands on one project can produce confusion, duplicated effort, and communication problems; you need clear organization and strong leadership
  • Effort leakage is real — when there are many contributors, it's easy for some members to carry most of the weight while others contribute less, whether due to speed, seniority, or how the work gets divided
  • Lower project ownership — the more people share a role or effort, the less any individual tends to feel committed to or empowered by the outcome

The honest answer: it depends

I know that's not what you wanted to hear. But it genuinely depends on two main factors: the state of the project and its scope.

Projects have convergent and divergent phases:

In convergent phases — where you're working toward a specific, objective result (analysis, prototyping, delivery) — a single person can handle the tasks needed to get there.

In divergent phases — where the priority is exploring multiple paths to solve a problem — company is recommended. This is where "two heads think better than one" actually applies.

And finally: you probably need different types of specialists to build something of real quality. Content designers, information architects, interaction designers, visual designers, researchers. It's very hard for one person to do all of that well, in the time you're expecting it.

Practical advice for working in teams

Create space for feedback and discussion

It doesn't matter whether your designers work in pairs, solo alongside developers, or embedded in squads — interacting with other designers is valuable. Build regular Review and Critique sessions into the rhythm. It helps people feel supported and more confident in their day-to-day work.

Group with diversity in mind

Whatever configuration you use — pairs, trios, squads — think about balancing both technical skills and soft skills. The easy version is a junior with a senior. But you can also look for potential leaders, strong communicators, or people who need a boost in motivation.

Shuffle things around periodically

Once you have a configuration, don't let it calcify. Change groupings every quarter or semester, or assign side projects with people who haven't worked together before. This matters so that everyone gets to know each other over time and can face bigger challenges as a real team.

Listen actively and measure everything

Pay attention to how pairs are progressing. Comparisons are uncomfortable — but they help you understand why group X is producing better results than group Y.

This article incorporates perspectives from designers across Latin America: Danelly Sotomayor (UXUI Lead, Kushki), Andrés Garrigós (UXUI Senior, Kushki), Miguel Rivas (Design Lead, EVA-NOVA), and Alva Echazú (Lead of UX, Paisanos).

Further reading: