Late last year we hosted our second Design Leadership Breakfast, with two panels debating in front of 70 design leads.

Jon Aizlewood
Jon Aizlewood
23rd January 2020

While the first panel dived into the role of research and the rise of ResearchOps, the second panel shifted into DesignOps, with candid input from Samantha Fanning (Head of Digital, University College London), Dan Saffer (Product Design Lead, Twitter), Daniel Souza (Design Operations, Babylon Health) and Andy Budd (Clearleft).

Four panellists and Jeremy comparing in front of a blue screen

What is DesignOps?

We first started talking about DesignOps back in 2017, and since then the function has evolved and matured. At Twitter, Dan sees it as ‘the religion and rituals around design practice which support design’. Similarly Andy Budd often refers to Dave Malouf’s excellent analogy:

DesignOps are the grease, rails, and engine that make design’s processes, methods, and craft as valuable as possible.
Dave Malouf Sr Director of Strategy and Operations, Northwestern Mutual

For more traditional companies like UCL, centralising some of the ‘less fun’ processes has cultivated a belief that designers are freed up to do the ‘more interesting stuff’. At rapidly-scaling companies such as Babylon Health, DesignOps has transitioned from a buzz word into the very core of what they do. As Daniel put it, ‘…organisations at scale have many different people working in different ways, across different design teams, DesignOps at Babylon

  • enable visibility
  • enable workflows
  • support design, content, research and branding teams to design at scale with clarity.’

It was interesting how DesignOps is now its own stream of onboarding at Babylon, with DesignOps tailored to each discipline alongside the company and team onboarding. This has ensured new team members start working with a clear understanding of standards, their design system, and cultural processes like how to join and participate in design critiques.

According to Andy ‘…as teams scale, things slow down. A lot of things that design leaders hate doing emerged. The need to create a role to own things like performance reviews, onboarding and recruiting became clear. Without a DesignOps function, 80% of their work was becoming recruitment.’

Operationalising into a central function brings efficiencies at scale.

Globally distributed teams result in even more complexity. With people in various offices, there is a high level of noise. The challenge is trying to maintain the cohesion. At Babylon, DesignOps delivered more mental space and freed more available time to allow for deeper innovation.

How embedded is DesignOps?

Embedding DesignOps doesn’t happen overnight. UCL introduced a DesignOps mindset via training, by paying for everyone to have whatever research/UX/design training they need. For UCL it’s not about forcing people into that role but to increase understanding and respect of the processes across the business.

For digital-first companies like Twitter where research, design and developers sit together in teams. The product team lead/manager remains responsible for collaboration needs between teams, whereas the DesignOps function is focused on the individual and organisational needs (such as design systems). For Babylon, their design system has been a practical way of delivering the value of having DesignOps in the first place. This has not only helped them make sure the right resources and energy are in place but has also played a role in building a community around it.

Are we really there yet?

One thing that has become clear through our work and events at Clearleft: there are constant improvements to be made. It’s not about the destination, it’s about the journey.

Looking at our engineering partners, we can learn a lot from the VPs and CTOs in tech who’ve implemented successful DevOps functions. We can strive to apply their learnings to the growing DesignOps movement within the teams of our clients.

Ironically, the design industry itself has created a few blockers to DesignOps. Twenty years ago design was craft-based, operating at a human-scale and through emotion. We’ve since industrialised it as a way to scale design for the sake of conversion and KPIs. The processes and outcomes allow us to take small 1 or 2-pizza teams and turn them into high-functioning design outfits without sacrificing quality or consistency.

However, are we de-skilling people through the desire to scale? Are we creating a sense of learned helplessness? Are we forcing a senior designer — working in an optimised and systemised environment due to DesignOps — to no longer worry about divergent, problem-solving? Do they now focus only on their ability to ship? Is DesignOps effectively neutralising a designer’s skillset?

A message often shared at our Leading Design events and retreats: design leaders have felt like they’ve hit a glass ceiling. All the power they thought design once had has now been lost to the VP of Marketing, or Product, where design increasingly becomes a delivery function. At Twitter, Dan found that Product has a lot of power, and Product and design often wrestle around the overall product vision (traditionally called design strategy). Who controls what, who defines the problem space, and who plots the direction of travel is often a source of contention.

The benefit of DesignOps

DesignOps allow us to take away all of the administrative, operations-based work designers find themselves doing, and systematising it. It allows them to focus more on the actual design part of what they do. It’s about getting as much value out of the design team and designers as possible while minimising waste and maximising scale, consistency and efficiency.

If you’d like to discuss how we could help you scale design get in touch.

You can sign up to find out about our next Design Leadership Breakfast panel here