Whose Job Is This DesignOps

Whose Job Is This DesignOps? With your permission, I will use the following phrase, which is often used when answering questions that do not have a single answer: “It depends on the situation”.

Let’s remember what it is before we start explaining whose business it is. DesignOps is simply defined as “everything related to experience design, other than screen drawing.” Team structure, software used, research practices, where and how to do the documentation… This is all the subject of DesignOps. The aim is to provide a sustainable and scalable environment in which design activities will flourish and grow, and to maximize the share of design in the value chain.

Whose Job Is This DesignOps?

How and by whom DesignOps should be run can vary from organization to organization because the structure and needs of each team are different. Now, if you want, let’s take a look at the different ways to integrate it into your design studio.

4 different structures for DesignOps!

When it comes to organizing DesignOps within a company or design function, we can talk about 4 different structures. It is difficult to argue that one is superior to others. Each has different advantages and disadvantages, and it’s best to decide which method is better for you based on your firm’s “UX maturity level.”

Messy

We can call the structures that are carried out by people with different roles in DesignOps and do not have an official it unit scattered. The word messy here doesn’t mean untidy, it just means that the work is carried out by people scattered across different teams.

Scattered team structures are often seen in organizations that are at the beginning of the road in terms of design maturity (where design thinking does not penetrate the company culture enough). This is because the need to invest in design operations has not yet been sufficiently recognized.

People who do not have DesignOps in their titles or job descriptions, but who have identified this need, voluntarily (and sometimes obliged) allocate resources to this issue. The main disadvantage of this situation is that when people do not have enough resources, it work is thrown into the background or even stopped.

Design maturity

On the other hand, an organization that is advanced in terms of design maturity may also prefer this structure. Teams with this culture don’t need a department named after them to work on DesignOps because they internalize the issue. The important thing is to ensure that the people who will make efforts in this field should include this in the job description and that they can allocate the necessary time to the subject.

In addition, it is important for people working on it to progress in coordination with each other in terms of consistency.

Defined DesignOps!

In this structure, the execution of design operations is the task of one or several professionals. That’s their main job, and their titles are like “DesignOps Manager,” “DesignOps Lead.”

In structures where a single person takes on this role, this decision is most likely made reactively. In other words, some problems in the design processes have started to harm the organization, and with this awareness, a person has been asked to be completely dedicated to this issue. The main task of a DesignOps Manager who comes to the task in this way will be to meet with the different roles within the design function, identify and prioritize pain points, and lead the solution development processes.

Lonesome American cowboy

This person’s empathy and persuasion skills must be very strong because he alone must be able to decipher the raw problems and break the resistance he may encounter in terms of solutions. As a “lone cowboy“, being crushed under the burden he has entered can be seen as another risk.

In order to eliminate this risk, the DesignOps task can be made the main responsibility of more than one person. In this case, each professional makes the division of labor possible by working on the subject that falls within their area of expertise (such as recruitment and onboarding, documentation, workflows). Of course, it is important for these people to share information among themselves, otherwise disconnects may begin between the steps taken.

Team Based for DesignOps!

In fast-growing organizations with largely autonomous teams, each team may need one or more DesignOps professionals. While focusing on the needs of the teams they are a part of, these people should also be in sync with each other so that they can act in accordance with the goals set at the organizational level and prevent the teams from progressing with completely different approaches. It is also helpful to have a DesignOps Manager to whom these people are connected for the coordination of DesignOps roles that are distributed across teams.

As with the defined structure, one person might manage all of a team’s DesignOps processes, or several people might split labor between them (for example, one DesignOps specialist might be involved in recruitment and training, while another might be engaged in the creation of workflows within the team).

The advantage of the tool-based structure is that it provides flexibility. Teams with more work in the DesignOps space may be supported by more than one person, while some teams may not have anyone involved in it. The challenge will be that the needs and practices of the teams cannot be aligned with the overall strategy at the company level.

Strategic DesignOps!

In this last structure, DesignOps has ceased to be an activity undertaken by individuals and has become an organization almost in its own right. This organization develops high-level tools and approaches to carry the design function. In other words, it has gone beyond organizing the functioning of teams and has become a strategic tool.

In the strategic structure, designers can also be included in the DesignOps team. These people can take on major tasks such as creating a design system and take the load off the teams. In addition to this centralized structure, DesignOps managers can also be involved in the teams and produce more micro-solutions for daily operation.

The critical point in this structure is that the DesignOps managers in the central structure are not detached from the designers and develop solutions that meet their needs. Otherwise, design teams may feel that some solutions are being imposed on them and reject them.

Where to Start?

If you’re on the verge of taking the first step in it, I recommend that you dedicate enough time to the discovery process. Taking the opinions of all stakeholders involved in the design processes and determining their needs will guide you on which structure will be more beneficial. Second, it’s helpful to analyze how much design thinking plays a role in your organization’s culture.

If you’re a team that’s already thinking about how it does it as well as what it does (you may not have called what you’ve done so far ), you can start by questioning which of the above models your current process is closer to and to what extent this model meets your needs. This analysis will enable you to take steps to speed up your DesignOps processes.