DesignOps’ toolbox

DesignOps emerged as a function to manage the growing complexity in the E2E design processes. But what are the specific skills and tools that make DesignOps unique and different from other functions?

Why DesignOps has become ‘a thing’?

If we look back at the past 25 years, one of the biggest changes is the transformation of the role of the designer and the positioning of design as a business discipline.

With the spreading of Design Thinking, mostly thanks to Tim Brown’s paper in 2008 and Roger Martin’s book the following year, businesses have explored and exploited the potential offered by design. This led to a fast evolution of design practices and to the increased complexity of web and digital initiatives. Since its beginning in the ‘90s, the web has moved from being a one-man job — the webmaster — to a multidisciplinary, collaborative, and complex task requiring new skills and new processes (more here and here).

Due to the increasing complexity, design orgs have started separating the What, the product or service vision, from the How, the operational strategy to execute the product/service roadmap.

If the design leader is in charge of the product and experiences strategy, someone else had to enable that vision to happen by bringing together tools, best practices, processes, and ways of working that could streamline efficiency and seamlessly embed all best practices in the E2E design process.

When the How becomes as important as the What, when a product or service strategy is unable to be delivered and accomplished, it is time to find a How specialist who can empower the teams and enable the vision to be executed efficiently and effectively.

It is in this context that it has become evident that doing design right required someone to orchestrate and manage the E2E design process and who could master all the domains and skills needed to deliver impact.

DesignOps emerged as a new function addressing the need to formalise processes, improve the consistency of outcomes, increase business results, revise cross-functional collaboration, and reduce errors and waste — being waste time wasted, poor quality outputs, orphan concepts, or just slow delivery cycles.

And it is because of the need to coordinate and consolidate the design processes that in the past few years, a number of design-related professionals have found a growth opportunity in the design operations space: UI and UX designers, user researchers, service designers, producers, schedulers, down to project managers and product managers.

But what is a DesignOps specialist?

As a start, it may be easier to define what a DesignOps practitioner is not.

DesignOps is not a task!

Although there is a clear need of managing the design process and all the cross-functional engagements, the problem is not always clearly articulated and operational matters are not seen with a systemic lens.

DesignOps is often seen as a set of independent tasks that are randomly distributed to design team members on the assumption that DesignOps is about solving contingent problems.
It is not unusual for organisations that have no DesignOps to have one designer to manage tools, another one focusing on ceremonies, a third one onboarding new vendors…

The fact is that the ability to operationalise a design vision is not valued as a distinct skill set.

The designers that are taking operational tasks on top of their job have all been hired to do design. Expanding the scope of a designer’s role to operational tasks can have 2 major negative consequences:

1. Adding operational tasks to designers’ workload can impact their life/work balance, causing long hours. Long hours reduce the ability to focus, affecting the quality of outcomes and causing rework and possible delays and tensions with their cross-functional partners. All this can then lead to designers' churn.
2. Asking a designer to execute a task means they have no visibility of the big picture and assigning random tasks with no systemic view of underlying operational strategy may inadvertently create tensions with the cross-functional partners or cause inefficiencies.
   As a discipline that combines Design Thinking with Systems Thinking (see here), overlooking the systemic impact of changes can create more problems than the ones it tries to solve.

The truth is that:

DesignOps is not about how we do things, it’s about how much business value is created through operational excellence.

And all DesignOps conversations should focus on the operational vision and strategy where each issue needs to be assessed and seen in relation to all other problems within and beyond the design organisation.

DesignOps is not Design Management

According to the DMI (Design Management Institute),
Design management encompasses the ongoing processes, business decisions, and strategies that enable innovation and create effectively-designed products, services, communications…

DesignOps has a similar intention (enable innovation and create effectively-designed products), but the ultimate goal is very different.
DesignOps is not focused on products/experiences (external focus) but it has a strong internal focus and it is aimed at creating and measuring impact and value.

In fact, Design Management is a product and service focused approach concentrating on the outcome.
On the other hand, DesignOps is an internally focused discipline that aims at making the product delivery experience efficient, and effective for all those involved by reducing waste and maximising business ROI.

So while Design Management considers the successful delivery of an effective product as the key achievement, for DesignOps success is about eliminating the waste in the process to create business value through:

• Stakeholder management
• Budget management
• E2E design process optimisation
• Tools’ ecosystem definition
• Improved designer experiences
• Enhanced cross-functional engagement models

Design process management is only one element of DesignOps’ remit, but there is much more to it!
More on this here.

DesignOps is not Programme Management

This ability to define E2E and cross-functional processes that embed best practices and align the design ways of working to the company’s metrics is what makes a DesignOps practitioner deeply different from a Programme Manager.

These two roles operate at different altitudes: while the DesignOps practitioners assess the problem, quantify the inefficiencies, and prioritise and sequence the initiatives, the programme manager is tasked with the implementation and execution of the solution.
A programme manager does not have — and they do not even need to have — knowledge of Design Thinking, Lean StartUp, or a detailed understanding of the problem or the user space.
A programme manager needs to understand the solution and how to execute it.

Simply put, Programme managers execute a programme to improve organisational performance, and DesignOps orchestrates engagement models and processes to maximise returns and impact.

To fully support the design organisation and to define the most effective processes that empower the teams to deliver products and experiences, a DesignOps practitioner needs to fully understand and have first-hand experience with the product and design processes and how all product management and delivery approaches work together to generate results and value.

What makes DesignOps … DesignOps?

DesignOps does not solve a single problem in isolation, DesignOps is a strategic approach that connects design and business through the orchestration of value-generating transformations across design and their cross-functional partners.
This is because DesignOps is closer to Change Management than to Project Management.
DesignOps builds on a solid understanding of the E2E design and product processes to bring the human elements (both the designers and the end users) at the heart of the process.

For this reason, DesignOps specialists need to master a number of very diverse skills that are not always sufficiently called out.
Yes, Programme Management is one of those skills, and no, Programme Management is not the most critical one.

The most critical expertise required is Change Management: DesignOps is a transformational discipline aiming to generate value for the business, the leadership, and the teams through the optimisation of the existing operational models.

And optimising the context and the operational models may mean at least 3 things:

1. Improving the design teams’ spending: budget inefficiencies are endemic and widespread. Just having a thorough look at tools setups, vendors, and contracts can save up to $100,000 with no effort or impact on the operations. And it can be done just with a single click.
   But improving spending efficiencies also mean collaborating with vendors and partners to maximise the ROI of every partnership.
2. Optimising the E2E design process by reviewing tools, templates, playbooks, data governance approaches, and the design system’s organisation… All this means working on the design process to enable designers to apply all best practices effortlessly.
3. Focusing on the teams and ensuring everyone has clear opportunities to grow and thrive in a constructive and safe environment where they know what is expected from their role, how to get promoted, and how to up-skill.

To manage these transformations and changes there are a number of transversal skills needed to be mastered, such as:

• Change Management: This is critical and non-negotiable. This is what distinguishes a DesignOps practitioner from a design manager. (More here)
• Systems Thinking: DesignOps delivers systemic changes. Positive (and negative!) impact easily cascades down to other teams that may be indirectly affected by the change. (More here)
• Design Thinking: As a design discipline, DesignOps needs to be familiar with the E2E design process and best practices. It would be nearly impossible to successfully change a process without knowing it.
• Lean StartUp: since design and product are critical partners, it is important that DesignOps practitioners know Product frameworks so that responsibilities and remit between product and design can be clearly outlined (more here)
• UXR (User Experience Research): as a transformational discipline, being data-driven and able to assess, measure, and understand the context in its depth through a number of research approaches is critical for the success of every DesignOps practice.
• Service Design: DesignOps is a form of service design for designers as it looks at designers’ blueprints and journey maps to identify opportunities.
• Design Standards: this bucket includes both all those design-specific standards, such as W3C standards ( WCAG 2.0, ATAG… ), and methodologies and best practices, such as Atomic Design and Design Systems, and web technology standards.
• Stakeholder management becomes critical to ensure transformations are being accepted — indeed — welcomed! by everyone and the value and benefits of the ongoing transformation are clear to all stakeholders involved.
• Budget management is essential to achieve spending efficiencies and to effectively partner with Finance and Procurement.
• Business strategy: as a function that connects design to business, it is important for DesignOps practitioners to know the fundamentals of business strategy, including organisational strategy and competitive strategy, marketing strategy.
• The legal aspects include privacy laws and GDPR in Europe, he specific requirements for different industries and geographies, and data governance. Knowing the details of what the industry regulation and local laws require is critical to define compliant processes and removing reputational risks so that designers can focus on design without putting the organisation at risk.
• Programme Management & Project Management: to execute the operational strategy, and to empower the team who is asked to do so, it is important to know the best practices and basic frameworks of how programmes and projects can be executed.
• Agile: as an iterative approach to project management and software development, it is important for DesignOps to manage it as it can help interact with cross-functional partners.
• Other skills to mention include empathy, analysis and synthesis, storytelling, influencing, listening, coaching, mentoring…

Final remarks

The list above is a generalisation and as with every generalisation, is imprecise.
The goal of this article is not to provide a prescriptive list of skills required to become a DesignOps specialist, but to highlight the complexity of the role and why considering DesignOps as a by-product of programme management or, even worse, a task does not even touch the surface of the problem solving and complexity of this function.

DesignOps emerges exactly to solve the growing complexity that surrounds the successful development of products and services today.

And a final Caveat: there are more skills that may be mentioned, and the truth is that no two DesignOps are the same, but they all need to master most of the skills mentioned to a certain degree. This degree depends on the organisation and, again, the context.