To understand where DesignOps is headed, we need to take a look back and see how Design evolved to the point of creating the conditions for DesignOps.

The history of design as a problem-solving approach stretches back at least 40 years.

The relevance of design and the concept of Design Thinking became widely acknowledged in the late 2000s: in 2009 Roger Martin wrote the book The Design of Business: Why Design Thinking is the Next Competitive Advantages and the year before Tim Brown published his article Design Thinking in the Harvard Business Review.

However, the concept of Design Thinking as an empathy and experimentation-driven problem-solving approach was not new at the time — in 1981 the Italian designer Bruno Munari wrote the book Da cosa nasce cosa: appunti per una metodologia progettuale (translated: One thing leads to another: notes for a design methodology): this book is not translated in English, but this article summaries the methodology and the approach.

While Munari focused on the methodological approach, R. Martin and T. Brown have the merit to connect Design Thinking to the business and since the late 2000s Design became a synonym for good business to the point that large organisations and consultancies started acquiring boutique design agencies to bring in the talent and the Design Thinking mindset.
This phenomenon was huge and it was well documented by John Maeda, who in 2015 launched the Design in Tech Report to follow this trend.

McKinsey also started analysing the phenomenon: in 2018 it launched the McKinsey Digital Index and provided all the data to prove the correlation between design and and business performance.

Between 2010 and 2020 Design as a practice and discipline became an exciting (and complex) space: these were design’s golden years.

During this period, the largest application of Design principles and Design Thinking went into the development of new digital infrastructure. Many companies transitioned their services to the digital space, beginning with the web and later expanding to apps.

But this also has added a new layer of complexity: in the ‘90s a website was generally built by a WebMaster, who was responsible for building the website directly in HTML 3.0 and CSS 1.0, with occasional use of Macromedia Flash or Dreamweaver (or maybe MS FrontPage). The WebMaster often performed multiple roles including copywriter, information architect, visual designer, UI designer, UX writer, and user researcher.

Today, delivering digital products and experiences involves a multitude of skills, teams, and tools. As this complexity grew, it became clear that having dedicated individuals to manage and orchestrate these processes was essential.

In one sentence: DesignOps emerged from the need to orchestrate the complexity required by the Design process to deliver digital experiences efficiently and effectively.

From Design Thinking to Design Doing

Towards the end of the 2010s, a more advanced design process emerged, and pioneers in DesignOps began giving structure to the discipline: Org Design for Design Orgs was published in 2016 followed by DesignOps Handbook a year later.

During the 2010s, there was a significant surge in demand for designers and design professionals across various disciplines such as UX, UI, research, content, service, visual, and copywriting. However, despite the rising demand, numerous companies struggled to achieve genuine design maturity. As design teams expanded, many fell short of delivering the expected business impact seen in truly design-driven organisations.

With only 5% of organisations reaching full Design maturity (according to Invision) and 41% admitting to being at the lowest level of maturity, it becomes clear how Design lost influence by failing to evolve and mature, leaving designers to execute pixels or screens instead of driving innovation and experimentation.

As product organisations became more complex, some design practices shifted from Design Thinking towards task execution, losing their power to drive user-driven innovation. This shift resulted in designers fulfilling requests from Product Managers (PMs), while PMs took over more problem-solving, research, and ideation tasks.

The lack of maturity and inability to practice design as an empathy-based problem-solving approach has led to the transition of design practices from Design Thinking to Design Doing, directly impacting businesses’ perceptions of design: once considered a key strategic discipline in the 2010s, in the 2020s it has been regarded as a cost centre.

Design Thinking became Design Doing: from empathy based problem solving and innovation focused discipline, design turned into an execution and delivery focused practice talking more about Agile than empathy and experimentation.

DesignOps as a streamlined approach to Design

In all this, DesignOps emerged to streamline and optimise the team’s health and the delivery of design projects, focusing on the execution and orchestration of the workflows. DesignOps then transitioned into a more strategic role, addressing not only the execution (Design Doing) but also the root causes of inefficiencies and ways to empower Design (Thinking). This involved operating at a higher level to establish cross-functional engagement models, focus on creating high-performing teams, and maximise business value through operational excellence.

What problem is DesignOps solving for?

There are several articles that analyse the ambiguity of the word Design that can be used as a verb, the act of planning and solving problems (I designed a new car), a noun — the output of the design process (I like this design), or an adjective (I do Design thinking) — see here. In this article I refer to Design as a verb indicating the act of solving problems through a process.

But to understand Design Ops the key is to define operations. From an etymological point of view, Operation comes from the Proto-Indoeuropean root *hop that can be found in the Latin Operari (here) and Operari means putting an effort to have an effect.

If Ops means stays for Putting an effort to have an effect: How do we combine Ops with Design?

• Are we using Design as a verb:
  Designops is about putting an effort to have an effect on the the ability to solve problems through a process (Design Thinking).
• Is Design a noun:
  Designops is about putting an effort to have an effect on the output — the design, the pixels (Design Doing).

The question becomes how we apply the term Operations to the word Design.

CHALLENGE #1
Is DesignOps about putting an effort into enhancing the design practice or is it leveraging Design (Thinking) for impactful organisational outcomes?

In linguistics there is a distinction between the topic, what is being talked about, and the comment, what is being said about the topic (see here).
Now, the question is: what constitutes the topic and the comment in the term “DesignOps”?

Are we talking about Design best practices applied to Operations, or are we talking about operations applied to Design practices?

And how are the other operations dealing with this conundrum?