How to prioritize in Design Ops
When you’re a mighty Design Ops team of one, you will be juggling multiple priorities at once. I’m often asked, how do I get things done?
With limited time and bandwidth (and let’s face it, that’s all of us), it’s in everyone’s best interest for you to make the most of that time. This requires ruthless prioritization combined with areas that you think will make the largest impact on your design team.
So the big question is, how do you decide what to work on?
Learn what the perceived problems are
If you have a role in Design Ops, chances are there are multiple complex problems you were hired to solve. Design Ops roles are created when it becomes clear the design team needs someone skilled in this area to triage and fix.
When there are problems, you will have lots of people who want to tell you about them. This is a very good thing!
Who should you talk to?
- Your team (1:1, if possible). People will often share more in a 1:1 setting than in a group setting, especially when using video calls.
- Other key stakeholders: who does your team work with on a regular basis? Whose voices are the loudest? Hint: look for leads and heavy users across design, engineering, marketing, and product.
At this stage, I tend to keep things more informal. You want people to tell you unfiltered feedback, and make them feel comfortable enough to open up. Be Switzerland: a neutral party, with no preconceptions, so that you can really listen.
Important: resist the urge to take the solutions they give you and execute on them. Take this time to properly define the problem, and not jump into the solution. You can thank my experience as a Product Manager for using this methodology.
Do note any existing solutions to the perceived problems (existing documentation, slide decks, etc): list them out, and file them away. Take good notes, and use them to inform the next step.
Gather and analyze data
You now have a bunch of comments on pain points in the design process, as well as assumptions on what caused these problems, and solutions to fix them.
Take this raw info and ask yourself: what do I really need to know, to validate these problems?
Here are a few key points on getting the data you need:
- Clearly identify: what problem are you trying to solve, and why are you trying to solve it?
- Figure out what data points would help you make a decision.
- As soon as you know what data you want, start collecting it.
You might need to roll up your sleeves and just start counting something. Perhaps you heard a complaint about “many projects” not being shipped on time. See if you can provide a count, and do a percentage of how many projects this applied to. Or, maybe comments were made about poor communication. Can you count the feedback rounds based on multiple Slack comments? Decide what you can measure, and try to measure it. If you have Jira tickets or something you can query, even better: pull counts and see what you find. I actually love this part: it gives me the opportunity to play detective, to look for clues on what is true, and what is a perception.
Think about your audience as well: different stakeholders will have different needs. Segment the data based on the audience for better understanding of their key pain points.
Data is much easier to collect than you realize. This scrappy method is not meant to be statistically significant with thousands of people. This is just to give you (and your team) visibility into what can be proven. When I wore the Product Manager hat, I constantly had to provide data to back up my product decisions. At first, it felt uncomfortable: I was confident in my decision making process, and thought I had enough information to move forward. Being forced to gather data was, in hindsight, a gift: it uncovered blindspots I had in solving the problem, and resulted in better solutions for my end users and customers.
Define actual problems to solve
Take all the information you’ve gathered, and define the actual problems to solve. Here’s a real world example:
Perceived problem: Design process takes too long
Suggested solution: Better communication on the design process
Data collected:
Actual problem:
- Clear definitions of design requirements and time needed to complete are missing from the start of the process
Possible solutions:
- Have design source files required to start the design process
- Documentation on design requirements and time needed to complete
- Define scope up front, so that there is transparency on what was agreed to
- Educate all stakeholders on ways to save time (descope items, simplify asks)
Focus your efforts on defining the actual problems, and present your findings to your team, using the data you’ve gathered as a starting point. Identify what is needed vs what is requested. Structure your data to come up with a conclusion and a path to move forward.
Bring people along for the ride
After identifying the problem and possible solutions, as a Design Ops team of 1, you’ll need help to execute them. Define what needs to be done before deciding who can do it. Then, identify the resource(s) best suited to help. This can be tricky: sometimes you need people with a certain mindset who want to expand their skills. Other times, you’ll need to identify champions or people who can influence a team to help with the work. Lastly, you may need to partner with resources that are outside your team (or offsite), based on what you want to accomplish.
I find it more effective to break down the work into small pieces, before asking others to help out. Smaller assignments are less daunting, lead to faster turnaround times, and you have more opportunities to optimize / refine as you go.
Remember: as a Design Ops team of 1, you’ll be responsible for making the machine work. Be realistic about what you can accomplish on your own, and ask others to help you build the parts.
Reduce, reuse, recycle
Remember that list of existing solutions? Take a closer look.
- Are any of them solving your defined problems?
- Do these solutions connect to other active processes?
- Can something be edited or better defined, for more clarity?
- Is information centralized? Is there a single source of truth?
- Are there overlapping systems / redundancies?
Save what is working, and decommission the rest. Ask the resources you’ve identified to help you refine these solutions, so that they are more effective for your defined problems, not for the perceived ones. I recommend editing / archiving as much as possible: it’s less to manage and maintain for the future.
In my experience, when first solving a problem space, it is better to optimize existing solutions instead of building new ones. When building new solutions, you risk creating new data streams that do not link to existing processes and unintentionally decentralize information.
Once you address the “lower hanging fruit”, you may want to evolve towards a new solution. As a Design Ops team of 1, you need to decide what is worth the investment of time, since it will a) take longer to build from scratch and b) take longer for adoption of a new process.
Communicate, evaluate and optimize
Change management is hard, and communication is critical to its success. Identify your main channels of communication (we use Slack and presentation slides), and leverage them based on what you want people to know. The goal here is to a) let people know they are being heard, b) share data / information you’ve gathered to help, and c) keep them informed (how it will improve their work, and possibly alter their process).
You may want to identify a test group to road test your solutions. This way, you address any gaps in your solutions before rolling it out to a larger team.
Once you have deployed your solutions, let it ride, and give people time to understand and adjust. Be sure to gather sentiment data you can evaluate (I love using surveys) after some time has passed and people are using your process.
So what do I do now?
Making the design team more effective is a great problem to solve. Take pride in this! Use the steps above as a guide to make sure you are delivering the most value to your team, and as long as you have the right problem defined, your solutions will only get better with time.
What techniques have you used to prioritize issues related to Design Ops? Please let us know in the comments below—we’d love to hear from you!
