I’ve always been on the fringe of people in the design community who love how design works more than they love designing. Throughout my career as a designer, I have leaned more toward process over practice, and in some circles I was made to feel like a pariah because of my fixation on semantics (resulting in my last name being affectionately turned into a verb by colleagues: “maloufing”).

This focus on process took me to Queens, New York, in November of 2017, where I joined nearly 300 people to learn, share, and work on formalizing a new aspect of design practice management, DesignOps. The DesignOps Summit marked a turning point, as design operations had begun to emerge across the design industry. But for me, it was also the culmination of a very long, personal journey through design.

What makes design valuable

Let’s go back to the start. Back in 2005, I took classes in a design school for the first time. They were continuing education courses in industrial design, and through them, I was awakened to what design really is, and what properties make design practice so uniquely valuable: serendipity by design, a culture of interruption, and deconstructive creativity.

Serendipity by design is the cultural core of a design studio. In a pre-digital studio, everyone’s work is externalized, visible, and transparent. This means that ideas are juxtaposed purposefully, passively, accidentally, and serendipitously. These forced interactions that give light to new ideas are core to how design works.

The culture of interruption is vital for design to reach its full potential. These interruptions come in the form of instruction, criticism, and comparison, to name a few.

When designers envision a rough idea of a whole system, only to tear it apart and rebuild it, they engage in deconstructive creativity.

These three properties of design practice contribute to a high-functioning design team with quality outputs. Add to that, the advent of user-centered design, and design practitioners also function as chief advocates of human understanding and empathy within an organization.

From design school, I moved to an industrial design studio and then to a design teaching position in the industrial design department at the Savannah College of Art and Design. That experience introduced me to systems design thinking in service design, and design for sustainability.

What I didn’t realize was that while on campus, immersed in the properties that make design so valuable and unique, the agile approach to software development was subsuming those very practices. I knew of agile, but I wasn’t prepared for its impact on the design world.

Anti-agile, pro-design

Agile is an iterative software development approach, where cross-functional teams collaborate to set requirements and solutions for a given project. As explained in the Manifesto for Agile Software Development:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

In those five short years while I was on campus, agile became the norm in product development, much to the detriment of designers. What I saw was design practice taking big steps backwards—vision, exploration, deconstruction, associative thinking, and interruptions were suppressed in favor of working the way developers work:

This subjugation of design to engineering in agile makes sense for engineers, as agile fit their culture. Further, agile methods have led to great outcomes, making it hard to refute their value. Companies like Amazon, Google, Netflix, and Facebook were poster children for agile method success. Designers were in the uncomfortable position of acculturating into the agile mindset lest their positions become irrelevant.

Here’s what I saw in this culture optimized for engineers:

  • Designers isolated from other designers, and not working out in the open
  • Design as a production role instead of a strategic role, with designers often asked to perform superficial visual cleanup
  • Design hiring practices based on engineer hiring practices
  • Designer career paths being mapped to engineering career paths
  • Design tools misaligned to the tasks at hand, as well as design tools chosen for integrations with developer tools rather than design functionality

In my first job after leaving SCAD, I was in the awkwardly-titled role of head of interaction design at Rackspace. This was my first “design operations” role, where my job was to make design—meaning my designers and our product outcomes—better. I discovered that the metrics of success for our partners in development and product management differed from those of design, leading to the shipment of subpar products. And therein was the problem: developers and product managers measured success by whether a product shipped on time, and not whether the design satisfied user needs.

In my role with Rackspace, I learned about DevOps and Lean Startup. DevOps is the practice of aligning software development, system operations, automation, and more to allow for continuous integration and deployment for the purpose of continuous learning. Lean Startup mitigates business risk by focusing on small, tightly-scoped bets, called experiments, that lead to determining whether a product direction is valid or not.

The combination of the DevOps and Lean Startup methodologies made people see agile in a new light, and agile product development cycles started to incorporate learning and quality. Speed was no longer the goal, but rather a byproduct of automation. Learning iteratively and learning quickly were brought together.

Everything changed for me in 2014 when I was first introduced to dual-track agile. This added discovery to the agile method; while one track focuses on delivering the value of an idea to users, a separate track is dedicated to actions based on learning. Dual-track presented questions about the role of the designer: how exactly do they work with their peers in this environment, and how could this new framework allow designers to incorporate their own methods of discovery and exploration?

The answer: add yet another track. I created tri-track: parallel to and integrated with discovery and delivery is a third track, understanding. On this track, we align on a strategy for building the “right” thing based on user needs and team insights.

Given my exposure to DevOps and my close working relationship with IT operations, it was a natural next step for me to christen tri-track as a new “thing” called design operations. Though it was still a very loosely formed idea when I developed it in 2014, I felt I was onto something.

Since that point in 2014, I’ve been on a journey from the loose idea of design operations to the legitimate practice of DesignOps. Along the way, I discovered peers with whom the idea of DesignOps resonated, and their stories resonated with me as well. This journey culminated with the DesignOps Summit.

Why DesignOps now?

My mission for the practice of DesignOps is to amplify the value of design. Design as a practice requires a singular focus on the operations that maintain the best interests of design and an organization’s business.

From my conversations with and observations of a host of organizations around the world, I’ve come away with four core factors contributing to DesignOps-oriented leadership roles and practices as design teams mature: scale, people, expectations, and inclusion.

Organizations are scaling at every turn:

  • Teams are growing larger
  • Companies are opening new offices (and forming distributed teams)
  • Design teams are supporting more parts of an organization
  • Companies keep spinning up new business units
  • Design solutions are growing in complexity
  • Organizations are integrating more and different types of design practices
  • The tools used for design become more complex in proportion to the systems being designed

People are a priority:

  • Great designers are a rare commodity, and they know it. This makes recruiting more difficult than days past
  • Product organizations are growing more complex, which makes structuring teams difficult
  • Design isn’t a job you just show up to. Designers need to be developed, advanced, promoted, rewarded, and recognized

Expectations are sky high:

We want our flying cars, meaning we expect that better experiences should have arrived by now. We insist on better design and better design outcomes.

Diversity and inclusion take work:

Diverse teams are great for design, but getting there isn’t as easy as saying, “Let’s hire more diverse people.” People need training and practice to work on diverse and inclusive teams, and this requires coaching that’s new and different than that of previous generations of design organizations.

So, what is DesignOps?

Every institution has at least one goal. And there are required activities to achieve that goal. If the goal of my wall company is to build brick walls, the laying of brick is the primary activity. For my taxi service, my goal of moving passengers from a point of origin to a destination is achieved by driving the taxi.

Operations are the elements that facilitate high-quality instances of those activities with minimal friction. Operations includes the tools and infrastructure required to complete the activity. Using the taxi example, a taxi service requires an automobile, fuel, and roads. The meter, map system, and dispatcher all make up the ecosystem of the taxi experience.

Like a taxi service, design practice requires a collection of balanced activities that support the work.

We talk about craft in design—sketching, pixel movement, and critique. But more generally, craft is how we create the plans for the forms and shapes we imagine will solve problems and create positive change.

These crafts are usually encapsulated inside of methods. Any given method can use different crafts to target the same success.

Finally, methods fit specific processes. Processes communicate the shared path to achieve success. The classic “four Ds of design” are an example of a process: discover, define, design, and deliver.

DesignOps, then, is everything that supports high quality crafts, methods, and processes.

To illustrate, let’s imagine you’re tasked with completing hand-drawn wireframes. What do you need to accomplish this task?

Well, you need tools, like a collection of drawing apparati. Maybe this is a #2 pencil, or perhaps a Staedtler .5mm roller. You might want to incorporate different colors and even different thicknesses. A ruler or a set of stencils might help, too. You’ll also want something to write on—a sketch pad, maybe a with a printed grid. You have many options, but you’ll need some tools.

You’ll need infrastructure to support your drawing. A desk and adjustable chair will help. If you draw often, a tilting desk that reduces stress would be nice. Where do you keep your collections of drawings—how are they organized and found later?

Let’s back up and ask even more questions: how do you even determine what to draw in the first place? Who decides your workflow? When you’re done, where do you submit your drawings, and who decides if they’re good enough? How is “good enough” defined? What if your drawings require corrections: who decides this, and who performs the corrections? These questions could go on and on.

How many people really need to work on these drawings, and how are they organized? At what point do you decide to hire more people, and how are the new people brought into the organization?

How do you get paid for your drawings, and when can you take a vacation (and for how long)? What type of governance is in place for time tracking, or for engaging with customers, or for grievances between parties when there are disagreements?

Together, tools, infrastructure, workflow, people, and governance is operations.

Finally, how we manage our particular operations is our culture. These are the values, principles, and mission that drive an organization.

How DesignOps works

A DesignOps practice is made up of three overlapping lenses, or areas of focus. These areas overlap, but the specific overlaps and practices are often influenced by the leadership at the time the DesignOps practices were put in place.

My introduction to the work of DesignOps was through the lens of Business Operations. My executive leader at Rackspace had a keen eye for how important business operations was to his team’s success. I saw him in as many meetings with finance, IT, and procurement as I did with marketing, product, and engineering. He took change management seriously, which manifested in a very strong communications channel for the team.

This business focus advantaged our team over others at my company. We got Macs when no one else could, and tons of whiteboards. We were able to reserve studio space. We had a special career track with HR, and more. A focus on business operations leads to the budgetary and political capital to facilitate design. In a DesignOps organization, a chief of staff is commonly in charge of business operations.

Another area of focus in DesignOps is People Operations. In my career, I saw what a difference having a defined and clearly communicated career path could mean to a design team. Conversely, I saw how an organization’s “one size fits all” approach to employee development can deflate team morale. Design teams need the support, rituals, and defined expectations that a dedicated focus on people operations can supply. Community leaders or practice leaders often run the people operations in a DesignOps organization.

Lastly, Workflow Operations is an area of focus that I sometimes call “Product Lifecycle Management Operations.” A program manager is typically tasked with this area of focus, which focuses on the flow of production within design and research teams, and on the integration of design practice with the other product lifecycle roles—development and product. Systems that support project intake, assessment criteria, and project management of design, tools, and infrastructure all fall under this lens.

In the next chapter, DesignOps Scenarios & Models, Collin Whitehead shares details about the unique operations models in place at Dropbox, right after he presents some scenarios when DesignOps might make sense for your organization. Later, look for Meredith Black to talk more about the operations that support design at Pinterest in Putting DesignOps into Play.

Dive in

This DesignOps Handbook presents the unique experiences, best practices, and lessons learned from leading DesignOps practitioners at some of the most design-forward companies in the world. DesignOps is both emerging and emergent. We authors don’t necessarily have all the answers, but we do have a strong set of principles and perspectives that we hope become valuable to you and your design organization.