https://www.nngroup.com/articles/designops-team-structures/
DesignOps is vast landscape of opportunity, because there are many elements related to enabling consistent, quality design. What an organization chooses to focus on in a DesignOps practice should reflect the needs and objectives of that organization, and so, too, should the structure of that practice when it comes to DesignOps teams or roles.
This article outlines 5 common types of structures for DesignOps teams. The appropriate structure for a company depends on the overall organizational structure, goals, and level of need for formalized DesignOps programs; therefore, there is no best-in-class structure. These structures should be viewed as potential models suitable for different contexts, not as required or progressive steps in a model of DesignOps maturity. Although some organizations may experience natural progression through these structures as they scale, teams do not need to aim for any structure other than the one that provides adequate support and resources.
The 5 common types of DesignOps structures outlined in this article are:
- Scattered: DesignOps efforts are taken on by other roles (e.g., design managers) as part of their day-to-day job responsibilities. Within the organization, “DesignOps” is likely unused as a term and unknown as a formalized concept.
- Solitary: DesignOps is a team of 1. This dedicated DesignOps role identifies and develops programs for the largest painpoints of the design team, often in an initially reactive way.
- Specialized: DesignOps is divided across a few people who manage or oversee specific aspects of DesignOps full time.
- Distributed: DesignOps roles are distributed and dedicated to individual teams throughout the organization, focusing on team-to-team coordination and alignment.
- Elevated: DesignOps scales to become a separate entity, providing centralized resources and programs that affect and benefit the entire design organization.
Type 1: Scattered
When DesignOps is scattered, there are lots of people doing DesignOps-related activities, but without an official practice or title. In many organizations, no one may have even heard the term “DesignOps” or understand what it describes. The term “DesignOps” certainly isn’t a part of everyday rhetoric for all organizations and most organizations lack formalized DesignOps roles (i.e., people dedicated full time to DesignOps). (In fact, our research found that only 13% of teams have DesignOps leads or managers.)
But even in organizations that lack a formalized DesignOps practice and roles, there are still people identifying and attempting to solve operational challenges related to the design team and its processes. Likely, even without labeling it as such, there are senior-level designers, leads, and managers doing DesignOps-type of work alongside their other formally recognized job responsibilities.
In a scattered structure, there are no official DesignOps roles. Design-team members perform necessary operational tasks alongside their design responsibilities.
This scattered structure is likely to be a widespread one due to the low level of DesignOps maturity across organizations. When we surveyed 557 UX professionals about the level of DesignOps maturity at their organizations, only 10% of respondents reported that there was a broad understanding of DesignOps across teams or that the value of DesignOps was established within the company culture.Scattered Structure in Practice
The absence of formalized DesignOps could indicate a low level of overall UX maturity. Certainly, companies that do not acknowledge the value of UX or support the overall UX practice will also not support a formalized DesignOps practice or hire dedicated DesignOps professionals. In such cases, design leads and managers will often scramble to carve out time and resources to solve operational challenges and enable design work, thus placing additional burden on themselves with no recognition for these efforts.
A scattered DesignOps structure could also be in place at organizations where DesignOps is understood and valued. Teams early in their DesignOps journey — or overall UX journey — may not have resources for a dedicated DesignOps role yet, even if such a role is widely desired. In these situations, teams may decide to include — and hopefully formally recognize — ops-related responsibilities in the job description and responsibilities of existing design roles. For example, design managers might be given authority and resources to create method protocols for their teams. Or, committees of representative designers may take on specific DesignOps challenges, such as creating a design system, documenting the design process, or systematizing UX meetings.Challenges and Benefits of a Scattered Structure
While individual teams without a unifying DesignOps structure have the benefit of choosing tools and methods autonomously, the biggest issue within a scattered structure is often lack of consistency. When individual teams are not aligned, they may develop wide variations in processes, methods, and tool stacks that make it difficult to collaborate, share insights and templates, or avoid duplicative work.Type 2: Solitary
In a solitary structure, one person has been given the official recognition and bandwidth for full-time dedication to DesignOps. This person often has an open-ended title such as DesignOps lead, DesignOps manager, or head of DesignOps and is charged with being the tip of the DesignOps spear — cutting a path through uncharted territory and leading teams into the DesignOps frontier.
This DesignOps team of one is typically focused on damage control through necessity, making sense of the backlog of operational debt and tackling the most obvious pain points one at a time. This role works across multiple designers or design teams to identify the biggest operational challenges and develop consistencies and standards that will benefit all teams.
In a solitary structure, a dedicated DesignOps role emerges to support multiple designers or small teams.
Often, this role is divided between 2 primary responsibilities: part design-team liaison, listening to and synthesizing challenges across teams, and part designer, architecting approaches and processes that will ease those pain points and better enable designers.Solitary Structure in Practice
The solitary structure often chronologically follows a scattered structure, because, eventually, someone in the scattered organization recognizes the inconsistences and inefficiencies across individual designers or teams, can bare them no longer, and raises a rallying cry to address the issues.
For a historically small team (fewer than 10 designers) that quickly scales to double or triple in size, an existing designer may recognize that processes and collaboration are becoming difficult to maintain across the growing team. This person feels the pain firsthand and makes a case to leadership to take on these operational issues, hence creating the first formalized DesignOps role.
Alternatively, if the company has a relatively high level of UX maturity across several teams that are generally well-aligned, leadership might proactively recognize the need for formalized DesignOps and bring in a seasoned DesignOps professional to “stand up” DesignOps in the organization.Challenges and Benefits of a Solitary Structure
In a solitary structure, DesignOps has been officially recognized. There is at least some level of formal acknowledgement and buy-in for optimizing the design process and allowing at least one person to take on this work full time. However, this person can quickly become overwhelmed by the plethora of operational challenges to solve and the many activities required to do so (e.g., identifying obstacles, roadmapping activities, tracking efforts, gathering feedback, evolving efforts). This burden is exacerbated if the existing designer must prove success of some DesignOps initiatives before being granted full-time focus.
Furthermore, this fledgling role is in a precarious position. They may face resistance as they carry out the unsung responsibility of tirelessly advocating for DesignOps, both to stakeholders and to individual designers who may not embrace change. Listening and rapport-building skills (easier for someone who came from a former design role) are critical, as a DesignOps professional in a solitary structure who attempts to design and impose processes in a silo will be rejected by the system of designers they’re attempting to support.Type 3: Specialized
In a specialized DesignOps structure, there are multiple (but limited) dedicated DesignOps roles, each focused on specific programs or specialized areas of DesignOps. Rather than having a single DesignOps generalist who focuses on identifying and solving DesignOps challenges of all kinds (like in the solitary structure), DesignOps professionals are specialized, meaning that each has a specific, unique focus area corresponding to some facet of the DesignOps landscape.
Individual DesignOps professionals within this structure focus on operational challenges and solutions aligned to their personal areas of expertise and skillsets, but remain tightly aligned with each other, collaborating to ensure that the operational programs put in place to support designers are complementary and coordinated.
In a specialized structure, multiple DesignOps roles exist, each with a specialized focus area.
DesignOps roles within this structure are created after specialized-need areas become apparent and they often alleviate an overburdened individual role in a solitary structure, allowing each person to focus on areas they are most motivated by and most knowledgeable about.Specialized Structure in Practice
As DesignOps gains traction and proves some measurable success over time, it can become too much for a single role to handle. Even if one superhuman were able to expertly manage multiple areas of DesignOps long term, they might not be interested in or even good at all the potential areas of DesignOps that need to be addressed.
If a DesignOps team of one can successfully benchmark and measure the growing success of initial DesignOps efforts, it often creates buy-in for additional DesignOps roles. Here, the DesignOps team expands by bringing in additional dedicated roles — maybe just another person or two to start — who can focus on specific programs or specialized facets of DesignOps that have proven most impactful.
For example, in a small and emerging specialized structure, there could be three DesignOps professionals: one focused on PeopleOps initiatives such as hiring and onboarding, one focused on optimizing design workflow, and one focused on tool curation, licensing, and tool onboarding.Challenges and Benefits of a Specialized Structure
In a specialized structure, individual DesignOps professionals can concentrate on specific workstreams, providing dedicated focus to areas that have been identified as critical for the long-term success of the design organization. However, without strong alignment among these roles, DesignOps will become fragmented.
Furthermore, this growing DesignOps team must not neglect its responsibility to help others understand its role. The individuals must provide clarity about the differentiated value DesignOps provides compared to other roles. They must also put time and effort into creating partnerships with other ops roles within the organizations (e.g., PeopleOps, MarketingOps, DevOps, BusinessOps, etc.) to ensure everyone is in sync with their efforts, goals, and communications.Type 4: Distributed
In a distributed structure, DesignOps professionals provide dedicated support to individual design teams throughout the organization. These DesignOps roles are a part of the individual team they support and might enable the team through areas such as workflow management, setting design goals, monitoring project trajectory, or roadmapping.
In a distributed structure, DesignOps roles are dedicated to individual teams or areas that need and desire DesignOps support.
Ideally, these DesignOps roles work together to ensure that the overall strategy and communication is in sync across all those teams. As in any decentralized team structure, there should be established touchpoints (e.g., meetings) that provide dedicated time for the distributed team members to share and collaborate with each other.Distributed Structure in Practice
This structure is common for design teams that are experiencing high levels of scaling or with widely dispersed teams. As the design team continues to grow in size, it can become difficult for just one (or a limited number of) DesignOps roles to keep up with shifting needs and challenges. DesignOps may need more “feet on the ground” to better monitor and optimize the health of the design organization. In this case, dedicated design producers or design program managers can help drive and remove obstacles from day-to-day design processes.
While a dedicated DesignOps role is typically more generalist in nature, this is not always the case. For example, a rapidly growing team might hire a dedicated DesignOps role to focus explicitly on recruiting and onboarding.Challenges and Benefits of A Distributed Structure
This approach is flexible and works well at organizations where teams have mixed needs or varying levels of acceptance for DesignOps, because any team can choose to have or not have DesignOps support. Therefore, DesignOps isn’t “forced” on a team that is not ready or does not yet see the need for such a role.
In addition, with dedicated DesignOps support, individual teams’ needs and feedback are more likely to be understood and considered. Dispersed teams are more likely to share knowledge and have consistent processes if the DesignOps roles have a sound structure in place for creating alignment.
However, it can be difficult for the dedicated DesignOps roles to know where to focus: Should they put more effort into supporting individual team projects or into optimizing the global UX programs and processes? At this point, there needs to be strong DesignOps leadership to drive the overall strategy and approach and coordinate this spread team.Type 5: Elevated
In an elevated structure, DesignOps is an organization in and of itself, focused on creating high-level tools and programs that support the entire design organization.
Here, DesignOps and design are distinct teams, but have structures and goals that align with and support each other. This structure occurs when team-to-team alignment optimizes and stabilizes, which frees some DesignOps roles to become more strategic. DesignOps roles in this approach tend to be focused on global initiatives, creating design-wide resources that proactively enable the design team and its processes, and they are more removed from day-to-day design activities and project timelines.
In an elevated structure, DesignOps is its own entity, providing centralized tools and resources to the entire design organization.
In this structure, DesignOps needs a strong layer of leadership, with roles parallel to leadership roles in other departments in the organization. DesignOps is part of strategic conversations and is viewed as a critical component for delivering best-in-class design and maintaining a healthy team and culture.Elevated Structure in Practice
Some elevated DesignOps teams remove the burden of creating and maintaining shared systems (e.g., design systems or research repositories) from the workload of individual designers. Such a DesignOps team might even have its own designers and developers, who work on these shared systems full time.
A centralized DesignOps team might be accompanied by a distributed model, where one group of DesignOps roles work across and are dedicated directly to individuals teams, and one group is centralized, focusing on global efforts such as culture building, new hire experience, or career pathways.Challenges and Benefits of an Elevated Structure
With dedicated team members working full time on centralized tools and programs, these initiatives are given adequate attention to be truly useful and accessible and designers can focus on design work, unhindered by dual responsibilities. However, the DesignOps team must remain diligent about gathering and acting on design-team feedback, or it risks the contempt of teams who feel like irrelevant or useless processes and tools are being forced upon them from the top down.
This approach requires strong leadership to prioritize initiatives and to plan for scaling DesignOps over time. Some role(s) must be thinking about creating programs for things like evaluating progress on DesignOps goals, evolving DesignOps areas of focus as business needs change, and elevating DesignOps leadership and impact to be parallel with those of other departments in the organization.Conclusion
Recognizing the DesignOps structure used by your organization helps you identify strengths, build on existing successful programs and efforts, and become aware of potential dangers. In addition, it enables you to loosely plan the evolution of the DesignOps structure as it continues to scale in demand and size.
When referencing these structures, take note that:
- This list is not exhaustive. This is a set of common DesignOps structures, but other models not included could support design teams successfully. In addition, it is reasonable and common for hybrids of two or more models to exist.
- These structures are not a maturity model. These DesignOps structures do not necessarily correspond to DesignOps maturity. For some teams, one dedicated DesignOps role (i.e., a solitary structure) is the right level of support. So, not having an elevated structure does not mean you are not mature in your DesignOps practice. Your structure should be based on your organizational needs in the current and near-future state.
There is no best-in-class structure. There’s no right or wrong here. Different organizations will use different structures depending on their context and needs.
Downloads
- Printable Handout: DesignOps Team Structures (Letter) (PDF)
若有收获，就点个赞吧
0 人点赞
