16. What's up with DesignOps? (feat. Kate Kaplan, Insights Architect at NN/g)
30:12 Share

- This is the Nielsen Norman Group UX Podcast. I'm Therese Fessenden. December is a great time for reflection and therefore a great time to reflect not just about what we design, but how we do design in the first place. So I thought it would be fitting to interview Kate Kaplan, Insights Architect at NNG. Kate has spent the last several years studying not just end users, but UX professionals all over the world.

She's interested in how they get their work done. She teaches the course DesignOps, Scaling UX Design and Research, along with five other UX certification courses. So we talked about the state of DesignOps, how it's defined, who's responsible for it, and how teams can level up their ability to better manage their design work, especially as we face the beginning of the new year. This was a really fun podcast for me, and I hope you enjoy it as much as I did.

So without further delay, I'm pleased to welcome Kate Kaplan. Welcome to the podcast. How are you doing? Thanks. I'm doing great.

Yeah, and you've been up to a lot of stuff lately. I mean, all of us at NNG are typically pretty busy this time of year, but you've been up to a lot. Yeah, I've been researching a handful of topics, but design ops is something that continues to be kind of top of my research priorities. It has been a research priority of mine for a number of years now, actually. And honestly, it's always changing, always fresh. So it stays top of mind for me. And it's always intriguing to keep following.

Yeah. So you're like the resident design ops expert, which is exciting for me because I feel like I've just started to get my own understanding of design ops and the state of it more specifically. So yeah, what are you seeing with the state of design ops these days? Yes.

Yeah, the state of design ops, it's like I said, ever changing, right? I really do think we're at a place where design ops is gaining ground, becoming more of a household term. You know, I really think, you know, just to describe the state of it and throw out a few words, it's blossoming, if you will. It's hopeful. It's gaining ground. You know, just to put some more concrete numbers behind that, you know, I actually did a study just last year when I was kind of focusing on just that, the state of design ops and

And in that study, I really wanted to know how many teams were really doing design ops. And the way I defined that was I came up with a list of like 34 different items and artifacts that really had to do with design ops across these three areas of our framework as we've defined design ops here at NNG. And during that research, I found that out of those 34 items across our framework, you know, on average, practitioners only reported the presence of like seven and a half of those things.

Even more interesting, the mode for the number of items reported for each area of our framework was zero. So that really meant that the majority of people who took part in this research, and I think there were over 500 participants, reported the absence of every single one of those design ops activities and artifacts.

So really interesting, right? So, but I do think, I do think the state of design ops is, you know, burgeoning, shall we say, like overall maturity might be pretty low as evidenced by that research. But I think awareness is high and efforts are increasing from folks. And I see that as really a positive thing. And it's evidence of the growth of design ops overall across the community.

Yeah, that's remarkable. So basically, people were not doing design ops, like, as far as it's been defined. So yeah, how would you define design ops then? Yeah, and just one of those, you know, maybe people were doing design ops, but they weren't calling it that. That's another kind of interesting factor that's been going on, I think.

design ops has been increasing in understanding. And, you know, yeah, we have a formal definition of design ops that we work with. Formally, what we say is design ops is the orchestration and optimization of people, processes, and craft in order to amplify design's value and impact at scale. And I mentioned, we have a nice little framework that kind of breaks that down into more specific components that are kind of under the hood of that umbrella definition.

But really, just kind of simply put, you know, design ops is honestly anything and everything that's related to enabling designers to be the best possible versions of themselves while creating the best possible designs. And you know, what different organizations need in order to achieve that vision is going to, it's going to differ, right, depending on their culture, their goals, their maturity. So design ops could look like any number of things like

education and upskilling, workflow design, tools optimization, whatever really is going to best enable and fulfill and empower designers in an organization. Got it. So yeah, I think I remember sitting in on the design ops class a while back and

One thing that really stuck with me was thinking about how design is done. And it's interesting to me, just that whole concept, because I think we've gotten really good at designing interface elements. And now we've got these design systems, which can help us do design at scale. But

It's interesting to see how there's not much uniformity in how design is done. And that's not necessarily a bad thing, but the fact that design as a process and thinking about the design of that process, that's something that I'm glad that people are starting to think about because in the past, it was just something where it's just like, all right, we're doing design. You kind of had to figure out how to do it. Yeah.

Like that's a huge win too. If you're doing UX, if you're doing design, especially at an organization where that hasn't been valued and systematized in the past, that is a huge win.

But now it's kind of at a place where I think in many ways, designers, you know, we've won. We have a seat at the table in a lot of places, but we're being asked to do a lot now. And we have to, we're at a place where we have to start putting some intentionality around how we design our own processes, our own tools and our own workflows and how we share and collaborate with each other. Yeah. Yeah. So on the topic of what is the current state of design ops, I know you mentioned in that research that there's

a lot left to do, a lot of room to grow, I guess, to put it nicely. Now, you went to a DesignOps conference recently, and I'm curious how that all went. What was memorable from that? Yeah, I did. I had the chance to go to Rosenfeld Media's DesignOps Summit. And this is a conference that that group has been putting on for a while. It's a great summit. They really centered around

people who are doing design ops. So they feature speakers who are, you know, at different places in their journey of design ops, making progress at their own organizations, and who are open to sharing their experiences. So that's great. You know, I really think what was most memorable from this year, what kind of stuck out for me, I guess, is that

I just saw a lot of variation, you know, there's a really wide spectrum of the different states and structures of design ops teams of the focus areas of design ops teams or just individuals who are trying to lead design up to efforts across organizations, what they're pursuing. You know, I've long held the view that

those who are doing design ops and doing it well are probably doing it differently. And I saw that kind of reflected there in the different approaches, focus areas, structures that design ops organizations were taking. So I think even as design ops does mature in some ways, like we were talking about, that principle of doing what is best for the organization and letting the organizational needs, the design team needs shape design ops focus really still holds strong.

Okay. So yeah, so I guess the variety of ways to implement design ops can be a good thing because it's also allowing teams to explore new techniques, new best practices, and really kind of grow the space, it seems like. Absolutely. Yeah. So I guess on the topic of the teams that are doing it well, are there like levels to how well you can do design ops? Like, what's the

What would you say is the kind of strata of expertise there? Yeah, that's an interesting question because in some ways there are definitely levels and there's definitely a maturity aspect to design ops, like whether there's general awareness of an organization, how much support there is from leadership to invest and formally recognize design ops efforts.

All that being said, it is in some ways kind of difficult to just kind of prescribe an overall maturity to design ops and kind of blanket terms because various types of teams need different levels of design ops, you know, if that makes sense. So...

For one, like, let's say, smaller organization, one person leading design ops efforts who has, you know, buy in and leadership support, and they're doing this across a couple of teams that that organization might have, that might be what they need to really deliver impact in this design ops area.

But if you look at another organization, maybe a larger organization that has a lot of teams, maybe they're dispersed across different locations and they have a lot more kind of moving parts, that same level of design ops would, of course, really highly struggle to deliver impact. So I kind of see the answer to that question as there are aspects of maturity, but

Sometimes it's helpful to think of it in terms of just different classes of design ops, kind of the different structures and shapes that design ops can take based on what an organization needs. It's dependent on the size of the team and the company, the needs of that company. And actually, one of my current projects is working on a framework to kind of document and communicate all these different classes of design ops kind of structures that teams can take and showcase some examples of them. So I'm really excited about that.

Yeah, that's awesome. Yeah. And thinking about like different UX, like hierarchical structures or organizational structures, there are so many different types of UX team structures. You've got like your centralized, you got decentralized, you've got hybrid, but then you've also got the size of the team itself playing a role there. So I could see that playing an important role in like whether you should even have like

I guess, yeah, that's my next question. Should teams have like a designated design ops role? Yeah. You know, I hate to use the old UX adage, but it honestly really does depend. You know, a lot of times too, let's just face the facts. Like a lot of times most teams who need design ops, they don't have just kind of like carte blanche authority and support to kind of just stand up a full-time design ops role.

or a team even, as a first step. I mean, if you do, that's amazing, that's great. And we should commend the leadership behind you that supports that. But likely that buy-in is going to come from some individual, somebody on the design team who probably through their own pain points and struggles recognizes the need for some kind of design ops efforts and then takes that on themselves. And

you know, it's extra work, of course, but with successful tracking and measurement of those efforts and what they're achieving, hopefully that effort that they're taking on is going to additionally get more buy-in and support for design ops efforts and help that see that they're planning grow into something bigger and stronger. Yeah. And, you know, thinking too of, because this is a common question I do get, Therese, like you mentioned, like when does a team need design ops? Like when is it time for that formalized role?

One of the indicators to look out for is if you, if your team is overwhelmed day to day by operational and administrative tasks, so much so that you're spending equal or more time doing that stuff than you are your real craft, design, research, whatever it is that you do, then it's probably time to make the case for a full-time role.

And the most straightforward way to do that is I think the easiest thing to try to gain that support is to start tracking your time spent on day-to-day things and your team's time spent on day-to-day things. And if you can kind of show that a significant portion of your team's daily time consistently is spent more so on that type of operational work, tool management.

process documentation, artifact collection so that there's a shared knowledge resource or something like that. That's a good case, right? That not only is a full-time design ops role perhaps helpful, perhaps warranted, but it's probably going to increase the bottom line for the design organization because designers are going to be able to spend more productive time designing what they're best at and more hard to do.

Yeah, I think that's a really great point. And actually, when you mentioned things like process documentation or artifact collection, like the thing that comes to mind for me is also like design systems themselves. And I am a bit, I guess, appreciative of the fact that now design systems are being seen as like

a full-time job as opposed to what they used to be seen as. It's just like, oh, you can take this on, right? You can put this together for the entire 500-person team, right? And then it ends up not being that easy. So yeah, totally. It's kind of a great comparison because design systems before, they really became more widely recognized as valuable tools

you're right. Like people had to take that on as kind of a side job. And in some organizations, design ops is kind of treated the same way, right? They're having to take on these efforts as a side job. And so if you're in that position, that can work for some organizations, right? A lot of people do design ops that aren't,

don't have design ops in their title, but it really does. If that is the case, those kinds of design ops responsibilities have to be recognized and acknowledged as part of the job responsibilities of the people who are doing them in order for that to work. Yeah, absolutely. So yeah, in terms of what people are

misconstruing about design ops as like a responsibility and as a function. What are some of these common mistakes that you're seeing? I think there's a lot of interesting ones just because we're still kind of, a lot of organizations are still defining what design ops means. It is a fairly nascent comparatively to UX and design in general as a field. It's a fairly nascent kind of

community, you know? And so I think a lot of the misunderstandings, honestly, they stem from kind of a misguided attempt to pigeonhole design ops into something overly specific. Like one of the misconceptions I hear a lot or myth that I hear a lot is kind of design ops is equal to design management, that those two things are the same thing. And, you know, like we said, sure, design managers are probably doing some level of design ops as part of their job responsibilities, even if they're not calling it that.

But design ops just encompasses so much more than a typical management type task we might think of like workflow, oversight, or people management. And also the opposite end of that, like you don't need to be managing people in order to be doing design ops. Another myth is that design ops has to be a specialized role. So in other words, you can't be doing design ops if you don't have design ops in your title. That's not true. Anybody can be doing design ops. And there might be more...

formal kind of dedicated roles, specialized names for roles at more formal design ops practices. But like we said, not every team needs that, right? And like I said, this approach of people who are designers, design managers, maybe taking on design ops accountability, sometimes that makes sense as long as those responsibilities are acknowledged as part of their workload and performance.

Hmm. I do want to pick your brain a bit more about the concept of design ops not being the same as like design management. Like what would you say is a design ops task that would be really alarming if a design manager did it? Well, what would be alarming is if a design manager were tasked with

design management, as well as the universe of design ops. That would be just so much to put on the shoulders of one person. It would be overwhelming. It would be too much to ask. So while there are some overlap and some things that design managers or design ops professionals do, I think that's the crux. It's too much weight for one role to be expected to carry. So we can partner

from a design upside and a design management side. And that's what organizations should do, actually, if they have both of those roles, really stand up and understand the difference in those roles, where those overlap and where those partnership opportunities do. Okay.

Yeah. So, so it seems like design management, what design management has that not necessarily design ops would be in charge of would be things like people management and like maybe mentorship and not that design ops folks can't do mentorship, but that that would be an expected function of like a design manager.

Am I getting that right? Yeah. And you can have design ops professionals that, you know, contribute on various levels, but yeah, design managers focusing on the day-to-day work, helping raise the quality of, of the quality bar for the work their team's producing, managing schedules, helping people, you know,

identify career opportunities and growth and like you said, just performance review and whatnot. Certainly design apps can have a role in shaping processes around that, right? But they may not be doing that day to day. They're more so developing programs, practices, and tools that the whole design organization can use and can benefit from to do their work better. Got it. Okay.

So I guess on the topic of those who are not doing design ops, like if somebody is brand new and it's like, this sounds like a good idea.

Where should those folks start? Yeah. So it's usually when design ops is born into an organization, if it's not something that's called and recognized on by leadership, which I don't think traditionally it is by someone, you know, the teams that I talk to and the professionals I talk to. So if it's a new organization or an organization that's kind of new to design ops,

they're looking for where to start, just look around, right? Where's the pain? Go to where the pain is. What are the current biggest hurdles and struggles that the design team faces? Like what's standing in their way day to day? Diagnose those and start treating them. So in other words, treat starting a design apps practice or identifying where to start, just like you would any other design problem. Spend some time

defining the problem first so that you can build a better solution, so you can build a more focused team that's actually going to deliver value.

Good ways of doing that are like our own research tools to be meta. So launch an internal survey with your design team, right? Figure out where they're feeling those pain points, how often they're feeling those pain points. Follow that up with kind of a listening tour, do some interviews with people who are internal to the design team and also design team partners. So people in the design team work with and collaborate with day to day and try to really understand where those hurdles are. I'll mention just our design ops framework that we have

published on our website is really good for guiding those conversations because it's kind of a landscape of where those pain points might fall and kind of use that to identify where they are. So use that, identify where they are, prioritize what seemed to be the biggest pain points from your research and let those drive the focus of design ops efforts, you know, until they're alleviated and then keep going, do it again.

Yeah. I think you bring up a really important point too, that it is a landscape. And to think of what you said earlier too, when you did that research with all those practitioners and the mode being zero, right? And more so the idea that there's...

There is design ops happening, but maybe people aren't calling it that. And I think that's a really important point too, because maybe some teams are already doing some level of design ops work. They just don't really realize it yet. So yeah, that's a great point. Yeah, absolutely. And maybe they're not tracking it formally yet either. So maybe if there are efforts people are taking on that feel like design ops, but design ops isn't a term used in the organization or something that's recognized,

tracking, benchmarking and tracking your progress, showing that hopefully can start to get some recognition for that other type of work that people are doing. Yeah, absolutely. Showing like the return on that effort and on that work. Like that's a huge opportunity to really grow it as a whole. Especially if you are that person who's like taken the mantle of, I will be the design ops evangelist for the organization, right? And then at least you can get some support. Yeah, exactly. Yeah.

Yeah. So for those that are aware that they are doing design ops work, what should those folks that have, you know, high level of maturity or capability, you know, what should they do to improve their craft? Yeah, that's a great question because, you know, a lot of times people start out in design ops, it's almost a damage control kind of situation. They are looking around at the biggest pain points, the red flags, and trying to solve those.

Once those are taken care of a little bit, once those are alleviated, I guess the question is like, what's next, right? So I think organizations that reach that point are a little bit more mature or have more stable design ops teams can start to focus less on damage control and more on design organization-wide initiatives. So they might not be thinking about one-off kind of efforts, but more so things like,

how to create wide-reaching underpinnings for the design team that everyone can utilize. They might be focusing on things like culture or onboarding and hiring, things that are not so much the first kind of red flags, well, most often, that we'll see when we're talking about things like workflow and team-to-team tracking, right? So they might be focusing on those wider kind of higher-level initiatives.

I say also, you know, they'll reach the point eventually where design ops teams who are large enough are going to need to focus on their own programs too for planning how they track their efforts and evaluate their progress, how they focus on how they're going to shift and evolve as business needs shift and evolve.

How to elevate their own leadership, you know, and their own impact to be parallel with other departments in their organization. So starting to really treat their own team as something that's growing and needs to scale over time, not just an entity that's focusing on scaling the design work over time.

I see. So really turning the focus inward seems to be a good strategy, both for folks who are newer to design ops as well as those who are already doing it to some extent, but in a proactive way as opposed to like, oh crap, this is on fire. We need to fix it. Exactly. You know, that brings up, you know, looking inward is such a great way to put it because I think one of the other really

for reaching misconceptions of design ops, especially for those kind of newer getting started is that design ops is already really defined. It's rigid. It should look the same from team to team or org to org. And it doesn't and it shouldn't. Like we talked about the shape of the design ops, the focus of design ops in your organization, it should come directly from the biggest hurdles that designers in your team face. And that's probably going to be unique. It doesn't look the same from organization.

to organization. So I guess kind of a word of caution there is starting out, don't attempt to model your design ops efforts or roles or team structures off of what another company is doing, even if they're doing it successfully. Like you said, Cherie, look inside, not outside for where to start. Comparison is the thief of joy anyway and rarely gets you anywhere. I mean, I say that both like

partially joking, but also seriously, like you're right. If you were to look to a huge company, like, I don't know, there are lots of great companies doing this really well. Um,

But looking at some of these, you know, Fortune 500 companies and then saying, oh, well, I have a team of 10. So we'll do it the same way. It's not going to necessarily work as well. It's so true. So it's great to look across. And I'm so glad one of the great things about the design ops, I think greater community is like I said, people are so open to sharing what they've tried. They're experiments that have been successful or needed iteration. And so while I think that's great, yeah, it comes with a little caution of not just kind of

lifting something that someone else has done and expecting it to work, but taking inspiration from whatever lessons there are to be learned there. Absolutely. So yeah, looking at looking inward and looking at what's next as it relates to what you really need as an organization. So totally. So

So yeah, on the topic of what's next, what's next for you? What do you have on your plate coming up? Yeah, I have some, I do have some upcoming design ops research and projects that I'm really excited to invest some time in. I am planning on devoting quite a bit of time in the upcoming year to design ops. One of the things I'm most excited about doing is launching this

longitudinal study I've been planning for a while. I'm going to plan to launch that early next year. And the idea is to follow some design ops teams or even just design ops teams of one, right? Who are getting started and kind of figuring out

Just the stuff we've been talking about, where to focus their efforts, how to integrate design ops into their organization, what that looks like in terms of how they're shaping their projects and who they're hiring, if that's changing, how they're evangelizing, like you said, design ops across the team.

tracking their efforts, you know, and just kind of the different shapes that design ups takes over months and quarters inside organizations as people make some progress on those efforts. So I'm excited about that. I know it's going to be a long-term effort. I mentioned too, I'm working on that framework, you know, the various...

classes of design ops teams and structures. I hope that's going to be a useful tool for design ops teams who are looking for potential next steps, maybe teams that have gotten a little bit of a foot in the door, but are really looking for where to go next. And, you know, we talked about maturity too. I'm going to be continuing the design ops maturity study to just kind of

continue tracking, hopefully, the increases in the indications of design ops maturity across organizations. On that, I really just have a hunch that because of the blossoming state of design ops, that through that work, we're going to see continual increases in maturity from year to year. And that's really going to be something we can celebrate and share ongoing.

Yeah, I'm excited. I think it's like the new frontier of design and really taking us to the next level. But yeah, Kate, this has been so much fun. I feel like I have...

my mind blown every time I talk to you. So lots of things for me to think about, and I'm sure our listeners will agree. But yeah, if anyone does want to follow your work, what social media channels or handles can you point people to? Yeah, for sure. And it is really an exciting time for design ops. So there's a lot to collect. There's a lot to say. There's a lot to research. There's a lot to share, I think, no matter where you are on your journey. And just on the

on the note of sharing, if you are someone in the design ops field, you're a team of one, you're just getting started, you don't have design ops in your title, don't feel like that excludes you from the conversation. I think the more people that share their experiences, no matter where they are in their journey, the more we're going to continue to collectively grow. So I look forward to hearing from others too. And I hope people, you know, if you want to

I hope people will continue to kind of follow and find value in our design ops research. I'll continue to publish that on our NNG site. So be on the lookout for upcoming research and articles. If you want to, you know, connect with me, connect with me on LinkedIn. I'm on LinkedIn as Kate W. Kaplan. I love talking design ops to anyone, anywhere on their journey. So feel free to reach out, participate in our research or just make a connection and

and chat about some of these things with them. Awesome. Well, thanks, Kate. It's been so much fun. And yeah, hope you have a great rest of your day. Thanks, Therese. Always great talking to you.

Thanks for listening to this episode of the NNG UX podcast. Feel free to check out our website where you can find Kate's work and maybe sign up for one of her classes. Our next virtual UX conferences will be happening January 8th through 21 and February 12th through 18. That's in 2022. Hard to believe. You can also find thousands of free articles and videos on this and other UX topics.

To learn more, go to nngroup.com. That's N-N-G-R-O-U-P dot com. Finally, if you like this show and you want to support our work, please leave a rating on Apple Podcasts. And no matter which platform you're on right now, please hit subscribe. This show is hosted and produced by me, Therese Fessenden, and all post-production and editing is done by Jonas Zellner.

That's it for today's show. We wish you and your loved ones a happy holiday season. And until next time, remember, keep it simple.