Leading Design was one of the best events I attended last year. To be honest, that surprised me—I wasn’t sure how relevant it would be to me, but it turned out to be the most on-the-nose conference I could’ve wished for.
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:
- Styleguides, Pattern Libraries and Design Languages
- Design Systems vs. Pattern Libraries vs. Style Guides – What’s the Difference?
- Design Systems, Style Guides, and Pattern Libraries: Oh My!
- What’s the difference between style guides, pattern libraries, and design systems?
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:
- Why Design Systems Fail
- Tips for in-house teams in a free market software culture
- Putting your design system into practice
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.
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.