Dave Malouf Interview on the Future of DesignOps

In recent years, design operations teams — a.k.a. DesignOps — have been embraced by businesses looking to scale their design production. They help grow and evolve design teams by operationalizing workflows and managing projects, budgets and hiring. Most importantly, they help improve the quality of the designs being produced by allowing designers to do what they do best: design.

But how does a company know when they’re ready for a DesignOps team of their own? Superside recently put that question to Dave Malouf, the man who essentially coined the phrase “DesignOps.” A consultant, coach and educator, Malouf is also a speaker and part of the programming committee of the DesignOps Summit. As Malouf put it, the question is less about, “what's the right moment for DesignOps?” It’s “how do you scale it?”

If you were to try to explain DesignOps to my mom, how would you describe it?

Your mom? Wow. I don't know anything about your mom. But someone asked me this the other day — what's the one sentence? DesignOps is everything that supports the practice of and the value that comes out of designing. That the value of a design practice comes out of the actions of designing and everything that supports that practice is the operations basically.

What problems is DesignOps meant to solve?

There's a host of them. The first is improving the craft and methods and process. So things like the best tooling, how to hire the best team, how to manage the best team, how to set up the right communication channels, how to do rewards and recognition for those teams that are most engaged in the work that they're doing. From there, it goes into more of the supporting stuff around the collaborative processes with cross-functional stakeholders, the general asset management workflow, delivery process stuff. It's about the culture that leads to the best practice of designing and about the governance, the policies and the way that those policies are used to make decisions that lead to the best designs. It's all of those kinds of components and then some.

What are the origins of DesignOps?

There's no one single starting point. I think that there's a lot of influences. When you look at DesignOps, I think, there's the producer/delivery manager role from the agency world, and then there's the program manager title, which very much came from the technology world — but they were both really focused on delivery. And then from a business ops perspective, you had teams that started adding the role of a chief of staff when they started scaling and started getting executives — that's another incarnation. And then in interior design and some industrial, architecture, and fashion design — where it was just physical things being delivered — that's where you see the earliest incarnations of the title “design operations” coming up.

The last one is, for me, business ops oriented. I was working at a company in cloud computing and there was a big DevOps component to our work. And so I sort of merged business operations and DevOps, and that's where I came up with the phrase “DesignOps” to describe what I was doing.

What conditions need to be in place for you to know that your organization is ready or actually truly in need of a DesignOps function?

DesignOps is really similar to the concept of user experience insofar as, if you don't do anything about it, you still have it. Right? If I don't design user experience, I still have an experience. I still have a quality to my user experience. It’s the same thing with DesignOps. If I don't do anything about it, I still have it. So for me, the question is less about, what's the right moment? But really how do you scale? You should always be intentional about it, whether you're a team of one in terms of your design practice or you're a team of 2,000.

How do you make an argument for formalizing a DesignOps function within your company?

The easiest things to start talking about are the numbers that matter to the business. The one that I like the most, depending on the scale of your organization, is attrition. It's a huge engagement indicator for your team. It's how well you're able to keep people, right? And it's a big cost. Every time you lose a person that's like $50,000 thrown away just on the recruitment and the loss of knowledge and all of that by the time you find and onboard somebody. So that's an easy one.

And then the ones that you can evangelize most easily with are going to be the things that your collaborators think about: responsiveness, optimization, efficiency, philosophy, things like that. They're all good things. I tend to not want my pendulum to swing too heavily in that direction because then we start getting into missing the point of DesignOps, which is about design quality.

Is it possible for a company to have an external DesignOps function?

You can do it in pieces. I still think you need to have someone who is on the inside who has skin in the game, like real accountability. But you can outsource program management. You can outsource procurement and some of the business ops relationships pieces. People do already, right? They're already outsourcing their recruitment or their other operational pieces through the COO's office.

So, what’s the future of DesignOps? What does it look like?

In the next two or three years, DesignOps is just everyone catching up. In the next 10 years, DesignOps goes away.

It goes, what?

It goes away. It just becomes part of the natural operations of an organization.

This interview has been condensed and edited for clarity.

Read More

Explore DesignOps in detail with our new report, The Future of DesignOps. From figuring out when you’re ready to start a team of your own to when it might be better to tap into external project management teams, like Superside, this eBook is your guide to streamlining creative workflows.

Click to download your free eBook.