Seeing as the event was all about design leadership, there was inevitably some talk of DesignOps. But I noticed that the term was being used in two different ways.

Sometimes a speaker would talk about design ops and mean "operations, specifically for designers." That means all the usual office practicalities—equipment, furniture, software—that designers might need to do their jobs. For example, one of the speakers recommended having a dedicated design ops person rather than trying to juggle that yourself. That's good advice, as long as you understand what's meant by design ops in that context.

There's another context of use for the phrase "design ops", and it's one that we use far more often at Clearleft. It's related to design systems.

Now, "design system" is itself a term that can be ambiguous. See also "pattern library" and "style guide". Quite a few people have had a stab at disambiguating those terms, and I think there's general agreement—a design system is the overall big-picture "thing" that can contain a pattern library, and/or a style guide, and/or much more besides:

None of those great posts attempt to define DesignOps, and that's totally fair, because they're all attempting to define things—style guides, pattern libraries, and design systems—whereas DesignOps isn't a thing, it's a practice. But I do think that DesignOps follows on nicely from design systems. I think that DesignOps is the practice of adopting and using a design system.

There are plenty of posts out there about the challenges of getting people to use a design system, and while very few of them use the term DesignOps, I think that's what all of them are about:

Clearly design systems and DesignOps are very closely related: you really can't have one without the other. What I find interesting is that a lot of the challenges relating to design systems (and pattern libraries, and style guides) might be technical, whereas the challenges of design ops are almost entirely cultural.

I realise that tying DesignOps directly to design systems is somewhat limiting, and the truth is that DesignOps can encompass much more. I like Andy's description:

Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements.

Now, in theory, that can encompass any operational stuff—equipment, furniture, software—but in practice, when we're dealing with DesignOps, 90% of the time it's related to a design system. I guess I could use a whole new term (design systems ops?) but I think the term DesignOps works well ...as long as everyone involved is clear on the kind of DesignOps we're all talking about.

This was originally posted on my own site.

Related thinking

  • Viewpoint

Season one of the Clearleft podcast

Read the story