Defining a team structure with intention helps design leaders achieve their goals, scale their teams, and create great designs. Key factors to consider are the company’s goals and culture, the skills and roles required, and the different types of team structures available.
☕ Design team structures - defining how we work
How product designers and researchers should work in a larger organization is one of those questions that seems to cause a lot of headaches, especially for design leaders starting their first team.
Most often, structure is organic and reactive to problems, and doesn’t provide a good vision for future growth and proactively solving problems. Questions such as balancing collaboration needs and specialization, being scalable and adaptable, or making sure the design team setup is aligned with company strategy should have clear answers rooted in the structure.
Company leadership usually has some expectations on how things should be done, but designers should have a clear voice on what they need. Design leaders need to figure out what leads to high productivity and great design quality using the existing resources. With each structure (like embedded or agency style) some tradeoffs will define where the leader needs to focus and what practices the team adopts.
The best fit organizational setup should build on two foundations, the aspiration of creating great design and the context of the company’s goals and culture. Creating great design is self-explanatory, we as a discipline strive to make people’s lives better, and if the company is hiring us to do exactly that.
The company’s goals and strategy will set the overall context. It should give some ideas of what needs to be achieved, what sort of users team members will work with, and what products and services the team needs to work on. Maturity also plays a role here. Less mature products and organizations will have more general wear-many-hats sort of requirements for the design team. I include here also the detailed needs and asks from stakeholders and teams, for example, engineering might want designers to dabble in front-end code or learn more about users.
Based on the input gathered, the skills and roles required can be identified. Industry-wide there seems to be a consolidation towards having product design and UX researcher generalists, but there should be at least some elaboration on what sort of skills are needed. The type and number of roles might be constrained by budget, this would already define some priorities on what projects to focus on, and how the structure should adapt. Times are changing too, new requirements need to be evaluated. For example, UX writing is more important than ever as a role, but designers also have more AI tools around it.
All this work leads to defining a team structure. There are four common models: agency (one centralized design team), decentralized (designers report to non-design leaders per team), embedded (designers work in product teams and report to one manager), and matrix (designers work embedded but report to both a design and a team manager). Most teams would want to have a combination of these as they scale, for example, have product designers work embedded, but have a centralized design systems team.
When choosing a structure, there is always some trade-off to be considered. I favor the embedded model. It strengthens and empowers product teams with design energy. It gives the most ownership to designers. And it aligns well with the idea of the basic building block of product development being a product team. However, there are trade-offs with this model the design leader needs to prepare for.
Embedded requires designers to be able to stand on equal grounds with product managers and engineering leads and be great at both detail and journey-level design. This is very difficult for more junior members. Design leaders need to prepare for this with training and opportunities for people to grow. Also creating cohesion across a broader user journey in the product will be more difficult, the design leader needs to spend a lot of energy on practices around alignment, visioning, and coaching toward cohesion.
Structure and especially number of roles is often put in the terms of ratios, so how many designers do we want for x number of engineers or product managers. Ratios give a simple shortcut for scaling. For small teams, this makes sense. It’s easier to argue for having one designer per product team once that is established, and have the headcount added as the company scales.
As companies get larger, this will be less optimal, as it’s better to have a smaller and nimbler creative team. Smaller means better cohesion across the user journey’s design language and more aligned design teams. To make this happen, a lot of the things the design team does need to be automated, both on the tooling side (like with a design system or insight repository) and the culture side (like training or sharing practices). This enables the team to focus on high-impact activities, such as strategy and requires more sophisticated team structures, like the centralized partnership.
Scaling is still important, even without ratios. Most organizations will grow from their current scale, and the team structure needs to have some ideas for how the team will deal with growth at least in the medium term of 1-2 years. This includes new teams required to focus on specific tasks (like a design system team) or regular design reviews (to maintain a cohesive vision).
Team structure is not only an organizational chart of designers and researchers reporting to managers, it also describes how team members will collaborate and communicate with partners and how decisions will be made. The team structure is important, as in the sometimes underdefined messiness of product development having clarity of at least the roles, so who does what helps in removing some friction.
🥤 To recap
- Consider the company’s goals and culture. What are the company’s top priorities? What kind of products or services does it offer? What’s its culture like? These factors will play a role in determining the best design team structure for your company.
- Identify the skills and roles required. What skills and roles do you need on your team to achieve your goals? Consider the types of products or services you’re designing, the complexity of your projects, and your budget.
- Choose a team structure. There are four common team structures: agency, decentralized, embedded, and matrix. Each has its advantages and disadvantages.
- Scale your team structure as needed. As your company grows, you may need to adjust your team structure to accommodate new teams or new roles.
- Team structure is important for collaboration and communication. A clear team structure can help to reduce friction and improve collaboration and communication.
This is a post from my newsletter, 9am26, subscribe here:
🍪 Things to snack on
The Org Design for Design Orgs book by Peter Merholz and Kristin Skinner is the single best source on creating design orgs. The book also popularized the model of centralized partnership, where designers work in their teams, but in close collaboration with product teams, a hybrid between the agency and embedded models. Besides team setup, the book has a lot of good materials on things like role descriptions, hiring, and growth.
🁌
Peter Merholz also has a series of articles about design org setups, starting with The Emerging Shape of Design Orgs. These expand on the idea of a centralized partnership and describe how scaling design orgs would look like along with the roles and team compositions.
🁌
Company culture has a large impact on how the design team should work. In her talk, Designing how we design Kim Godwin describes how company types are expressed through their values, and how those values radiate through the company organization and product. The types are defined along the Internal-External focus and Dynamic-Stable axes. In an Adhocracy (dynamic-external), UXers need to be whiteboard ninjas. In a Clan (dynamic-internal), UXers should focus on involving everyone. In a Hierarchy (stable-internal), UXers will be valued as experts focused on repeatable processes. In a Market culture (stable-external), UXers need to be scientists working with data and looking for efficiency. The challenge is, that all of these types precisely need the thing they are averse to, this is where the design team can act as a change agent.
🁌
Christie Lenneville writes about how to get started with creating a design org in Designing a new UX team. While the first few hires might feel like “we need more of what the first designer has been doing”, it’s important to intentionally design the team, so hire for complementary skills. The article offers a simple tool for this, have a chart that describes current skill coverage and a vision of where the team needs to be.
🁌
Where Should UX Report? 3 Common Models for UX Teams and How to Choose Among Them by Kate Kaplan and Kara Pernice describes the three common models for designers, Central Team, Distributed, and Matrix with pros and cons.
🁌
A detailed argument for the embedded model by John Cuttler, Hire More Designers, OK?, is especially useful for early scaling. Companies going from one startup team to several product teams will drive early designers to work more upstream which creates distance from actual delivery and leads to plenty of problems around quality, planning, cohesion, and outcomes. As long as there are people shared between teams (for example designers splitting their time) the issues won’t go away.
🁌
While structure should have some high-level ideas on how designers and researchers work across the org, researchers commonly sit together in a UX research team. Becky White and Marianne Berkovich write about how these teams grow and what they do in each stage in The stages of growing a UX Research team. The four phases are Getting a UXR practice started, Growing a UXR practice, Accelerating a UXR practice, and Toward maturity. I’d argue that for the orgs that don’t need more researchers, the numbers would be compressed, and working toward maturity comes earlier. The article also has a bunch of good tips on what to focus on in terms of research work, operations, and hiring.
🁌
Golden Rules for Organizational Structure by Joshua Burgin is more focused on engineering orgs, but the ideas outlined here can be just as easily applied for a design org. Especially Spans and Layers are useful to understand as design teams scale up above 10+ people. Spans describe the responsibilities of managers and have some guidelines on how many reports should a manager have. Layers refer to hierarchical depth, and while a lot of organizations pride themselves in being flat, neither too much nor too little depth is right. The article has some more tips on organizational health, things like attrition, hiring, and general well-being.
Comments