Someone just tell me what DesignOps is.
Your burning questions answered.
When your title is, “DesignOps,” you get a lot of questions like… What do you do? Are you a person or a department? What Ops are you running, or designing? Or both? Are you sure you’re really necessary?
Geez, I hope so. I sat down with our Product Writer to answer some of the most pressing questions I get asked about DesignOps that reflect a larger curiosity in the workforce around the purpose and value of this emerging role.
J: Hi, Kory. What is this big DesignOps movement that has every Product team talking?
K: Hey Julia. Well as you know being on the team, you guys are working across every team in the business. When you have designers, writers and researchers working so cross-functionally, a gap or an opportunity arises to look after the operational side of things. This is where DesignOps comes in. It’s a function that helps remove friction in processes, workflows and communication while unifying a consistent design language across everything a product team builds, to ensure everyone can just focus on what they love. Which, for our team, is design.
J: Got it. So another question that comes up sometimes is, “Is DesignOps necessary?” Some may argue that we should each be responsible for managing our own processes and communication.
K: Of course that is very true. But the role of DesignOps is simply to remove as many barriers as possible so teams can get there faster. So much of a designer’s time, for example, can get eaten up just looking into things like the best new design tools or training they should be using, or trying to manage their pipeline of work or the governance they need to go through to get it signed off. If you let DesignOps take care of all of that, you leave the designer with more freedom to do what they love without being derailed by mechanics and behind-the-scenes work.
J: Other than the immediate Product Design team, who else does DesignOps work with and support?
K: DesignOps supports anyone who needs to be connected with Product Design. That means everyone from users coming in for a research session and the front of house who let them in, to pretty much every team in the business who’s impacted by the products we’re building.
On a day-to-day basis I work with our finance, marketing, legal and compliance teams, Product Managers and Engineers to ensure there aren’t any gaps in our Product Design processes, and that we’re all working together to get the best possible product in the hands of our users, as quickly as possible.
A key focus on where DesignOps supports the business is called ResearchOps. In short, this is about centralising research and making it accessible and relevant to the rest of the company.
For example, we’re working right now with Kate from our Go to Market Team. She recently created a Research at Domain group where we get together monthly to share research findings from all across the group, from Marketing to Agent Solutions.
So to summarise, DesignOps works with the entire business to make sure everyone is aware of what we’re doing in Product Design and the impact it’s having on their corner of the world/office.
J: DesignOps is often adopted when design teams get bigger. Can you talk about how you specifically support the team as it scales?
K: That’s right, DesignOps exists to allow a team to scale by making sure they have the right processes and frameworks in place. We start by removing operational inefficiencies where there’s opportunity to do it better. Once we’ve identified those opportunities, we collaborate with other teams to find the most agreeable solution forward, meaning the one that requires the least amount of learning something new for maximum efficiency. Sometimes the solution is a new tool, or sometimes it’s just a change in process.
At Domain, we have our own in-house design system called “Casa” which we ensure is constantly updated and maintained correctly. I work with our designers and engineers to find the best possible solutions for both accessibility and visibility, but also to ensure that the system suits both the engineers and designers.
J: When you’re looking at bringing in a new tool or process, how do you go about finding one that suits everyone’s needs? For example, there are certain tools that make it easier for me to edit copy, but harder for designers to do their job. How would you make us both happy?
K: There won’t always be a perfect tool that everyone loves to use or that makes things easier for the whole team, but I approach this problem assuming there is. Start by understanding the problem; what do we need this tool for? Which one minimises effort while maximising efficiency for both parties? If the tool suits most parties (ie designers and engineers) but not another (ie copywriter) then is there a change we can make to the process that would minimise friction for them, and benefit all parties earlier on?
J: When you’re collaborating across the business with other teams, how do you go about removing silos?
K: I think most of it comes naturally as an extroverted person, you always want to bring people together. Silos exist because there’s a lack of communication between teams and it’s actually very easy to fix, but everyone has to be on board. You start with empathy; understanding everyone here has a job to do — what’s getting in our way and how can we help each other out? The answer is more often than not by talking more, working closer and always taking time out to see things from someone else’s perspective which is one of our values at Domain: Open Minds Open Doors. In a way, living that value is enough to help break down any silos that get in our way.
J: What makes a great DesignOps person, and is being a designer a requirement?
K: I don’t believe you need to be a designer but obviously having an understanding of the design process and the ins and outs that go along with it will help you approach the role with great empathy. However, you don’t need to be a designer to create an infrastructure within a company that minimises the effort needed by PMs, designers, engineers, researchers etc. in order to create amazing product. At the end of the day, you need to be a good communicator and most importantly, someone who is comfortable with ambiguity. I think whenever you come in to any new function where there hasn’t been a precedent set, you’re constantly becoming aware of new problems that the team themselves may not have known existed because they’ve always done things that way. It’s really common for someone in this position to feel like they are swimming through ambiguity. To be successful in this role, you need to be comfortable and even enjoy working through that ambiguity in order to find the clarity you’re looking for.
J: Why does DesignOps matter so much right now?
K: In my opinion, as design teams scale or even just as we focus more on shipping faster and more frequently, we risk losing so much focus on design to the operational side of things. This means less time for things like innovating and critiquing; the things that ultimately lead to better design. DesignOps is a way of letting designers do design instead of wearing 50 hats. It’s a way of restoring design purity and evangelizing their work throughout the company, which is more important than ever as teams become more agile.
J: Thanks for taking the time out to help us better understand DesignOps, Kory! What do you recommend our readers read next?
K: Well if they’re keen to come work with us, I’d check our our Product Design Director’s blog on how to get hired here!
