Six pitfalls to starting your Design Operations practice

It seems that building a DesignOps practice is all the rage, especially at organizations of scale. This is a good thing. But I want to throw a bit of caution to this great work by offering some advice in making sure your DesignOps practice works correctly.

1. Don’t get buy in

This is probably the biggest and most important issue to avoid. From highest level executives to your core design & research practitioners, you have to get buy in.

What does buy in look like though? What does it mean?

Think of this as a list of questions that you need to be sure to be able to answer for different audiences:

Executive staff are going to want to know, how is success going to be measured, what is going to be asked for them to support directly/indirectly, and they need to be able to express the value of the role across to their leadership and production teams across the organization.

Partners with design practice such as product management and engineering need to know what is going to change? How is that change going to impact he work of their teams? What are the short term hit/gains and the same for long term gains. They also will want to know if this new practice is going to answer the problems/issues that they have been having with design practice, not just how design is going to change. They are also going to need to understand what their involvement is. How are they and their teams going to need to be involved in developing this practice. Finally, like execs they are going to want to know what success is going to be measured as.

Your design & research teams are going to need to know how this is going to impact their current obligations. Change always takes time and even if they are supportive of the type of changes being deployed, they will want to understand how this change will impact their other relationships in the organization. They are also going to want to understand how they are going to be involved. They aren’t only interested in how there is going to be change, but also what are going to be their opportunities to participate in the actual building of this practice. How are decisions that are going to impact their direct working and evaluation going to be made?

2. There is no vision of success

As mentioned above already, people want to know what this is all going to get them. What is the mission, and how will they know when “mission accomplished” occurs.

Part of this is about the development of a roadmap for how to building of this practice is going to take place. A roadmap is going to include which affinities (or lenses) are going to be concentrated on when and how. Who is involved at which stages of the plan itself.

The vision needs to sync up with the known goals of both the company and the design team and sync up with the values of the both as well.

3. Hiring/deploying the wrong person/people

This is similar to the common problem of making a rockstar employee into a manager because you need to scale, but you did nothing to prepare them for the different role. Just because there is interest in an area of design operations, or because you need to promote someone, doesn’t make either of those people the right person to hire into this new type of role.

What makes this further complicated is that different skillsets need to come together across the different areas of DesignOps, so initial leadership is less about doing and more about managing other people’s leadership. Regardless of area of ops there are some traits that are important regardless of general design skills/experience:

• The person is an influencer. They can work a room and strategically sway the people who need to move so that things can change in the right direction.
• They are a systems thinker. This means they can hold a system in their mind and they can further help others do the same, so that connections can be made, breakpoints discovered, and solutions uncovered and built.
• They are results oriented, but strategically so. They are not swayed by metrics that won’t impact strategic ends, and help teams drive towards transparent strategic goals.
• They are a communicator. They are transparent. They let people know what they are doing, why, and how it is going to impact who. They don’t wait for people to come to them with problems, as they are always reaching out to remain connected.

4. Taking on everything or Not taking on enough

These are related to each other. Design Operations is a huge area. it includes production operations, people operations, and even business operations components. And those three are all tangled up together. This makes it seem like working on one area requires working on all of it. While having that roadmap mentioned above to express a vision is a great start, the challenge is really a combination of understanding where you are now, creating focus, and prioritizing.

Too often a DesignOps leader will say, I’m starting here. They put a lot of effort into that one piece just to learn that it is too connected to other pieces for them to make their goals happen in a reasonable timeframe.

5. Getting hung up on semantics

A past time of always everyone in any discipline, we all tell ourselves that words matter, especially us in the design world closely aligned to information architecture. However, in this case, let the process drive the language instead of the language drive the process. You know what you are doing. And you can talk about it however you like, but focus on effectiveness more than being right. If you never use the term DesignOps because your devs get confused, or Design Operations, b/c your COO thinks it should be part of what they do, your response is always, “Yes!” Focus on explaining your goals and your vision for achieving it and let the community decide what they want to call it internally. All of this language is too new and too fuzzy to get too uptight about it anyway.

6. Forgetting what this is all about

This isn’t about making designers work better with developers. This isn’t about hiring top talent. This isn’t about getting the best Macs (and having them supported). This IS about amplifying the value of design within the greater context of your organization. This will require mindset shifts by everyone, as well as changes in workflow, tooling, and general culture to boot, but getting and understanding the value that comes from well-practiced design.

If you need help getting started. Reach out, and let’s see if we can put you and your team on the right path.