When is it time for DesignOps?

Editors Note: This is an excerpt from InVision‘s DesignOps Handbook, which highlights the methodology behind successful design operations.


DesignOps is the key to scaling digital product design teams with more efficiency. As companies mature and invest in design, they need to operationalize workflow, hiring, alignment between teams, and more so designers can focus on design work while someone else takes care of the rest. Learn how creating these centralized services and systems helps grow integrated, high-functioning teams at the best companies in the world.

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.

three members of the Dropbox team look at a wall with illustrations posted to it

The Dropbox brand team.

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.