DesignOps 101

11 min readJul 8, 2020

You’re having a coffee break with your colleague, who is suddenly talking about “DesignOps” as the new trend and you find yourself nodding your head while you’ve never heard of it.

Anything to avoid passing off as clueless, right?

My journey with this topic started with a simple post-it with “DesignOps” written on it, and my boss, smiling. “Here’s your big task, enjoy.”

After some months conducting research and running some interviews, I’ve been able to gather enough material to grasp what DesignOps entails.
Here is the synthesis.

Design…What?

It comes from DevOps

Development + Operations = DevOps!
A practice that emerged around 2008 to answer the need of having a quicker and more efficient development process.

DevOps is the practice of aligning software development, system operations, automation, and more to allow for continuous integration and deployment for the purpose
of continuous learning.
— InVision: DesignOps Handbook

Sorry, but what does it have to do with DesignOps?

DevOps and DesignOps are both responses to the same underlying phenomenon.
— Jeff Sussna, UX Matters

Same but different, DevOps led the way and DesignOps followed when Design eventually started to gain acknowledgment.

Not one single definition

If you start looking for a definition online, you might get confused by the number of answers.

Let’s compare that with factories.
Not all factories have the same manufacturing and production processes since it depends on the in-house organization.
Well, it’s the same with Design: each company would have its way to define DesignOps.

To state it more clearly, here are 2 common definitions:

DesignOps refers to the orchestration and optimization of people, processes, and craft in order to amplify design’s value and impact at scale.
— Nielsen Norman Group

DesignOps is the key to scaling digital product design teams with more efficiency.
— Dave Malouf, the Progression Podcast

Underlying common goal(s)

Even though companies differ in definitions, they have shared goals, the biggest of which: producing more.

It’s not about producing just for the sake of it but making it intelligent and efficient.

Companies are building complex high-quality products, and they have the expectation to deliver faster, thus produce more. To meet this goal, they need to create their own chain of production that will ensure the product’s quality, allow people to have a defined role, and guarantee that deadlines are met.

3 different meanings

The term “DesignOps” can actually mean three things:

The practice of design operations
The person or the team running the operations
A specific mindset.

Why, DesignOps, though?

Once again it’s all about the industrialization of Design.

The production rate is higher, the teams are bigger, so it becomes more and more complex to go to the final version of a product.

By industrializing Design, we keep up the pace with market expectations and allow more innovation.

Industrialism as taught us to treat large systems like machines. While these systems might be very complicated, if we can break them into their component parts and make sure all the components work, the whole system will work.
— Jeff Sussna, UX Matters

Starting small and assembling progressively ensures the big piece to be working while the opposite is often not true.

Amplifying the Value of Design

Dedicating interest, time, resources, and organization shows not only maturity in the company’s position towards Design but it helps Design increase its value both in-house and to the end-customers.

Let the Designers design

Now that Design gets to have a say, it often happens that designers end up being responsible for strategic and management work that will take up a great deal of their time, a time not available for them to design and do creative work.

In a lot of companies, designers would be the one in charge of:

Finding the tools,
Updating the licenses,
Overseeing budgets,
Planning meetings and workshops…

DesignOps aims at changing that by readjusting the balance to support the designers, protect them, and improve their creativity.

Good management practices

Doing so will also positively impact the turnover rate by retaining your talents and making them feel valued for their creativity and skills.

Many organizations expect their designers to wear many hats — project manager, cross-functional partner, creative leader, and logistical coordinator. However, these additional roles reduce the time your designer can devote to your product and users.
— InVision: DesinOps Handbook

Demonstrate the value of Design

Animation by Deekay

“Could you make this red a bit more orange my dear?”

Let’s be true. Even though Design has come a long way, some designers still face coworkers — or worse managers — thinking their job relies solely on choosing between blue and green. There is still a lot of work to do evangelizing the importance of design within the company. DesignOps works as a protection cloth around designers to prove their value.

By thinking “Operations” you come up with tangible data, metrics, statistics that will end the debate around Design’s value. People never question numbers.

Craft Specialization as an outcome

You can either see it as a consequence or a benefit. Or both.
Since Design is organized around processes and people, it inevitably leads to more craft-oriented jobs according to the people’s expertise.

Pretending you are expert on everything, does not mean anything.

By definition, having expertise equals being specialized. And being specialized is good! In a competitive world, we can feel the urge to acquire a range of skills that would compare us to the mythical 5-legged sheep. And since we all fear being put in a box doomed to repeat the same over and over again — choosing expertise can seem scary.

But you can see it another way. If the company’s culture allows you to occupy this expert position, it’s because they believe that bringing experts together will not split people into clusters but create strong synergy.

At the time we were graphic designers, we did a little bit of everything. […] I think that [Craft Specialization] is a good thing because you can’t be good at everything.*
— DesignOps at Engie (*translated from French)

Now that Design evolves, we do understand the stakes of each craft and can properly assign talented people. Of course, it would depend on the company’s stage:

With DesignOps comes Craft Specialization. And that’s not always possible when the Design team is small and at an early stage. The requirement for specialist on specific Design roles often comes when the organization itself scales and matures.
— InVision, DesignOps Handbook.

This is of course true, but I was surprised to see that a minority of small companies do bring in DesignOps experts from the start to make sure they have smooth processes early on.

On that note, how and when do we do DesignOps?

Guess what? It’s not new.

It just hasn’t been labeled as such. Here are quick examples of things that you are probably already doing without knowing they could be called Operations:

Having a list of resources and tools,
Planning regular meetings, such as Design Critics,
Creating asset libraries,

See it as everything that will help you be more efficient.

The question is not when do you start having design operations but when or how do you start becoming intentional about the operational part of your design practice.
— Dave Malouf, Progression Podcast #16

The intention that you put behind is the very trigger point.

So taking your first steps in DesignOps, I think is trying to see why you want to do it. What problem do you want to fix: is it because someone else has a DesignOps function or is there a problem somewhere.
— DesignOps at Air France

It starts with a challenge

You don’t wake up one day and say, “I’m gonna do DesignOps now!”.
Everything starts with a problem to overcome, a challenge to take on.

The practice of Design Ops often emerges from a single individual — somebody who has noticed inefficiencies in the current system, and has hacked something together in their own time to reduce repetition.
— Clearleft: DesignOps, A New Discipline.

Here are some real case challenges that could come up in a company and that would trigger such initiatives:

Time-consuming onboarding processes
Communication and organization issues among product teams
Multiple products and multiple Design Systems not defined as such
Higher demand, increase of the production rate,…

Design System as a turning point

Coming up with a Design System that reflects not only the brand but also users’ expectations is a big task that can immediately improve the product team’s velocity and consistency. But it’s a long project that will need transversal collaboration among teams and a defined design vision, both creatively and strategically speaking.

But how do we fit DesignOps in a company’s organization?

There are a lot of components within DesignOps, and what an organization chooses to select — or to pass on — should depend on the current need and most poignant pain points of that organization.
— Nielsen Norman Group

There’s no such thing as a general DesignOps checklist with mandatory steps. See it as a big basket of best practices where each and everyone picks and chooses according to their situation.

Start by defining the scope

Some questions to help you do so:

Is there a Lead Designer/Head of Design?
Are there PO/PM, if yes, to which teams do they report?
Is the company ready to dedicate an entity of department to Design?
Does the challenge to overcome require us to tackle several or only one part of the organization chart?

Usually, structures have a DesignOps come in because they are aware of the challenge ahead of them but have no idea on how to tackle it. From there, the rest will mostly be observation and change management.

What does DesignOps usually entail?

Remember: there is as many DesignOps structuration as they are companies.

Here is an example inspired by the InVision Handbook, but no matter how you call those topics, they all correspond to pretty much the same:

Providing and having tools that help the team build faster, collaborate more and iterate
Having a well-defined organization, everybody knowing their roles to avoid wasting time
Restructuring or building from scratch a workflow for projects with steps, methodology, deliverables, etc.
Caring about members of the team as individuals with valuable skills to make them grow and shifting the turnover rate.
Managing all of it and still evangelizing the value of Design to other teams. Can be done via events, workshops, conferences, etc.

Who is involved with DesignOps?

Simple answer: everybody in the product design chain.

UX/UI Designers/Product Designers/Visual Designers
Service Designers,
UX Researchers,
Content Strategists,
Copywriters / UX writers
Product Owners / Product Managers

DesignOps applies to anyone using user-centered and design-thinking processes to solve problems.
— Nielsen Norman Group

What does it mean to be a DesignOps?

We talked about DO as an organization and a mindset, but what about the role?

Who is the DesignOps person?

I often tell my teams: ‘help me to help you’. *
— DesignOps at Engie (* translated from French)

To him, being a DesignOps equals being the designers’ helper.

What are the DesignOps’ roles?

Play the pivot role between Designers, Product Managers, and Developers
Manage everything on the logistic side of things (hardware, software, licenses,…)
Set up rituals within a defined methodology (workshops, daily standups, meetings, design critics,…)
Remain curious about the technology trends
Overview of the hiring of recruits and take care of their onboarding

The simple thing as preparing the desk for your new recruits’ first day can already be considered as DesignOps because it helps to make them operational to do their job.

Which types of challenges?

According to the company’s maturity, these challenges will be more or less complicated. Non-constructive criticize can arrive quickly, towards a support position such as DesignOps or the designers themselves.

Convince the hierarchy of the value of our role although we don’t produce
Stand the designers’ grounds
Create a community between roles and build team spirit
Evangelize Design in the company

People over processes

The main focus is on people, even if producing is important, people making it possible are all the more so.

[DesignOps] also protects the design teams’ health by preventing burnout. By dedicating time and space for feedback sessions and by defining clear objectives, the designers feel that they are more valued and not running after unclear expectations.
— InVision, DesignOps Handbook

All in all, at this point it’s “just” good management practices. But it’s only efficient if the processes behind support it.

The way I look at it is that, velocity comes from the well-being of people. What’s important to me and what still motivates me today, […] is really that people feel good, and from there, if people feel good, then the velocity comes out of it.*
— DesignOps at Engie (* translated from French)

Is a Designer’s Background mandatory?

Well, not necessarily. However, here are some key skills that will make you a good candidate:

Good understanding (if not experience) of what is Design and how designers work
Knowledge of management practices and methodologies
Strong communication, acculturation, and pedagogy soft skills

You want someone who can build cross-functional relationships while representing design, and who understands the design process.
— InVision, DesignOps Handbook

What makes a good DesignOps

To sum up:

Organization: build a solid structure on which the product teams can rely
Empathy: understand your end-user — the designers
Passion: To push Design one-step further

Quick bonus: DesignOps & Agile

During my research, I saw that there is a lot of connection that is being made between the two.

Depending on the school of thought some would say:

No, DesignOps and Agile are completely different, we should not merge them.

While others would say:

There are good things in both that can be similar, let’s mix and match!

So if we sum up very briefly the main similarities and differences people make between the two, that would look like this:

Similarities

Methodologies: DesignOps borrowed a lot of things from the Agile Framework
Rituals: daily stand-ups, retrospective — helps create a continuous link among teams
Sprints and iterations: the iterative logic can be found in both.
Mindset: the general way of thinking relying on flexibility and efficiency.

Differences

Organization: initially, a Scrum Master works with Devs where DesignOps works with Designers. Both are different teams that need to be managed as such even if their collaboration should always be close.
Purpose: a Scrum Master’s first leitmotiv is believed to be the velocity and some say the DesignOps’s one is more people.
Job title and place in the chart: you can be DesignOps and work with a Scrum Master or a Scrum Master can be replaced by a DevOps,… this depends on what each company expects behind a certain job title.

Thank you very much for reading! If you liked the topic, see below for sources!

To go further

Here are all the sources I used for this research project, feel free to use them to dig further on the matter!

Articles

Videos

Books

Kate Battles, Meredith Black, Dave Malouf, Collin Whitehead, and Gregg Bernstein (editor). « DesignOps Handbook. » (download — or Audio version on Soundcloud)

Podcasts

Progression Podcast: #16 Dave Malouf on Design Ops and the power of Speaking on stage