Where Should UX Report? 3 Common Models for UX Teams and How to Choose Among Them

Designing a UX-Team Structure is Difficult

Establishing an organizational model that enables effective collaboration and partnership — for UX design or any other discipline — is not easy. Team structure is always evolving: Newly added team members, newly developed products and features, and lessons learned over time about how teams best communicate can cause team structure to break.

It is especially difficult to determine an effective UX-team structure because UX is often added after other disciplines, such as development and product management, have already been established at the organization. Also, development processes don’t always include UX activities in their models.

UX teams are structured according to three common models that largely accommodate these organizational pressures. In this article we discuss the benefits and drawbacks of each, so organizations can assess and compare them to determine the most appropriate model for creating alignment and oversight for their UX staff.

UX professionals usually report to a:

• centralized UX team
• product team
• hybrid of these

Each of these models have clear benefits and drawbacks. Even though a team’s structure may follow one of these common models, we shouldn’t expect it to be immutable, rigid, or perfect. Revision is a necessity: A model that worked at one point in time for an organization will likely become obsolete under new and different pressures. Rather, these models are general approaches that should be applied and adapted as organizations learn what works best for their evolving context.

Centralized UX Team

In a centralized team, all UX team members report to a UX manager. UX team members work on various products and business efforts as needed, basically acting as consultants to the rest of the organization.

A company with a large investment in UX would have a more elaborate org chart, with multiple levels of UX management, but if it followed a strictly centralized model, all the company’s UX professionals would report into a single hierarchy, headed by the UX VP, Director of UX, Grand UX Poobah, or whatever title were used for the company’s top UX person.

This model is also sometimes referred to as an “internal agency model” (because agencies typically structure design and research resources this way), or as “UX as a service” (UXaaS) or a “UX center of excellence.”

How the Team Typically Works

When a product or project team needs UX support, the UX manager communicates back and forth with the product team’s lead to fully understand the need. The UX manager then assigns a UX-team member to that project for a specific amount of time based on alignment between the project needs and the skillsets and availability of UX-team members. When the project is complete, the assigned UX-team member returns to the resource pool to wait for another assignment.

UX-team members may work on one or many projects depending on the workload of each need. A project may last for a long or a short time.

Benefits of a Centralized UX Team

• UX at a high level: Having a core group of UX staff means that there is a UX manager or executive overseeing the performance and contributions of that group; therefore, there is organizational investment in UX at a high level. The UX manager can describe, champion for, and defend UX to the rest of the organization, and be the budget and resource custodian.
• Wide range of UX skills: Centralized teams often include a wide variety of UX skills, from IA to research. Therefore, centralized teams have increased breadth and flexibility and can provide product teams with exactly what they need, drawing from a wide pool of UX skillsets shared among the team. Additionally, centralized-team members often mentor and help each other grow within various expertise areas, evolving the collective skills of the team over time.
• Broad opportunities for UX-team members: Acting as consultants, UX team members work on various projects, gaining a wide breadth of product and organizational knowledge. The variety of work often helps UX people remain challenged and less “bored” in their work. Additionally, the centralized team can transfer this broad knowledge, consulting each other when needed and connecting product teams who otherwise would not work together.
• Known career paths: Centralized teams tend to be large and to have established job tiles, descriptions, and career paths. This environment can provide UX people with goals for which to strive. People who prefer to remain individual contributors can still grow and be promoted, while people who would like to become managers can aim for those positions. Teams with both executive-level UX jobs and senior individual-contributor jobs provide UX role models and mentors who can cultivate the careers and minds of new professionals.
• Shared resources among the UX team: A centralized UX team is likely to share design and research resources and knowledge, cultivating personal growth and increasing overall team expertise. DesignOps or ResearchOps processes and roles can help maximize knowledge sharing among the team: A shared UX toolbox (e.g., templates for common deliverables, a database of user research insights, workshop agendas) helps teams avoid reinventing the wheel every time a tool or a process is needed. And a shared research-participant database helps teams overcome the very common roadblock of participant recruiting when doing user research. 

Challenges of a Centralized UX Team

• UX teams are often chargeback centers: Often, other teams will have to include collaboration with the UX team as a line item on their project budget.  As a result, the UX team must (1) convince teams to include UX on their projects (often a difficult enough battle), and (2) pay for it out of its own budget,. To circumvent this issue, some organizations require each product team to allocate a certain amount of money to UX work. Such an approach can lessen the need for the centralized UX team to convince product teams to participate in UX activities. But even with best intentions, organizations with low UX maturity can require product teams to use specific user-research methods that may not in fact be optimal for their needs and contexts.
• Out of sight, out of mind: Because the UX staff is not incorporated into project or product teams on a consistent basis, those teams may forget to proactively involve UX in their workstreams. UX-team members may not be invited to participate in strategic conversations, activities, or meetings, not out of intentional disregard, but simply because they are not top of mind.
• Lack of shared understanding: In some cases, the product team or UX professionals may lack common ground. Individual product teams may have little understanding and respect of UX. This perception may be reinforced when, due to the in-and-out nature of their involvement on projects, centralized UX staff are unable to gain deep product knowledge, and thus, are less effective.
• Difficult-to-predict staffing: If the UX manager is not in the loop about upcoming projects, perhaps due to lack of alignment with the organization’s leadership, the UX people may be either understaffed and unable to help on projects where their skillsets are needed or overstaffed and sitting idle.

Decentralized UX Team

With this model, there is no core group of centralized UX staff reporting to a UX manager — rather, individual UX-team members are embedded within a number of teams throughout the organization, aligning to specific features, products, or lines of business.

This model is typically how UX teams start out in traditional in-house product organizations and startups (as opposed to design agencies and UX-consulting firms). Decentralized models are often described as “distributed” or “embedded” teams, or, sometimes, “pods.”

How the Team Typically Works

UX staff is distributed across many teams. Each product team has budget, and UX work comes directly from that budget. Individual UX professionals work consistently with the same developers, product managers, and other team members over time, and they report to an individual within that team.

Benefits of a Decentralized UX Team

Many advantages of a decentralized UX team are direct foils to the drawbacks of a centralized team:

• Increased trust and opportunity: Because the individual UX people are part of the product team, these UX professionals can build trust with their product team members. UXers are able to become experts in the product or line of business they work on (due to long-term exposure and narrow focus) and their value can, therefore, be easily recognized by other team members (who are also experts on that product).
• High likelihood for UX involvement: In a decentralized model, UX-team members are involved in the same planning meetings, activities, and conversations as the rest of the team. In physical offices, the UX people will be literally more visible as they are seated with their product team members. Consequently, UX will likely be involved in workstreams, providing opportunities to contribute and prove value.
• Manager’s sense of responsibility: A line manager who is responsible for a UX person may make greater efforts to ensure UX success than if that UX person reported to a different area.

Challenges of a Decentralized UX-Team

• UX could be outnumbered: Especially if an organization (or a team) has low UX maturity, it can be difficult for decentralized UX professionals to hold their own against many developers and other team members when disagreements or differences arise. The dissenting opinion of one or two UX-team members can be easily ignored.
• Little time for design and research: When UX staff members are outnumbered, they are likely to spend a great amount of time selling, convincing, and educating other team members about the value of UX. Especially when UX is not fully integrated into the development process, the effort spent trying to interject UX into the process can take most of the UX team’s time, leaving little for research and design!
• Redundant UX efforts: In direct opposition to the centralized model, it is difficult for decentralized UX staff to regularly communicate and share resources. Especially in the absence of a centralized design system, UX framework, or research-insights repository, work can be wasted and duplicated due to lack of alignment and collaboration. Unknowingly, UX professionals will create deliverables, research plans, or design elements from scratch, rather than taking advantage of existing resources from past efforts.
• No process improvements: With no designated UX management responsible for the company’s overall UX efforts, nobody is in charge of seeking continuous improvements in the quality and productivity of UX work.

Matrix UX Team

The matrix UX-team model is a hybrid of the centralized and decentralized models. Here, UX people report both to a centralized UX-group manager and to a product team. (One of the managers has priority and thus higher weight than the other.) Thus, UX-team members are overseen by both a UX-specific lead and an individual team lead.

Like the decentralized model, a hybrid model can work well in organizations using Agile or scrum methodology. There could be many variations in the specifics of how organizations create a merged management approach that takes advantage of those benefits of centralized and decentralized models that are most important for them.

How the Team Typically Works

In a common instance of a hybrid model, UX staff is distributed across many teams, where they act as long-term resources and team members. Depending on organizational structure, their team may align to a specific feature, product, domain, or line of business. Day-to-day direction is provided by and supervised by the team lead (e.g., a product manager or scrum master); however, a UX manager or executive also provides oversight (often from a career-development and personal-growth perspective). Often, alignment and collaboration among individual UX-team members is retained with UX-wide meetings, such as design reviews or communities of practice.

Furthermore, the UX manager may oversee a small number of additional staff who are not assigned to product teams, but instead work on company-wide initiatives, such as creating design standards or running a usability lab (that’s used for product-design tests conducted by the UX staff who work on each product).

Benefits of a Matrix UX Team

• Double the focus on UX: In a matrix model, there is UX oversight from both a UX manager and a product-team lead; consequently, two managers may take responsibility for an individual UX professional’s success and, thus, for UX in general.
• High likelihood for true partnership: Because UX professionals partner long term with an individual product team, other product-team members will be likely to view UX staff as a true part of their team, involving them in critical conversations, meetings, and activities.
• Increased flexibility: A matrix team is less rigid than a strictly centralized or decentralized one and can, therefore, be easily adapted to meet evolving organizational pressures or short-term, immediate needs.

Challenges of a Matrix UX Team

• UX practitioner confusion: Because UX staff report in some manner to two managers, they may feel pulled in two different directions, unsure about which manager has ultimate authority on design direction, who to approach with personnel or team issues, or which person to speak with about career goals.
• Difficult to operationalize: In large organizations with many layers of alignment, matrix models may be difficult to operationalize. However, in organizations where there are multiple product teams, a matrix UX model can provide the best of both the centralized and decentralized worlds — as long as the UX-team leader and product-team leader are in sync with their UX goals.

Which Model Is Right for My Organization?

There is no best model among these common structures. Overall organizational context (e.g., organization size, complexity of products, capacity of the UX team compared to organizational demand) should drive the decision to commit to one model over another. That being said, there are a couple of common patterns observed:

Typically, nascent teams within design agencies begin in a centralized model. At the time of team inception, there simply aren’t usually enough design and research staff to support a decentralized model.  As the size of UX staff grows, usually in correlation with an increasing demand for the skillset, the team may evolve into a decentralized model, because there are now enough UX people and UX expertise to distribute across teams in a fixed manner.

Conversely, in-house product organizations often begin with a decentralized team. As the need for UX is recognized, an individual team may hire a UX role. As that person’s value is realized, additional teams begin asking for support from the UX role. Eventually, headcount and budget may be approved for additional roles. As the amount of UX staff grows, typically a UX-team member begins to lead and suggest a centralized team for its benefits of efficiencies and knowledge sharing.

After a length of time and lessons learned, many organizations (both agencies and in-house product organizations) eventually embrace a matrix model. With this flexible, hybrid approach, an organization can balance a long-term partnership between UX and product teams with the need to retain consistent collaboration and alignment among the core UX team.

When deciding which model might be best for your team, consider the following:

• Existing process: Do the process teams currently use include UX activities and checkpoints? If not, UX will be difficult for anyone, but will be especially difficult for one UX person on a product team within a decentralized model. Lack of support and resources means this person will spend a good amount of time just trying to convince the team to do UX work.
• Size of the UX team compared to number of products and product teams: Are there enough UX people to commit to individual product teams? Or, does project-by-project prioritization need to occur? If a decentralized model is appropriate, but there are more product or scrum teams than UX people, which teams will have a UX person and which will not? Can that decision be made objectively and consistently? If project-by-project prioritization is needed, a centralized model or matrix can act as a custodian to UX allocation.
• Workload: Is there enough demand for UX expertise within individual product teams to justify a dedicated UX resource? Or, will distributed UX-team members find themselves sitting around twiddling their fingers, wishing they could contribute to workstreams where their skills are needed?
• UX maturity and culture: Will distributed UX staff’s expertise and insights be as valued as that of other members of individual product teams?
• Opportunities for collaboration: If the UX team is distributed in a decentralized model, how will collaboration and resource sharing be enabled among the UX team? What meetings, spaces, or rituals can be put in place to ensure that alignment is maintained?

Summary

The following table summarizes the benefits and drawbacks of the three UX-team models.