Over the last decade, we’ve seen a massive surge in operations teams: DataOps, FinOps, DevOps… Yet, there is something unique in DesignOps: it’s Design. Understanding the connection between Design and DesignOps is key to reflecting on DesignOps’ role and determining if and how the destinies of DesignOps and Design are necessarily intertwined.
A representation of the key dates of Design and DesignOps’ evolution, with a correlation between digital products’ complexity and teams’ evolution.
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.
From Design to DesignOps — via Design Thinking
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.
Source: Alessandra Colucci’s translation of Munari’s design 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?
What are other Operations disciplines doing?
In the past 15 years, there has been a growing attention to all operational roles and tasks.
As teams and business units grow in complexity, managing a large amount of tools, processes, silos, and cultures has created a real need. And this emerging need has triggered many operation-focused roles:
MARKETING OPS (MOPS)
Although some authors claim that MarketingOps can be traced back to the 1920s, MOPs as we know it today can be dated back early / mid-2000s, with the first official MOPs framework being released in 2007 by Adrian C. Ott from Harvard Business School in his article Marketing Operations in the Silicon Valley: Addressing CMO Challenges (here). In that blog post, the author quotes the VP of Marketing Operations at a major Silicon Valley firm:
“Marketing operations ensures marketing is run as a business … We strive to enable the marketing organization to be streamlined in day-to-day processes so they have time to think, focus on the customer and to innovate.”
In a nutshell: MarketingOps puts an effort to solve for streamline the processes to enable innovation.
DEVOPS
DevOps is a more recent operation compared to MOPs as its origin date back to around 2008. Software engineering was among the first business groups to feel the pain of inefficiencies and the pressure to operationalise its functioning and manage tools and processes. Today DevOps is defined as:
“DevOps is a way of working that promotes the fastest flow of work while balancing that with the highest levels of quality. It combines organizational culture improvement with technical innovation, particularly around automation” by Helen Beal, Chief Ambassador, DevOps Institute
DevOps’ focus is to shorten time to value by reducing the development and deployment lifecycle and providing continuous delivery and high software application quality.
In a nutshell: DevOps puts an effort to increase speed to delivery and quality of output through culture and technology.
FINOPS
FinOps, the combination of finance and DevOps — is a framework for managing Opex across an organization (see here).
As a fairly recent discipline, that builds on DevOps, all FinOps best practices were developed by the FinOps Foundation, a nonprofit trade association officially funded in 2020 and whose members include Atlassian and Cloudify.
FinOps is an operational framework and cultural practice which maximizes the business value of cloud, enables timely data-driven decision-making, and creates financial accountability through collaboration between engineering, finance, and business teams. (FinOps Foundation 2023)
The emergence of Cloud computing and IT infrastructure prompted the application of traditional financial methods to manage costs and resources effectively, supporting both the business and DevOps teams.
In a nutshell: FinOps puts an effort to drive business efficiency through technology investments and the optimisation of procurement and processes.
DATAOPS
DataOps is another framework that has recently emerged.
According to the definition of DataOps.Live is the following:
DataOps (short for data operations) is a data management practice that makes building, testing, deploying, and managing data products and data apps the same as it is for software products. It combines technologies and processes to improve trust in data and reduce your company’s data products’ time to value.
In a nutshell: DataOps puts an effort to improve processes and workflows to enable the organisation to exploit data and improve decision-making.
PRODUCTOPS
Most recently, ProductOps also entered the Ops’ arena, although there is no single source of truth and definitions may vary, this comes from the Product School which is a solid reference:
“While a Product Manager owns the development of the product (aka, the person who Builds The Thing) a Product Operations Manager handles the day to day tasks involved with development (aka, the person who Makes It Easier to Build The Thing).”
In a nutshell: ProductOps puts an effort to streamline processes, execution, and decision making.
Ops and Design-Ops: similar but not equal
Each operational discipline has a slightly different focus area and it delivers business value in a different domain, however, all these ops put an effort to have an effect on these threecommon aspects:
– Processes
– Culture
– Technology
Ops practitioners manage processes and technology with an eye on developing the most effective collaborative environment and cultural context for the output to be impactful.
CHALLENGE #2
The key difference between most Ops and DesignOps is not so much in the WHAT, but in the HOW:
DesignOps consistently and subconsciusly apply Design Thinking and empathy to everything they do to ensure change can happen effortlessly and without frictions.
A lot of work for DesignOps practitioners is about streamlining empathy with users, improving internal and cross-functional collaborations, and acting as agents of change in the organisation to maximise value generation.
DesignOps and Design Thining
By reviewing the presentations of the key DesignOps conferences from the past 24 months, including the Rosenfeld DesignOps Summit 2022 and 2023 and the HS DesignOps events 2023 and 2024 there is one thing that stands out: each story, each narrative, and each case study is deeply rooted in Design Thinking and the story applies all key elements of design thinking: empathy, brainstorming, hypothesis generation, experimentation and validation.
The ultimate goal? Transform the practice and deliver tangible benefits to the design team and the organisaiton.
DesignOps practitioners often have a background in Design and they apply Design Thinking in their practice as a problem-solving framework, to the point that there is no need to call it out.
CHALLENGE #3
Design Thinking is part of DesignOps’ DNA.
And since DesignOps is about driving transformations within the design and R&D organisation to maximise cross-functional engagement models, good use of empathy and experimentation is key to ensure adoption and stickiness.
Design Thinking as the empathy-focused problem-solving approach is key to enabling organisational change through a participative and inclusive approach (see here) therefore, when designing a change, applying a Design Thinking framework is what often determines DesignOps’ success.
As DesignOps matures, its remit and its partners and allies evolve: it is not uncommon for DesignOps practitioners to collaborate and join efforts with their operational partners, such as ProductOps or DevOps, to streamline how innovation is generated and experiences are developed and delivered to the customers.
Design Thinking is what makes DesignOps unique.
What’s next?
If DesignOps’ goal is to operationalise the Design vision using Design Thinking to drive business outcomes, can Design Thinking enhance other operations to drive organisational transformation across processes and systems?
CHALLENGE #4
Can then DesignOps be a Design Thinking based approach to organisational operation efficiency?
So the question remains open as the implications are huge:
Is DesignOps just the application of Design Thinking to boost Design outcomes or is it a strategic operational function that applies Design Thinking to organisational change and efficiency?
Are we talking about DesignOps as an operational framework based on Design Thinking to enable organisational change or are we referring to DesignOps as the function that optimises design processes, trying to push design teams from Design Doing into Design Thinking?
CHALLENGE #5
Are the destinies of DesignOps and Design necessarily intertwined?
The answer to that question will determine if Design and DesignOps are deeply interconnected disciplines or if DesignOps can aspire to a broader scope within the organisation by leveraging the Design Thinking framework and providing a solid change management approach to other operational functions and ultimately, to the whole organisaiton.
Ps. These are the notes I presented as my opening remarks at the HS DesignOps London on March 1sr 2024.
Huge thank you to all for the feedback!
DesignOps: rethinking operations with design thinking was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
