- • Historical convergences and/or divergences of design and neoliberalism
- • Design and globalization and/or nationalism
- • Neoliberal design ideologies in the context of international development
- • Race and racism at the intersection of design and neoliberalism
- • Discourses of innovation and “design thinking”
- • Design and labor and/or class
- • The coalescence of design and business in both the academy and industry
- • Conflicts and convergences between neoliberal design and modernist traditions
- • Indigenous design in the context of neoliberalism
- • Design, neoliberalism, and postcoloniality
- • Challenges to neoliberal design ideologies and practices
- • Neoliberalism and design pedagogy
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?
Original article at https://clearleft.com/posts/design-ops-a-new-discipline