How to Start and Manage a Design Ops Team

How do you define design ops?

Q. The design ops role is new to a lot of people. Talk to me about what it is and what exactly it does.

A. Design ops is, in the big scheme of things, a relatively new function within the design community. I would say that it started in 2014 with Dave Malouf participating in the development of the  Invision Design Ops Handbook, and from there it’s really started to grow. In the last three, four years it has grown exponentially.

If you use the Nielsen Norman Group definition of design ops — which I think is great — it’s the orchestration and optimization of people, processes and craft in order to amplify design and design teams’ values and impact at scale.

When I say that to people, though, their eyes cross and rollback in their head <laugh> because it’s a lot of words shoved into one sentence, and everyone gets something different from it

So although that might be the technical definition, how I like to explain it is, Design operations is focused on ultimately empowering individual designers, or in general, design practitioners, to do the work they’re uniquely trained to do. I want to reduce the cognitive load of everything else in their work lives and let them focus on their work and the things that they have a specialization in.

As you can glean from the Nielsen Norman definition, it can go in a variety of directions.

Q. Sometimes I like to frame things around what’s the problem that you’re solving. Is there a problem that designers have with cognitive overload and related topics that you’re addressing?

A. You know, I think it depends on the team. And I’m going to apologize in advance. Most of my responses will start with “it depends,” because design ops roles in general vary so much. At the end of the day, we’re trying to fix the pain points that design teams or individual designers or practitioners are identifying. I like to use the word “practitioners” often because in my most recent role, I was supporting not only designers, but also researchers, managers, and content writers. My work wasn’t just specific to UX Designers.

I was looking at the larger pain points around the processes that could improve the efficiency of work, the findability of information, and the connectivity of the team. Is the team happy? Are they happy in their work? In the way we’re communicating? Can they do their work efficiently? Do they spend an hour out of their day trying to find the information to do their work because they don’t know where it is, or it’s never been documented?

So when I use the phrase “reducing the cognitive load,” I think about how I can speed up the processes that are in place, so that it’s easy and simple to find and digest information without overloading practitioners with different activities that don’t directly impact their work. This way, as I mentioned, they are able to focus on the work that they’re uniquely trained to do  and that I’m not uniquely trained to do.

The employees are my users

Q. You mentioned the practitioners that you’ve been working with. I’m used to people describing design as being — I don’t want to say subservient, that’s not the fair word — but a subsidiary to the overall product development process or website development process. It sounds like you’re operating a little bit more holistically. Talk to me about that.

A. I think the designers, and practitioners, at the end of the day are focused on a product or a specific space. They’re using either a product development process or a design thinking process. They may be working in Scrum and Agile . And I would say that it is all directly connected to a website, a product, or a piece of a product.

But for me as a design ops practitioner, my work is focused on the employees, the designers and practitioners themselves. I wouldn’t think of them as my product per se, but I would think of them as my users. And I’m thinking about what  they need. What is the product I need to create for them? Is it documentation? Is it support? Is it standardization? Is it team events to boost morale?

So I’m looking at my users as employees and my product as processes and structures that as a design ops practitioner I can implement to make sure they have a great experience.

From outdoor education to design ops

Q. Let’s talk about your personal background. Talk me through the story of your past and how that led you to design ops.

A. My background is somewhat unorthodox, although I’m happy to say that among design ops practitioners, I meet a lot of people who come from other untraditional backgrounds. We bring skill sets that are not always just — and this is nothing negative about anyone else — a project manager, or a program manager.

There are a lot of members of the global Design Operations community that I’m a part of, known as the DesignOps Assembly – I just want to give them a shout out – who come from really different backgrounds.

My background is actually in outdoor education. I spent about a decade in the outdoor industry working primarily with youth. I did everything from “let’s go backpacking in the woods for two weeks,” to teaching geometry at an experiential education high school, to running corporate team building in Hong Kong with Coca-Cola and Barclays senior management teams. 

I did it all. It was an absolutely incredible time in my life. Eventually, I moved into management- operations, hiring, logistics, and supporting my employees to make sure that they could run their programs efficiently and effectively. You might start to see some parallels here to how I spoke about the work done in design ops.

And at the time, this was — oh my God — seven years ago, maybe longer, I was working with a small nonprofit in California. We worked with schools and ran school programming for their students, three to five day programs with entire school groups, which was really cool because we got to focus on leadership development, communication styles, and personal capacity planning. Since these students were mostly eighth graders, they were transitioning from this middle school stage, into high school and wondering what that change would be like. We addressed that through fun outdoor skills and experiences. 

When I came on as the operations director of the company in 2015 we had a lot of return clients, but we weren’t seeing a lot of new clients.  I started gently poking my boss at the time saying, “We need a new website. Ours is out of date — and it isn’t working to meet our needs, or our clients’ needs anymore.” I’m not exaggerating when I say it was from 1996, maybe ‘98, I don’t know <laugh>. But it was old. It was outdated. It did not seem trustworthy. And that is actually a word I used back then, unbeknownst to me that this is something talked about in user experience design.

To make a long story short, I rebuilt the website, rebuilt a ton of processes as a part of that, from staff applications to student applications, medical management — everything from the website to day-to-day processes.

And I said to myself , “I love this. This is my jam. I’m going to be an engineer who builds websites.”

I started to learn how to code. That fizzled off relatively quickly. A friend of mine told me that I should look into something called user experience design. I’d never heard of it before. It turned out to be exactly what I wanted to do — designing through focusing on the needs of the users. It’s something that I had been doing my entire career, just either in a very physical one-to-one, or a non-traditional design space, experiential education type of way. 

You can imagine how surprised I was to realize I had just done a lot of user experience design, without knowing it was user experience design. At the time I didn’t have the language, didn’t have the vocabulary, and didn’t know what I was doing. It was all very intuitive.

I went back to school to get a certificate in User Experience Design through the School of Visual Concepts in Seattle, which was an amazing experience. And then I tried to get my foot in the tech door. Coming from the outdoor industry, even with management experience, this was quite challenging. I’m sure when hiring managers saw Pro Guiding Service, Go Adventure and Treasure Island Hong Kong as companies on my resume, as well as a degree in Expeditionary Studies & Sociology. It didn’t make it much further through the application process and my resume likely went right to the trash.

I ended up taking a project management job with a team at Microsoft to get a foot in the door. At the time I didn’t even know project management was a job, because for me it had been just a part of all of my work — doing it off the side of my desk. I was used to wearing many hats and project management was one of them. So for someone to hire me and say, “all we need you to do is project management.”

I’m like, “What? Oh my God. I can do that. Nothing else? You’re sure?”

“Yeah, that’s it.”

“Oh, okay.” <laugh>

This team I was assigned to at Microsoft is incredible. I was supposed to be there for a six month contract, but ended up staying for close to three years. And eventually, I had the opportunity to bring the knowledge of user experience to this team. They were building an internal platform, and I had a lot of questions very quickly, most importantly “have you talked to your users?”

And they said, “We have not.” And I’m like, “problem, red flag” <laugh>.

I ended up being somewhat of a  UX strategist, UX program manager, leading the communications, overseeing the design, and driving some direction throughout the development of this work. I called myself a translator between our stakeholders, our dev team and our design team.

Once again, I had found something I loved.

Eventually I moved into working on our external-facing Microsoft.com websites, and  I had the opportunity to do UX research and design, as well as strategy to launch some impactful changes to the websites I supported.  

 I had only recently stumbled upon this world of design operations, and became part of the DesignOps Assembly group and started lurking on Slack channels and reading a lot of Medium articles. And I thought to myself, “I think this is my calling.” I had spent the last three or four years in user experience design — maybe longer – when I was doing it but not knowing I was doing it, and I had decade plus of experience in operations.

Design operations was this perfect intersection of all my operational background mixed with UX and design thinking, while still getting to be involved in the design process. 

How and why to run a Listening Tour

Q. You shared with me an article that you wrote for Medium, talking about the listening tour that you did in your design ops role. I’m interested in that in two ways. Number one, the process of the listening tour itself. Tell me about what you were hoping to accomplish and how you structured it. Second, I’m also interested in what you learned out of it.

In my most recent position at REI, we were a brand new design operations team of two, supporting a practice of 70, which is a lot, to say the least.

A listening tour was an opportunity for myself and my associate DPM to figure out what we should be doing. We wanted to understand:

• Where did this design practice need support?
• What were their pain points?
• What were their challenges?
• What was actually working well?

The goal of conducting this listening tour was to do a set of interviews and connect with our practitioners. Let them know that our doors were open. We want to hear from you, and we’re not going to come in, and just be like, sweet, I’m just gonna know exactly what needs to be done and do it, and bulldoze the solutions through.

Because at the end of the day, I think — and I believe many design ops practitioners would agree — that design ops needs to be focused around the organization and the problems in that organization. So, I conducted a listening tour with 17 different members, which was a lot, but we had such a big organization that I wanted to have a holistic view of our designer pain points, our researcher pain points, what was working well, and if they could wave a magic wand, what would they love us to tackle this year?

From this conversation, as a design ops team, we were able to define what our focal points were going to be for our work. This provided us with a backlog, focus areas, and an understanding of our practitioners, and organizations, needs and wants. It also created an opportunity to build relationships with our team. That was really important for us because those relationships and connections help you to successfully implement new or changed processes or solutions.

Once we defined what our goals were, we went about running a pretty traditional research project — following a relatively traditional research plan — figuring out what our opportunities were, plan our research, work with participants, conduct the research and then run our synthesis and our analysis, and finally share it out with the broader audience. We wrote interview guides, took thorough notes, but unfortunately we didn’t have session recordings. That was a learning experience for us. <laugh>.

From our research, we learned that there were nine key areas that were important to our practitioners. 

Knowledge management was a big pain point. That certainly wasn’t shocking, and I think it’s something that most organizations struggle with. There was no single source of truth. When someone left the organization, the knowledge went with them.

We shared these insights with the design practice, and larger communities across the organization. On the flip side of challenges — team culture and health was an area we heard many positive things about. Everyone spoke highly of how supported and how connected they felt. And it’s also important to share those positive items.

We then went on a roadshow to share our findings. We had a lot of conversations with a lot of different teams to share not only our learnings and findings, but also our process and open up opportunities for cross-functional collaboration.

 I believe as design ops practitioners, we shouldn’t be sitting in silos. Design ops practitioners can work cross-functionally with other program managers or product managers, and beyond, in specific areas to create these processes and implement structures and change for the greater community.

There were a lot of great things that came out of the specific listening tour at REI that I conducted, but in general, it’s a great process to go through when you’re starting in any new role. Whether it’s just for yourself to connect with those individuals and know what’s going on in the organization, or if you want to run a formal listening tour that helps you to define your work and strategy, both are beneficial to being successful in your position. 

Q. When it came time to share out insights, you said you did a roadshow. Give me a little bit more on what that was like. Is that a standard presentation you did to staff meetings? 

I think I gave about seven different presentations across the organization to a variety of different groups ranging from product management to customer research, and of course the design practice. The goal of these presentations was first to say, “You gave us your time and now, I want you to know what we learned and, importantly, here’s our plan.” We hoped those practitioners felt as though the work that we were doing was going to impact them positively and they could understand our findings and see their pain points reflected. For those outside of the design practice, we looked for opportunities for collaboration and see if other teams might also have similar pain points.

It was an opportunity for us to share our work, but also say, “Hey some of this might sound familiar to you; are these pain points you see in your organization as well?” I think a lot of organizations potentially see similar pain points in different parts of the organization, but because of these silos we sometimes live in, we are like, I’m solving it over here and I’m solving it over here, but everyone’s solving it slightly differently. If we solve these challenges in our silos, we’re not always able to get to the root of the problem because at the end of the day it is a much higher level challenge to solve.

Out of this listening tour, we actually created a practice ops working group, which was a collection of members from design, product, and engineering to work on shared objectives, to tackle these shared pain points.

And another big outcome was the product management team saw the value in this work and decided to run their own listening tour. That’s where the development of the listening tour playbook actually started.

Q.  I want to ask a really tactical question. When we were doing the prep for this interview, you mentioned to me that you used Mural to organize your findings. My stereotype of Mural is that it’s something we use for group brainstorming on Zoom. Talk to me about how you used it personally to organize your findings, because that’s a different usage to me.

A. Before I dive in, I have to admit that my answer is over simplifying the process I used to analyze the interviews — we could talk about research analysis for an entire other interview. 

That being said, when I think about traditional research, we’d sit in an office together and everyone writes their sticky notes and you’d stick ’em all on a wall together and start creating groups to work through your affinity map process. We can’t do that when we’re working remotely. So that’s actually how I leveraged Mural.

I copied and pasted all of our written notes into sticky notes in Mural and started to group them into similar buckets. I had 374 sticky notes from our interviews — yes, I know the number.  In total it took a couple weeks to actually complete the full mapping exercise and summarize the insights. 

All of my notes from the interviews were on my mural board. I could quickly ask, “What was that thing someone said about communication standards?” I could go back, look at my little communication standards subgrouping, and be like, “Oh, yeah, one insight was — no one knows how to contact each other.”

So that’s how I used Mural to conduct my research analysis, which was great because I worked with my associate design program manager, and we did it together, which meant often we put on music and sat there quietly for two hours and worked in Mural.

We could comment and then share with our manager. She would pop into the Mural board and she would comment in an asynchronous environment, “No, is this a good grouping? Or maybe here’s a better title for this.”  It was a great collaborative tool.

Q. In general, what did you learn from the tour? What were the big takeaways?

As I mentioned we had key areas of findings that ultimately ended up becoming the focus areas for our design operations team: knowledge management, research ops, people’s ops, software usage, team culture and health. It helped us to create a backlog of work as well as understand if there were additional areas that we needed to conduct  deeper dives into understand more clearly.

We could organize our backlog as well as our sprint cycles into these key focus areas. That didn’t mean you were working in every area every week or every month or every sprint cycle. Sometimes it was just , “let’s tackle the need for documenting a research process.” Which fell both in design ops and Knowledge Management groups. These focus areas helped us to divide work between ourselves, and keep track of the areas we were tackling.

Q. I’ve seen cases in my career where you get a beautiful plan in place and then when you start executing, everything in the company ends up changing. Were you able to stick to the agenda? How did it work out for you afterward?

A. Our backlog was so huge after our listening tour. We had to sit down as a team and do a lot of internal work to prioritize what needed to be done now, what were those quick low lift efforts we could execute on rapidly versus what were the initiatives that were going to take a lot longer.

I think it’s always hard for a new team. I always liked to say “We were flying the plane as we were building it.” At least that’s how I often felt.

I think it took about nine months for us to really have that foundation as a team because just as we were dealing with executing on a project, we were also creating our own processes and trying to tackle the work that we saw as long term impactful work. We were also trying to develop our own team processes — the building the plane part- as we were also going full steam ahead. How do we manage this backlog? What are our sprint cycles? How do we quantify work? How do we communicate out the work?

I would say it was a successful year, but that backlog very much still existed, and will continue to. That’s just how it is; it was never-ending. There were a lot of big initiatives in place that happened, a lot of things in the pipeline, and a lot that got completed. There was a lot of great work to be done and we heard kudos from our team. I mean, we got tweeted at from a practitioner who said, “design ops at REI has made our lives a hundred times better.” That is huge, to hear that the work that you’re doing, even as small of a lift as it was, can have such an impact.

The many flavors of design ops

Q. As I’ve talked to various people about design ops, I get all sorts of different views of what it is. Sometimes it’s very focused on acquisition of tools and standardization of tools – sometimes to the point where I hear the design ops folks described as the police who force us to consolidate our budget and won’t let us buy other tools. On the other hand, I get a lot of stuff that’s much more around crafting workflows and stuff like that. Help me understand why I’m getting these really different views. Is it just because companies are different, or is it because some design ops teams are actually losing the thread of what they should be doing?

A. You probably know my answer: It depends. <laugh> It depends on the design ops position, as well as the organizational and company needs and priorities.

Design operations comes in many different flavors. You could almost think about it from a UX design perspective: there are UX design generalists, and there are information architects, there are interaction designers, design system designers, all these subsets and more.

And I think design ops is really no different. There are design ops generalists; I often consider myself one, I do a little bit of everything from focusing on team culture and health to knowledge management, to documentation, to Research Operations, to identifying tools, documenting them, software management, vendor management, so on and so forth — everything under the sun.

I think in a really mature organization — some of the big ones I think about with design ops are Atlassian and Meta — they have huge design ops organizations and a lot of practitioners. And they’re very mature operationally. They have many levels of design operations and they have people and positions that range from generalists to those working within a specific team or focused on specific areas within Design Operations pillars. There was a great talk at the DesignOps Summit last year, which was hosted by Rosenfeld Media, around being a chief of staff for design and how that too is a part of design ops. So I think there’s a lot of different flavors and it just depends on the needs of the organization as well as the maturity.

Avoid the trap of tackling everything at once

Q. Are there certain traps that a design ops team should try to avoid? Especially if it’s starting up, are there some things that they might be pulled into where you go, “whoa, no, danger, danger, don’t do that one.”

A. I think one of the dangers with a new design ops team is getting pulled into everything — period. I realize it’s a very broad statement, but there is so much to do all the time. And especially if you’re working in an organization where you’re more on the generalist side. I think it’s easy to just say, “I need to tackle everything and talk to every person and know everything that’s going on all the time,” and just become overwhelmed with trying to address all of the pain points and opportunities. If you don’t define your scope in design ops or it’s not defined for you, it’s easy for everyone to just start coming to you with things that should be done — or they want to be done

And you aren’t prepared to say, “actually that’s not within my scope.” Or, “that’s something that could be escalated to this other person or to a manager.” Or, “I hear you, but will need to address this at a later time.” So I think it’s really about defining the scope and making sure that you’re willing to be nice and pleasant, open to everything, but also being able to clearly say “sorry, that’s not something that I can tackle now.”

Saying no is I think a superpower in general. Saying no with tact is a superpower.

Q. I can definitely see that in an ops role where you’ve defined yourself as making sure everybody’s satisfied with their jobs and empowered to do their jobs really well, that could turn into everything under the sun.

A. It’s exciting because I think in this design ops function and in this career, you can go a lot of different directions and there is a lot of opportunity to dive deep, as some do, or stay broad, such as a generalist. There are people who are just focused on software as design technologists. There are generalists; there are people who focus solely on employee experience. And in each of these areas these practitioners bring their unique skill set to tackle the challenges and opportunities they are presented with —  which I think is really exciting. So I don’t feel as though you’re really stuck in this place that’s never going to evolve or change. And if you’re interested in something, you can go learn about it, and pivot your position. 

I mentioned that a lot of people I meet in design ops come from really different backgrounds, and it is really great to see how those practitioners leverage their unique skill sets to do impactful work. Maybe it’s an educator and that’s a huge aspect of our work — focusing on education and communication. Maybe it’s a researcher because at the end of the day, you’re doing user research on your users or product teams. So I think it’s really interesting to think about the skill sets that are brought into design ops jobs.

Design ops versus research ops

Q. Speaking of doing user research on your designers, the people that you’re helping, there is in the world starting to be a function called user research ops. To you, is that the same as design ops? Is it a subset of design ops? Is it a totally different thing?

A. Ohhh, it depends.

Q. You’re going to use that all the time, aren’t you?

A. Yeah. All the time.

I think of research ops as its own branch within the operations tree. Definitely a parallel to design operations. Research is part of the design process, and therefore you could include it in the scope of design ops. As I mentioned, some of the work that I did, as well as my associate DPM, in my last team was research ops focused because there was nobody else doing it and it needed to be done.

I think research ops is very much emerging as its own role, in its own space. There is so much to tackle there — there are so many processes and tools specific to research, as well as management needed to execute the research efficiently and effectively. I think that one of the goals of research ops, amongst many others, is often talked about as defining the value and impact of research at scale. And within research ops you have specific research knowledge management, you have specific research software management, you have participant management — just to know a few. It is its own space.

I think it really comes down to the maturity of an organization or team to see if they have research ops and/or design ops as functions. Are they melded? Are they totally separate? Do they even exist?

There is definitely a lot of crossover, and anyone working in design ops and research ops can share a lot of knowledge and can partner across teams.

Q. The word “democratization” comes up a lot. Democratizing research, democratizing design related stuff, democratizing analytics. You know, empowering people who don’t necessarily have a full-time professional credential or a degree in something to be able to go access these tools that let them do pieces of it. Do you have a take on that concept of democratization? Have you dealt with it?

A. It’s a great question and something I’ve had many conversations about. I’m a believer in democratization, but you know, it’s a personal opinion. Let’s share information. Let’s stop saying, “This is my template;  you can’t have it.” I don’t believe in that. Instead let’s share our learnings, templates, and findings.

Let’s take research, for example — I believe the democratization of research can be very impactful in an organization. I’ve actually had a lot of conversations with researchers about this. And I would say for the most part, it can be an exciting next step in research maturity within an organization. I feel as though research teams, depending on the organization’s size, might consist of a small team, but they are doing incredibly impactful work, and everyone should have access, at least visibility, into this work, and these learnings and findings.

That being said, there can also be a danger to this. For instance, if that research is not, let’s say, tagged in a certain way, or clearly communicated to those without research knowledge it could be used incorrectly. Additionally, depending on the type of research, it can be scary (for researchers) for someone to just walk up and say “Sweet, here are the outcomes. I’m gonna take that and run it with my product group to make final decisions,” rather than that person having an understanding of the larger scope and implication of that research.

I think there’s this balance that needs to happen, which is yes, let’s democratize access to learning and findings, but let’s do it in a way in which we also provide education throughout this process. I make that sound a lot simpler than it is in reality. This is an incredibly complex issue because to educate, we need to understand if a usability study has the same weight as a thousand person survey. And what were the questions asked? How do our learnings impact our product or a space within a product? Those who are outside of the research teams need to be open to taking the time to learn.

So I think there’s an opportunity to educate around what user research is, why it’s important, and the different types of research. Maybe there’s even an opportunity to share portions of research that could be accessible to an entire organization or company, to lean into that democratization with the caveat that this is internal information and if you want to use it for your own product or project or your team, talk to the researcher, talk to the product or program manager who understands in detail before taking it as “the final word”. 

So personally, I’m all for it… with guardrails and guidelines in place and an emphasis on education. 

How long does it take for design ops to have an impact?

Q. A lot of people ask me, how long should I expect it to take to reach the flowering of this initiative that we’re trying to do? Like, “I’ve been trying this for six months and I’ve made only this much progress and I’m wanting to make this much more. Is that normal? Should I expect that? Or does it mean there’s something wrong because it’s going too slowly?” How do they know when they’re making progress, what’s reasonable to expect versus what are dangerous signs that they should worry about?

A. Look, everything we’re talking about could be a book or a conversation all on it’s own, but within the short time we have,  I think some of the biggest challenges that design ops practitioners face, especially when it comes to implementing change, is change in itself. Change is scary. I’m a believer that incorporating a change management process, as a part of design ops work, is what can make it more successful. It is not a standalone, like, “I’m here and I learned what’s wrong and I made these processes and you should follow them.” That doesn’t work in my opinion.

So I think if it’s not working as expected, and you thought it would take a month and it’s six months down the road and nothing’s changing, maybe it’s time to go back to the beginning and ask, “Well, why isn’t anybody adopting it?”

Maybe it’s that you need executive leadership buy-in from the top-down, or going through a better process, or understanding that maybe no one wants to adopt this because they’ve tried it and there are things broken in the process. These are just some examples — I realize there can be a lot of reasons for what something might be taking longer than expected.

So I think there’s a lot of different reasons to go to look at the time things take. But I think it’s also very important to remember that change takes time. You’re not going to snap your fingers and it’s going to happen overnight.

How to measure the value of design ops

Q. How do you measure the value of a design ops team?

A. This is something that has been widely discussed and is something I would say that is currently being discussed amongst the global design ops community because there isn’t one specific, or right way to measure. There are a lot of different ways, and I think a lot of different teams are experimenting with how to measure the value or impact because so much of our work is not as simple as “I reduced the hours in my sprint cycle” and things got through production quicker.

A lot of our initiatives take much longer and are more challenging to quantify. How do you measure a team’s happiness at work?  Or a team has all of a sudden gotten more hours back in their day because they didn’t have to search for information or they have less unnecessary meetings on their calendars. Those are actually some of the data points that people in design ops are trying to measure, saying how many hours a day do you spend in meetings? Or how many hours a day do you spend looking for information? and how can we figure out how to make an impact in those areas to allow practitioners to do the work they want to be doing versus spending time on unnecessary tasks or being pulled in too many directions. 

There are also initiatives that I’ve conducted through trying to measure design ops initiative on an impact scale for practitioners. How impactful was this initiative in your work and why? That seems to be a great way to get a baseline of impact and of course if you can get any quantitative data for those questions about those initiatives, that’s even better. 

There are a lot of conversations referring back to the quantitative measurement of time and then essentially to financials for the business. So if a practitioner gets an hour back every day, here’s what their salary is, here’s how much money we’re getting back as a company because that designer is now focusing more of their time on the essential duties of their work. 

So there’s a lot of different ways that design ops practitioners measure impact and it’s still a very hot discussion topic.

I asked this question to a member of my design ops group last year who’s a longtime colleague at Meta, who’s been there a long time, and it’s a very mature organization, and she’s still figuring it out. And I thought to myself, “Well, if you’re still figuring it out, I feel way better.” <laugh>

Q. If someone’s starting up a design ops function, do you have any advice for them?

What to do first or what to watch out for?

A. I certainly do! My manager at my recent position at REI gave me the best advice, and I have been passing it on ever since. It is: “Don’t let perfection be the enemy of good.”

I think that is some of the best advice I have gotten as a design ops practitioner, and in general. I can only speak for myself, but I think that a lot of those in design ops might define themselves as overly organized, edging on perfectionists,  and we strive for creating the best and right solutions. Sometimes, though,  you just have to say, “This is what I built. It’s good enough for now. It solves the current pain points or challenges. We’ll keep iterating to make it better”

Stairway photo by Nicolas Hoizey on Unsplash

The opinions expressed in this publication are those of the authors. They do not necessarily reflect the opinions or views of UserTesting or its affiliates.