DesignOps Handbook
01

Introducing DesignOps

AMPLIFY THE VALUE OF DESIGN


by Dave Malouf, DesignOps Summit and IxDA

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.

DesignOps Handbook
02

DesignOps scenarios and models

MODEL STRUCTURE


by Collin Whitehead, Dropbox

Going Hollywood

Sometimes I wish I had a simple answer to the question, “What do you do for work?” Instead of being able to say “I’m a tax lawyer” and move on with the conversation, I answer “I’m a design producer.” This usually leads to a response of, “So… like a movie producer?,” which is not far from the truth.

The craft of being a producer in the creative world is similar to that of a movie producer. Filmmaking is one of the most logistically complicated creative workflows in the world. Naturally, this discipline helped to introduce roles that maintain the creative integrity of a director’s vision while working to coordinate large teams against tight timelines and budgets.

As film industry talent spilled over into commercial advertising, broadcast producers followed. Then as advertising and design agencies grew, more and more types of producers were brought on, each with their own craft discipline. Broadcast, print, interactive, experiential, design, and even integrated producers who spanned multiple mediums began to support creative teams.

Nowadays, the role of DesignOps is becoming more commonplace. DesignOps teams help to forecast work, manage resourcing, drive the day-to-day project flows, oversee budgets, support team health, and basically facilitate anything that allows creative teams to focus on what they do best. Companies are beginning to understand the value of design, and are investing in the role of DesignOps to maximize design’s value and impact.

I began my career as an interactive producer at Goodby Silverstein and Partners. The timelines were insane, the clients were demanding, and my production teams were trained to “yes, and” every creative idea that landed on our laps.

An ad agency was (and still is) a great proving ground for a producer; I was often tasked with scheduling and budgeting unrealistic and impossible ideas from teams of art directors and writers, with the expectation to never say it couldn’t be done.

I came away from the ad agency with some incredible experiences and came to realize that what mattered most in my role was not to fight just for the creative team but to build a process that would protect the integrity of the creative team’s work.

As I transitioned from an agency to a startup consultancy to in-house DesignOps at Dropbox, many aspects of my work have remained the same. However, unlike my time at the agency, where I sometimes felt I was producing creative work for its own sake or for awards, I now clearly see when and how DesignOps can serve and impact both design teams and the businesses they serve.

When is it time for DesignOps?

The craft of a DesignOps team boils down to process. When you have a team responsible for process, it lets every other team focus on their respective crafts. It can be hard to gauge when to ramp up a DesignOps function, but I’ve seen three scenarios where it might be time:

  1. Craft specialization: it’s no longer feasible for roles to blur
  2. Operating a design team at scale: it’s no longer possible to keep everyone in sync
  3. Safe harbor: designers need protection from the grind and thrash of creative development

Craft specialization

In the early stages of a design team, designers and other team members wear many hats. The roles and responsibilities are blurred in a persistent “all hands on deck” approach to every problem. For small teams, this is often the fastest way to work together—the workflows, stakeholders, coordination, and communication are all easy enough to keep in check, and everyone is in sync.

At this limited scale, designers manage their own project intakes and timelines, as well as other tasks outside their own design crafts. At this stage, while teams are small, DesignOps functions don’t make a lot of sense; it would likely take more work just to keep a DesignOps person up to speed on projects that are moving quickly.

As organizations mature and grow, specialization becomes increasingly important. As a business scales, the processes that were once effective might no longer fit the changing org. Design teams may find that as they scale, they require specialist roles beyond the UX designer—like design researchers, UX writers, brand designers, illustrators, and motion designers. This is when a DesignOps role can help to make sure that the right people give the right feedback at the right time, with each specialist aligned to the same overall objective. It’s a tough job that seems more of an art than a science.

The job of the DesignOps team is to protect the time and headspace of everyone within the design organization—the designers, writers, researchers, and so on—which allows everyone to focus on their respective craft. That focus benefits managers, who are able to pull themselves above the fray of the day-to-day to set a longer-term vision, as well as individual contributors who gain more time to hone and develop their skills. Specialization also introduces a financial upside to an organization by ensuring that people are doing the work they were hired to do, rather than taking on work outside of their core competency.

Operating a design team at scale

Organizational growth means more teams and individuals—from product management, customer support, marketing, sales, etc.—lean on the design team. Keeping these teams and their requests in sync often becomes a responsibility unto itself beyond the actual work of design.

Beyond organizational headcount, companies tend to expand their product lines and functionality, which creates an acute need for design standardization and optimization. This is when it becomes critical to better manage communications and coordination across all teams and projects.

When I joined the Dropbox brand studio team in 2015, we were growing fast and spread too thin across a wide variety of projects. I was hired as the team’s first executive producer to help our creative team to collaborate better in general, as well as with cross-functional teams, our marketing team, and external creative partners. We were experiencing growing pains on two fronts.

First, other teams were growing faster than our team. Dropbox was establishing marketing teams in multiple cities around the world. As teams like communications, sales, and product design relied on us for more and more projects, suddenly everything was considered “high priority.”

 

Second, we were expanding our product offerings. The launch of the Dropbox Paper beta was my first project, and we faced a number of internal challenges to get it out the door.

For many years Dropbox had a smaller portfolio of products and features, and we had not established an operational cadence for new product launches at scale. The Paper beta required lots of hunting around to identify the project stakeholders (not to mention determining how they wanted to be involved), as well as the financial and legal management of new vendors.

As organizations build out these processes they become the “fine motor skills” that ensure consistent quality at scale. DesignOps is uniquely adept at defining, socializing, and maintaining these type of workflows.

Safe harboring design teams from burnout

Creative teams are uniquely vulnerable to the subjective nature of their work. On any given project, they might receive bad feedback, late feedback, conflicting feedback, and even feedback from unknown parties with no apparent involvement in a project. After jumping through the burning hoops of a long creative approval process, a team will see their good ideas arbitrarily go down in flames. This creates a stressful environment with few safe places to explore and ideate, and little to no empathy or support for the creative process.

What’s more, scale, pace, and complexity can add up to an environment where creative teams feel like they are always reacting, and never exploring and refining ideas. When this happens, it’s understandable that a designer might just throw up their hands and say, “Just tell me what to do.” This happens all too often at companies that invest in amazing design talent, only to relegate them to software operators rather than thinking of them as partners in solving business problems. It also means that these great creatives are going to look elsewhere for a creative outlet—hopefully on a side project, but likely at another company.

DesignOps is not a panacea for every issue, but it can mitigate the workflow problems that impact a teams’ health—beginning with planning. If a team knows when to expect feedback from specific people—whether from the CEO or other stakeholders—they can tailor the presentation of their work to reflect how it addresses things like revenue goals (this design will increase conversions), product goals (this redesign will make features more discoverable), etc. What’s more, a design producer can set expectations and explain to stakeholders what type of feedback is needed at each particular stage in the design process.

At Dropbox, producers create what we call “blue boxes” at the top of each document we present for creative reviews. These are check boxes that clearly state—before any work gets presented—what feedback we are looking for and from whom. We also call out what types of feedback won’t be helpful. This approach is a great reminder at each review of roles and responsibilities; while we want everyone to be heard, we also want to clarify who is the ultimate decision maker for different aspects of the creative output.

To use a video production as an example: in the final edit review, our design producer will kick off the meeting with specifics on what feedback we need, but will also note that we have a locked cut—signaling that we are not accepting feedback on the voiceover or other unchangeable elements.

Beyond managing stakeholder feedback, DesignOps can prepare the team for upcoming projects and even expose the creative team to the decision-making process early, elevating them more to project partners than executors. This advanced forecasting allows creative teams to get involved with those requesting projects—like product or marketing—and work collaboratively to define the problem.

DesignOps models

The specific flavor of DesignOps you put in place can vary. In general, I’ve seen two DesignOps strategies surface, each of which overlaps with the other:

  1. Operations support: the DesignOps role sets standards and refines processes for the entire design team.
  2. Project support: the DesignOps role embeds into each specific project workflow to drive and improve the creative process in partnership with design leadership.

The operations support model

In a DesignOps support model, the ops function builds systems that impact the work at a high-level. Here the ops function tends to be smaller—sometimes just one person—with a broad focus that allows for spotting areas in need of triage. These areas include design tooling and systems, communications, recruiting, team development, and budgeting.

The DesignOps team can standardize the tooling and systems used to scope, resource, track, and archive projects. While some of these systems can drive high-level strategy, others—like file nomenclature and folder structure—can be just as vital to a team’s success and sanity.

The ops role might dictate meeting cadence, thinking strategically about when 1:1 meetings, team meetings, and leadership meetings should fit in any given week. More, the DesignOps role can implement and enforce good meeting hygiene by requiring and documenting clear agendas and action items.

More broadly, a DesignOps support function might set recruiting standards, plan new hire onboarding, and set a curriculum for the ongoing education and development of the team. The support model also extends beyond the logistics of project work and facilitates teammate recognition, the “pulse” of the team, special projects (like a “hack week”), and other projects where there is no natural project owner.

Finally, the DesignOps role can support the team by managing the budget. Forecasting and tracking both external and internal spending trips benefit even the most adept design leads. This is especially true when your team relies on freelance talent, vendors, and agencies.

The work of managing contracts—setting the scope of work, negotiating rates and terms, coordinating with the finance team—is absolutely crucial for team success. A DesignOps function can manage this responsibility, giving both the design team and external resources an informed and helpful point of contact.

The project support model

In the project support model, a design producer or program manager attends not just to the high-level systems but to individual projects, driving the day-to-day creative workflow.

As each project kicks off, DesignOps can establish clear roles and responsibilities for the working team as well as for stakeholders. Within Dropbox we don’t have one set way of doing this across each of our teams; one group may be using a R.A.C.I. model, others a D.A.C.I. model, and still others some (likely made-up) acronym that means the same thing.

DesignOps can help pair the different work styles into a unified project flow. And while this obviously keeps everyone accountable for their respective contributions to a project, these clear responsibilities also delineate what folks should not work on, like tasks that can best be handled by someone else or that are out of scope.

While a product or project manager might own the overall schedule, in this model the DesignOps team owns the creative schedule and milestones and ensures that creative teams have what they need to develop their best work on time. This project support might include documenting tasks and follow-up items, wrangling project specifications, and handling asset management.

Moving the practice forward

You might find the trigger for your org’s adoption of DesignOps doesn’t fit the scenarios listed here or in other chapters—or perhaps the trigger is a combination of a few scenarios. You might also settle on a hybrid DesignOps model that provides both operations and project support. There is a lot of overlap and variability in DesignOps practices worldwide, and that’s fine.

Whatever the reason behind and shape of your team’s adoption of DesignOps, just remember the most effective DesignOps teams are servant leaders to their organizations and respected peers to design leaders and teams. Whether in an operations or project support role, the DesignOps function is there to push projects forward while providing creative teams the space and time to create.

As design teams and companies invest in DesignOps, they’ll realize better creative results faster, and they’ll see how better work processes can impact the entire culture of collaboration.

About the Authors

Dave Malouf
Independent

Dave Malouf is a 25yr veteran digital design leader. He is a consultant specializing in design operations and a design leadership coach helping design leaders amplify the value of your design team’s efforts both to the organizations they design with and to the end-users they design for. He is a sought after speaker and trainer and author of a book on design leadership. Dave is a founder of the Interaction Design Association, one of it’s first global conference co-chairs, and creator of other IxDA initiatives. He is also the founder of and program co-lead for Enterprise UX conference.

  • Currently listening to: Bruce Springsteen on Broadway (fave music and incredible storytelling)
  • Currently inspired by: U2 and more specifically Bono. Personal truth to power all time. Pixar. No one! No one! tells a story like Pixar.
  • Cultural thing I’m lovin’: Spiderverse — Redefining cinema animation quality.; “Love+Death+Robots (Netflix)” was also really neat (NSFW), Cursed Child on Broadway
Meredith Black
formerly Pinterest

Meredith Black has become a DesignOps pioneer over the past several years within the design/tech industry. She is the co-author of “The DesignOps Handbook” as well as co-founded the West Coast DesignOps group. After championing the DesignOps role at Pinterest for almost five years, Meredith is going back to her consultancy roots to help design organizations grow worldwide. Her prior experience includes working within design at Facebook, IDEO and Hot Studio. Meredith and her husband recently moved to Carmel Valley, CA where she plans to adopt as many animals as possible.

  • Currently listening to: I love my 90’s hip hop playlist on Spotify. 
  • Currently inspired by: Charles and Rae Eames hands down. They never stopped discovering and always tried new things. 
  • Cultural things I’m lovin’: Educated by Tara Westover AND Shoe Dog by Phil Knight. 
Collin Whitehead
Head of Brand Studio, Dropbox

Collin Whitehead is the Head of Brand at Dropbox. His team defines, guides, makes, and manages creative for the Dropbox brand. Since joining Dropbox he has led the creative process for the recent overhaul of the visual identity system, voice and tone, brand campaign, and new company mission.

Prior to Dropbox he was an Executive Producer at West Studios working with startups to build and launch their brands. Collin’s roots are in advertising where he got his start at Goodby Silverstein & Partners.

  • Currently listening to: My team actually has a side hustle making playlists for creative flow at work
  • Currently inspired by: Masako Miki
  • Cultural things I’m lovin’: I am in love with the Hurry Slowly Podcast , it’s got a great perspective on better ways of working
Kate Battles
Senior Manager, Design Operations, Fitbit

Kate Battles joined Fitbit 2015 as a Design Operations Manager, and over the past 3+ years has managed a number of large scale design programs and process initiatives, as well as started and led the Design Operations team. Kate believes in the power of user-centered design to help solve complex problems for users and for businesses and is passionate about helping people live healthier lives. Kate lives in San Francisco and spends her free time chasing her toddler and French Bulldog Bruce, and if she has any extra energy you can find her in spin class or urban hiking with her husband.

  • Currently listening to: James Blake – Assume Form
  • Currently inspired by: Roy Lichtenstein
  • Cultural things I’m lovin’: Greta Thunberg