What is DesignOps?

DesignOps as a concept has been creeping into the mainstream for a few years now. The mission, ‘to amplify the value of design’, resonates with companies from 2 designers through to large design orgs. DesignOps is definitely growing as an industry, with companies such as Airbnb, Salesforce, and Shopify pioneering the area, and increasingly, defining what it is to the wider design community.

So, what is DesignOps anyway? While the nitty-gritty diverges, the common consensus is that DesignOps is all about increasing efficiency both within your product design teams, and with the way your product design teams interface with the rest of the company. In essence, DesignOps operationalizes shortening the delivery cycle of high quality experiences. The result? Designers spend less time doing non-design focussed tasks, so they can spend more time on their craft.

DesignOps is all about increasing efficiency both within your product design teams, and with the way your product design teams interface with the rest of the company

So, that nitty-gritty that I talked about? The detail of what DesignOps covers, varies wildly from place to place. Some folks focus on delivery, process and tooling, while others include org design, leadership, HR functions like hiring and management, and defining and maintaining culture as part of DesignOps’ function.

Where does DesignOps come from?

DesignOps owes a lot to engineering practices. Over the last forty years, software engineering has matured at an incredibly fast pace, largely due to the cost, size and importance of the engineering org in most organizations. This also means that a lot has been invested into trialling, refining and forging processes, structures and culture to ensure that everyone is working at their optimal capacity.

Pretty early on, Operations became a standard part of any engineering department, taking care of infrastructure, hardware requirements, QA, process refinement and just about anything that helped make the software engineers, and the company as a whole, faster and more efficient.

DevOps grew as a set of practices that were focussed on reducing delivery time in the software engineering lifecycle, with a strong focus on testing, and continuous integration and delivery. DesignOps was coined in 2014 by Dave Malouf, as a term to cover his tri-track delivery process, developed in response to Agile’s single-track focus on delivery. Dave’s suggestion was that instead of solely focussing on product delivery, we should be focussing on developing practices that focus on strategy, frameworks, and principles (Understanding), as well as building out requirements and validating the ideas (Discovery).

You can still see the mark that this definition has had on DesignOps (especially the Understanding track), but since then DesignOps has blown out to include three wider, distinct areas: business operations, people operations and workflow operations.

Business operations covers off what would be seen as bread and butter of department leadership, no matter what the area. Things like procurement, budgeting, legal, and recruitment/resourcing. People operations overlaps with traditional leadership roles, but also covers off what managers do: line management, career development, defining and maintaining culture, and team rituals. Finally, workflow operations covers off your tooling, governance, work process, and practice.

DesignOps in your Design Org

As with DevOps, the concept of DesignOps is more of a way of life than it is a specific blueprint for how to operationalize your design org. However, DesignOps as its own role (and increasingly, team) within a design org is becoming more and more prevalent. DesignOps as a methodology will naturally be about operationalizing the design team’s work, whereas for DesignOps as a role it makes sense to focus on the gaps that aren’t covered by existing functions.

The dual-track growth framework for designers has gotten a lot of traction over the last five years, and been adopted and popularized by the likes of Spotify and Facebook (as talked about in Julie Zhuo’s The Making of a Manager). The core concept is that once designers reach a certain level within a product org, they should split into focussing on a craft-based, individual contributor (IC) role, ultimately leading to roles like Principle, Staff or Lead Designer, or focus on management, leading to Design Manager, and ultimately, Head or VP of Design.

In smaller design orgs, it makes sense to spread the load of DesignOps across the different functions, with anyone in a management position bearing the brunt of the operations work. It’s also worth noting that while you have a small design org, the scope of impact of any operations work will be limited.

Once your org gets to a point where there are enough people that the people and business operations take up the majority of your Design Manager and Design Leadership’s time, it’s time to look at a third track. In my eyes, this is where DesignOps as a function steps in. The main difference to the previous definition of DesignOps is that this primarily covers workflow operations, with folks focussing on managing design as a programme, building and maintaining design systems and building and optimising design tooling.

But what does a DesignOps function do?

Another way of viewing DesignOps is that they are responsible for removing as much impediment from the designers who are focussed on crafting the product as possible. Giving them the structure, tools and constraints to allow them to create beautiful, usable features and products that serve the business.

With this in mind, there are four key ways that a DesignOps function can help improve the lives of their IC counterparts:

• Design systems – Building, maintaining and growing a design system to serve the product, and setting up robust systems for contribution and feedback
• Design process – Analysing, iterating on and documenting the internal design team processes and associated tooling
• Handoff process – Analysing, iterating on and documenting the handoff between design and other teams, from product to copywriting to marketing to engineering
• Design programme management – Managing the day to day workflows, rituals and processes to do with the design team.

While it makes sense that a lot of organizations will invest heavily in design systems and program management to begin with, looking at ways (and tools) to improve the two process pieces are key to a well oiled team. Design tokens are a good example of how tooling can improve the handoff process between design and engineering, cutting down on future design and development time, especially around speccing and handing off to developers.

What’s next?

As mentioned before, a lot of the focus so far on DesignOps as a function has been on design systems and effective program management. With DesignOps as a concept, the focus seems to be on org design and people ops. However, I think one of the biggest opportunities here is in how we can optimize the handoff process between design and other parts of the business.

Abstract launching their Notebooks product is a good example of someone trying to nail the dance between product, leadership and design. The tools to handle copy integration (especially when it comes to localization) are slowly but surely getting better, with Phrase providing a good first attempt at syncing with design tools. And, as mentioned before, design tokens are becoming more and more common (we recently launched the beta of our Design Tokens 2.0 in zeroheight), and the W3C Working Group are having their first vendor roundtable this month.

Aside from the handoff tooling, another key part is documenting how all of these processes work together. We’re increasingly seeing folks not only use zeroheight to document their components, styles, and principles, but also their processes, both to do with their design systems and their product practice generally.

I think we’re about to enter an exciting time in the maturity of product design orgs where we see more and more of these practices codified, shared and implemented. And hopefully, some time very soon, when you’re explaining what you do to someone at a bbq, you won’t have to explain exactly what DesignOps is because they’ll already know.