When are you ready for DesignOps?

Most design teams start small — sometimes as tiny as a team of one. In the early days of any organization, design is born out of a need to make things.

Requests from other departments are often given and completed on the fly, with designers working on whatever is needed most. But as an organization grows, so does its design needs. Soon the requests increase in both scope and volume. Maybe the resident designer gets the go-ahead to hire another designer. Believe it or not, this is where many organizations run into their first potential operational problem.

If you deliver design — any design — there needs to be a plan for what that process will look like. That includes the tools that will be used, how they will be used, which guidelines should be followed, who should be involved in review, and how the design will be handed off when it’s complete.

This may be easy enough to cobble together for a design team of one. Add just one other member to that team and you’ve doubled the size of the department. The first team member needs to ask themselves: “Could I work with another person right now? Could easily hand off my work in a way that makes sense, has a system attached to it, and follows a set of rules that are predictable and repeatable?”

Warning signs to look out for

Organizations of all sizes can benefit from DesignOps, and the earlier it’s implemented, the better. It’s much easier to create scalable solutions before you’ve actually scaled, as opposed to trying to retrofit solutions to a team that’s already grown. But that doesn’t mean an organization has missed the boat if it’s already at a good size, with a large team, and no operational plan to speak of. It does mean that introducing these measures will be more of an active approach than a preventative one, however. Keeping that in mind, here are some signs that you shouldn’t wait any longer to implement DesignOps.

Staying the same feels painful

Abstract Design Advocate Scott Welliver says teams face a crippling dilemma when they realize that changing and staying the same can both be painful. And for organizations without DesignOps, the prospect of implementing the systems, protocols, and guidelines it requires can feel very painful, even while they deal with the kinds of issues that would make it useful. All that work, and for what? It may feel like putting the cart before the horse.

But at a certain point, that changes. Suddenly, staying the same is what feels difficult. Without systems, uniformly enforced design tools, and some degree of automation, things can quickly spin out of control. If you’ve reached that tipping point, it’s time to change.

Design is built around platforms rather than problems

For many hiring managers, there is a temptation to grow their team once there are more “things to be designed.” Some work on website design while others work on the iOS app, and others still on the Android app. Each of these entities requires its own designated designer, right? Well, not exactly.

This kind of structuring occurs when companies add new platforms (like apps, online shops, or customer service portals). This piecemeal approach erects silos around certain functions, causing different elements of the same customer journey to feel “Frankensteined” together because they were not considered or designed as a whole.

DesignOps creates a model where work centers around the problem a customer is trying to solve rather than the platforms on which they are interacting with your organization.

For example, a designer focused on the problem of “accessing exceptional customer service” might work across several customer touch points, with the objective of creating designs that put clear instructions and easy customer service access front and center.

Time to delivery is bloated

Maybe this sounds familiar: something you planned to deliver in two weeks is now six weeks overdue, has been sent back for revisions three times, and now comprises so many disparate thoughts and opinions that it barely does what it was originally intended to do. This kind of scope and timeline creep is common in organizations that have not instituted the kinds of formalized workflows, review processes, or design guidelines that are inherent in a good DesignOps function.

Information exists in silos

Maybe your design team is already adept at capturing and communicating guidelines and processes within the team. But many organizations find that communication breaks down when they try to work with other teams. It’s not uncommon for marketing and product design to have their own separate sets of brand guidelines that vary from one another. Similarly, running into hiccups with engineering at the handoff stage could often be avoided by communicating better and earlier in the design process. 

This tendency to keep information locked within teams is common, but it can also be easily avoided. Introducing tools that increase visibility among teams and allow for collaboration can break down those barriers.

“How things get done” means something different to everyone

While some degree of variation in process between projects is to be expected, if your stock answer for how something should get done is usually some form of “it depends,” that’s a red flag. Design always benefits from some degree of fluidity, but not having well-defined and communicated processes will cause miscommunication, scope creep, low morale, and confusion.

You have high turnover

Without a deliberate focus on improving the culture within your team, it’s more likely that employees will lose interest and, ultimately, look elsewhere for a more fulfilling role. While focusing on team-building and morale-boosting activities is important, to truly improve your design culture, you have to go deeper. Taking a more operational view of how your team is setup and who is responsible for what allows you to focus on career paths, which opens up an opportunity to really invest in your team members. When your designers see the gaps in their own skillsets and have a plan for how they can grow in the future, they will be much more excited about exploring that growth within the organization.

Your team is growing

Former DesignOps lead at Target Andrea Burton says DesignOps becomes important “the second you have more than one designer working on the team.” This is true in a perfect world, but the reality is that many teams will have already grown quite a bit by the time it feels necessary to add this function. As your team grows, so does the need to operationalize it. Doing this earlier rather than later can save you the pain of having to retroactively amend process holes and stitch guidelines together. This is especially important for teams that are spread out either geographically or by product, where guidelines can grow within one location or product silo but are not carried through to other parts of the business, further perpetuating silos and hindering cross-collaboration. The sooner you’re able to introduce systems using a top-down approach, the smoother your organization’s growth will be overall.

We’ve interviewed industry pioneers about how they’ve built and grown the DesignOps practices at their organizations in our book, Why your organization needs DesignOps.