DesignOps

DesignOps, or design operations, organises the processes, tools and communication that support design teams as they grow. The role identifies friction as a project moves through the team, makes collaboration easier and gives designers time to design and conduct research. It supports the design team and its partners, especially product and development teams.

The scope starts with how work actually gets done: how a request arrives, who handles it, where decisions are made and how deliverables move to the next stage. DesignOps may structure team routines, shared documentation, onboarding for new designers and the choice of tools. It may also organise contributions to a design system and help the team adopt it. That system remains a library of components, styles and rules; DesignOps is the practice that helps sustain it. The exact responsibilities depend on the organisation’s needs and maturity.

The role may be dedicated, or its activities may be shared among several people. Before hiring, employers therefore need to define the problems to solve, the teams involved and the decisions the person will be able to make. Coordinating design work does not automatically give them line management responsibility for designers. Nor does it make them responsible for every product decision or interface.

DesignOps, Product Designer and Head of Design: who does what?

• DesignOps organises working conditions and the flow of information between teams.
• A Product Designer designs product solutions. Experience in product design can help a DesignOps practitioner understand designers’ constraints, but producing interfaces is not their main responsibility.
• A Head of Design may lead and manage the design team. Managing people does not follow from the DesignOps title alone.

These boundaries should be set out in the job description: the same operational problem may involve several roles with different responsibilities.

As a design team grows, practices that worked for a few people can become hard to follow. Requests come through several channels, decisions get lost and handovers to development require rework. Hiring a DesignOps practitioner addresses this kind of friction if someone needs to understand its causes, coordinate the people involved and maintain solutions over time.

The aim is to make the path of work clear, from the brief to handover to developers. Useful team routines can clarify decision points. Accessible documentation helps new joiners find the context, tools and team practices they need. An explicit request process shows what has come in, what is waiting and who needs to respond. These changes require collaboration with designers and their partners, because a procedure that ignores their daily work risks moving the blockage instead of resolving it.

The design system illustrates the distinction. Organising how proposals are received, reviewed and shared may be part of the role. That does not mean DesignOps designs every component alone or sets quality criteria alone. The GOV.UK Design System offers an example in a particular context: its team reviews proposals and the quality of their implementation before publication. Each company needs to define its own responsibilities and criteria.

Hypothetical example: several product teams request variants of the same component, but nobody knows where to submit a proposal or who should decide. DesignOps could make the process visible, agree a review with design leads and check whether teams use it. Responsibility for choosing the component would still need to be assigned according to the organisation.

A poorly defined remit creates a role that is impossible to fulfil: the person is expected to settle product priorities, manage designers and produce interfaces while improving processes. The actual need may span several distinct responsibilities. Before hiring, naming the decisions entrusted to the role and the partners who retain their authority helps avoid this confusion.

• Map the path of a design request, from brief to handover to developers, to identify points of friction.
• Organise how requests and contributions are handled, with clear responsibilities and decision points.
• Structure team routines and document decisions that matter to shared work.
• Coordinate the design team’s operational work with product and development teams.
• Prepare for new designers to join: context, access, tools and guidance on team practices.
• Help organise contributions to the design system and its adoption, according to the responsibilities defined by the organisation.
• Assess design tools against the team’s needs and support their introduction.
• Gather team feedback and track the effects of changes to processes.

A background in design can provide direct knowledge of the design process and the difficulties the team faces. Experience in DesignOps, programme management or a related area within a design organisation can also prepare someone for the role. DesignOps is rarely a first job: familiarity with design work remains important, whatever the route taken. The sources used here do not support requiring one particular degree or certification. Responsibilities already held reveal more about a person’s background than the name of their course alone.

Useful capabilities include understanding an operational problem by speaking with designers and partner teams, then organising a response. They may involve mapping workflows, documenting practices, clarifying how requests are handled and tracking changes. Design system experience can also prepare someone for the role if it distinguishes managing contributions from designing components.

Knowledge of tools matters when it helps someone compare options against a need and support their use. Proficiency in one brand alone does not prove an ability to improve how people work together. Listening and coordination with product and development teams complement this experience.

To assess this profile, you can follow the steps below and adapt the exercises to the role’s scope.

1. Define the criteria before interviews

Write down the problems the person will need to tackle: requests, team routines, documentation, tools or design system adoption. For each area, distinguish what they may decide alone, what will need the design lead’s agreement and what belongs to product or development teams. Assess their ability to diagnose a blockage, involve the people concerned and track the effects of a change. A list of tools they know cannot replace these criteria.

A positive sign is a candidate who asks who receives requests now, where decisions are made and how teams know whether a change helps. A warning sign is a promise to standardise all work before understanding the differences between teams.

2. Review past work

Ask for an example of an operational difficulty the candidate examined. Have them explain the starting point, the feedback they gathered, the options they ruled out and their own responsibility.

Also ask what changed after implementation and what observations support their account. The sources describe listening to teams and tracking effects as useful abilities. An account that attributes every result to one person, without explaining the roles of designers and partners, calls for further questions.

3. Present a case relevant to the role

Hypothetical example: three teams submit design requests through different channels, and developers sometimes receive conflicting versions. Ask the candidate how they would investigate the causes, whom they would listen to and what small first change they would test. Ask what they would document and how they would observe its effects without imposing a single measure.

A sound approach separates available facts from assumptions, identifies which decisions need to be discussed with others and plans to gather team feedback. An answer that jumps straight to software or a general rule without examining the path of requests deserves closer examination.

4. Explore coordination and disagreements

Ask how the candidate would act if a design lead and a product team disagreed on the order of requests. Listen for how they would make constraints visible, whom they would bring together and who would make the final decision. DesignOps can organise the discussion without automatically owning the final decision or managing everyone involved.

Also examine how they would introduce a new practice to designers worried about extra administrative work. A positive sign is an explanation of the problem it solves, followed by a test and a way to adjust it. A warning sign is a new procedure with no owner or plan for feedback.

5. Check professional references

With the candidate’s consent, ask someone who worked with them to describe a specific improvement, their part in the decision and how the team adopted it. Ask the same questions about a change that worked less well. The answers help clarify the scope of their actual responsibility; they do not replace examining their work.

If your company has no DesignOps expertise, involve a design lead and a product or development partner in the assessment. Together, they can judge the quality of the diagnosis and whether the proposals are workable, each within their area.