An Introduction to Design Operations

If you’re reading this post, chances are you’re aware of the term “DevOps”. The term “DesignOps”, however, is probably not as familiar. You might try to connect DesignOps to DevOps in order to help you decipher its meaning. And you wouldn’t be entirely wrong, but you’d only be looking at the tip of the iceberg.

Design operations (“DesignOps”) is a growing area of concern for design teams seeking to help their teams increase the value they produce for their host organizations and that organization’s customers. As this is a burgeoning area of interest, inconsistencies in the usage of “DesignOps”, both as a term and as a practice, still exists.

In this blog post, I present my own thinking around DesignOps, which has been highly influenced by growing conversations among design peers from organizations like Autodesk, Uber, Airbnb, Pinterest, Expedia, and even non-technology companies like CapitalOne, Royal Bank of Canada (RBC), and GE.

Developer and Designer Tools Aren’t (Always) the Same

If you’re a developer, you code. You might write code in TextEdit or Notepad and use FTP, or you might prefer editors like Emacs and vi. You can then start to add in other tools like an IDE, version control, or data repos. And you can eventually layer in a CI system and add issue tracking and automated testing. Each one of these layers of tools is meant to somehow make you better as a coder and more valuable to your organization. The choice of tools one uses is an operational decision.

Operational systems, which are made up of processes, practices, and tools—like Agile, project management software (JIRA, etc), and quiet spaces and collaborative spaces—exist to make you as a developer more productive, thereby improving your output. All of these things aim to make you better at doing your craft: coding.

In the design world, we contemplate similar things. Some operational systems support the design process itself; others support cross-functional collaboration with engineering to ensure design intentions are executed as closely as possible to what the design team had in mind. The last point in particular is the driving force behind design operations: how we collaborate, communicate, hand off deliverables, and partner with engineering has become a central part of how DesignOps evolved.

While many organizations have operationalized their design teams by adopting the same tools developers use—JIRA, GitHub, or Confluence, for example—these decisions don’t account for the different tools and processes unique to the designer workflow. As design teams scale, using development tools and processes for design has the unintended consequence of diluting design value. Designers don’t use IDEs; they use graphic tools, and not even a singular graphic tool. Designers don’t share or collaborate on code via text files in open-source environments; they use a mix of vector and raster graphic formats that are often created in closed, proprietary systems. Designers don’t iterate the same way developers do (well, not all designers, and they shouldn’t). They’ll explore multiple options at almost every stage of the design process. The concept of “forking” won’t scale when looking at 10-20 alternatives of a single microinteraction in the same file where 5-10 alternatives of a layout are managed.

At the same time, the growing trend of creating design systems sometimes forces designers to work in files where they might have to interact with code on some level. These are usually meant to be points of interaction between designers and developers. As design systems are made up of components written with a mix of CSS, HTML, and JavaScript, using standard version control, issue management, and even Agile project management tools starts to make more sense.

This creates a new type of complication for designers, where some operations use one type of system and another part requires something else entirely. The good news is this pushes designers to be more cognizant and intentional about how they use those systems, especially those within the direct lines of sight and communication of developers.

Organizing Design Teams

Using different systems to manage assets is but one aspect of design operations, and operations as a whole is but one aspect of making individuals and teams get better at their craft. Human resource management is another important consideration for teams who want to amplify their value. And similar to the asset management areas of operations, different organizations will find different ways of managing and organizing their design teams.

For example, many design teams centralize their workers in a single design group, assigning members to projects while still directly reporting to a single design leader. Other organizations do the opposite: designers are hired to work directly within project teams, and “guilds” are created to help manage their specific design needs.

In summary, different organizational and team cultures require different solutions, which depend on many factors. And when accounting for other aspects of operations such as running design systems, design processes, and even research practices, DesignOps gets significantly more complex.

Resources

We’ll share more insight into DigitalOcean’s specific DesignOps philosophy and processes in future blog posts. In the meantime, you can read more about DesignOps at Amplify Design.

If you’re in NYC, join us for the first-ever conference on the topic of DesignOps this November 6-8 at the Museum of the Moving Image, called the DesignOps Summit. DigitalOcean will be there and your team might find value in meeting with a broad group of people who are interested in cultivating an operational mindset to amplify the value of their design teams. We hope to see you there!

Dave Malouf is the Director of Product Design at DigitalOcean. Dave’s 25+ year career in design includes enterprise, agency, and consumer spaces. He is a founder of the Interaction Design Association (IxDA) and has founded the Enterprise UX and the Design Ops Summit conferences. ave writes, speaks, and teaches around the world. You can find Dave talking about design, design leadership, and design operations on Twitter @daveixd, LinkedIn, and on Medium.