Like all new terms, it’s a way of describing an emerging set of activities and behaviours. These activities aren’t necessarily new; we’ve been practicing elements of Design Ops since we created our first design system and modular code library way back in 2008. So it would be easy to balk at the term, seeing it as little more than an unnecessary buzzword. That’s not my reaction.
While many in our industry dislike the use of terms like UX Designer, Interaction Designer and Product Designer, preferring to drop the qualifier in favour of the more generic Designer, I find the specificity useful. I personally believe in the power of language to encapsulate complex concepts into a small and sharable package, making them accessible to a much wider group of people. The creation of new terms like Design Ops allows for the democratisation of these emerging ideas.
So what exactly is 'Design Ops' then?
Well, as the name suggests, Design Ops is somewhat related to the field of DevOps, which started gaining traction in our industry towards the end of the last decade. Back in 2008, there was often a separation between the people who wrote the code and the people who looked after the infrastructure it was deployed on. As agile started to take hold, and continuous delivery became the norm, this gap started to narrow. In order to increase the speed of delivery, teams required multi-disciplined individuals who could bridge the gap between the production environment and the server, allowing their code to be deployed faster and more efficiently. DevOps was born, and over the last decade, the field has gone from a few talented hackers to a profession with its own tools, techniques and culture.
The field of Design Ops is the result of a similar set of pressures. The rise of agile development has necessitated much tighter integration between design and technology, while recent investment in design—most notably by the big five tech companies—has highlighted the need to figure out how to deliver design at scale. Design Ops is essentially the practice of reducing operational inefficiencies in the design workflow through process and technological advancements. In short it’s about getting design improvements in the hands of your users as quickly and with as little friction as possible.
At first, the effort was focussed on low-hanging fruit. The creation, maintenance, and socialisation of modular design systems and component libraries. These libraries helped encourage consistency, reduce waste, and allowed teams to produce work at a faster rate. The next big challenge was to fit these tools into the design and development workflow, which is why we’ve seen the creation of tools like React Sketch app by the talented Design Ops team at AirBnB. The other big challenge is how to reduce—or even remove—the distance between design and deployment. This is something we’ve been trying to solve with our own Fractal application, which aims to create a bridge between your design language and your technology stack.
It’s worth noting that while Design Ops and DevOps are the result of similar drivers, the practices are considerably different. DevOps obviously has a much stronger bias towards tools and server-based solutions, while Design Ops tends to focus more on the process and operations side of the equation. Some argue that the similarity in names is therefore confusing. I believe this similarity is actually part of its power.
Where does it work best?
While design is starting to get a seat at the table, it’s arguably still a highchair. It’s vital for designers to use every political tool at their disposal. In most organisations, IT has a much bigger voice, and holds more influence than design. This is partly due to the maturity of the field, partly due to the larger head counts in IT, and partly due to the budgets they command. Pitching your language and values to a sympathetic technology department makes a lot of sense. After all, if your CTO understands the value of DevOps, how could they possibly not see the value in Design Ops? Especially when Design Ops will make the lives of their tech teams infinitely less messy and more productive.
It’s worth noting that Design Ops isn’t for everybody. It’s definitely not required at most agencies or single-product companies that do a redesign every 3-4 years. But if you work in a relatively large design team, inside a company that practices agile development and continuous integration, there may be an opportunity for you here. In these environments, 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. Either that or it’ll emerge from the design language team, as they remove the friction and pain points slowing down adoption.
Ultimately, if you’re trying to deliver design at scale, investing in a small Design Ops team will help you deliver better work. Who wouldn’t want that?
Since then we've been working with design teams to help them level up in Design Ops and we've started to [see some universal themes and challenges](https://clearleft.com/posts/a-theory-for-design-ops).
We’d love to hear yours - tweet us @andybudd and @clearleft
