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,
and 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 DesignOps is something that
continues to be top of my research priorities.
It has been a research priority of mine for a number of years now, actually.
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 DesignOps expert,
which is exciting for me because I feel like I've just
started to get my own understanding of DesignOps and the state of it more specifically.
So yeah, what are you seeing with the state of DesignOps these days?
Yeah, the state of DesignOps,
it's like I said, ever-changing, right?
I really do think we're at a place where DesignOps is gaining ground,
becoming more of a house from term.
I really think 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.
Just to put some more concrete numbers behind that,
I actually did a study just last year when I was focusing on just that, the state of DesignOps.
In that study, I really wanted to know how many teams were really doing DesignOps.
The way I defined that was I came up with a list of 34 different items and artifacts
that really had to do with DesignOps across
these three areas of our framework as we've defined DesignOps here at NNG.
During that research, I found that out of those 34 items across our framework,
on average, practitioners only reported the presence of 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 DesignOps activities and artifacts.
So really interesting, right?
But I do think the state of DesignOps is burgeoning, shall we say.
Overall, maturity might be pretty low as evidenced by that research,
but I think awareness is high and efforts are increasing from folks.
I see that as really a positive thing and it's
evidence of the growth of DesignOps overall across the community.
Yeah, that's remarkable. So basically,
people were not doing DesignOps as far as it's been defined.
So yeah, how would you define DesignOps then?
Yeah, and just one of those, maybe people were doing DesignOps,
but they weren't calling it that.
That's another interesting factor that's been going on.
I think DesignOps has been increasing in understanding.
Yeah, we have a formal definition of DesignOps that we work with.
Formally, what we say is DesignOps 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, DesignOps 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 what different organizations need in order to achieve that vision is going to differ,
depending on their culture, their goals, their maturity.
So DesignOps 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 DesignOps 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, 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, 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,
or a lot of room to grow, I guess to put it nicely.
Now, you went to a design ops conference recently, and I'm curious how that all went.
What was memorable from that?
Yeah, it did.
I had the chance to go to, it's Rosenfeld Media's Design Ops Summit.
And this is a conference that that group has been putting on for a while.
It's a really, it's a great summit.
They really centered around people who are doing design ops.
So they feature speakers who are at different places in their journey of design ops,
making progress at their own organizations, and who are open to sharing their experiences.
And so that's great.
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.
It was a really wide spectrum of the different states and structures of design ops.
Design ops teams of the focus areas of design ops teams, or just individuals who are trying
to lead design ops efforts across organizations, what they're pursuing.
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 to shape design ops focus really still hold 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 levels to how
well you can do design ops?
What would you say is the strata of expertise there?
Yeah, that's an interesting question, because in some ways there are definitely levels and
there is definitely a maturity aspect to design ops, whether there's general awareness of
an organization, how much support there is from leadership to invest and formally recognize
design ops efforts.
All of that being said, it is in some ways kind of difficult to just kind of prescribe
an overall maturity to design ops in kind of blanket terms, because various types of
teams need different levels of design ops, if that makes sense.
So for one, let's say smaller organization, one person leading design ops efforts who
has 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 different UX hierarchical structures or organizational structures, there
are so many different types of UX team structures.
You've got like your centralized, you've 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 whether you should even have, I guess,
yeah, that's my next question.
Should teams have a designated design ops role?
Yeah, I hate to use the old UX adage, but it honestly really does depend.
A lot of times too, let's just face the facts, 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 design
ops efforts and then takes that on themselves, right?
And 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 seed that
they're planning grow into something bigger and stronger.
Yeah, and 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,
the thing that comes to mind for me is also design systems themselves.
And I am a bit, I guess, appreciative of the fact that now design systems are being seen
as 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.
Exactly.
So yeah, totally.
It's kind of a great comparison because design systems are so easy to do.
And because design systems before, they really became more widely recognized as valuable.
You're right.
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 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 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.
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 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, 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.
You know, 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 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 up
side and design management side.
And that's what organizations should do, actually, if they have both of those roles, really stand
to understand the difference in those roles, where there's overlap and where there's partnership
opportunities to.
Hmm.
Okay.
Yeah.
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, if I'm getting that right.
Yeah.
You can have design ops professionals that contribute on various levels, but design managers
focusing on the day to day work, helping raise the quality of the quality bar for the work
their teams producing, managing schedules, helping people identify career opportunities
and growth.
And like you said, just poor performance review and whatnot.
Certainly design ops 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 talked to and the professionals I talked 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 ops 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 put 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 listing tour, do some interviews with people who are
internal to the design team and also design team partners.
So people who 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 seem to be the biggest pain points from
your research and let those drive the focus of design ops efforts 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, and more so the idea that 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, 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 the return on that effort and on that work, that's a huge opportunity to really
grow it as a whole.
Especially if you are that person who's taken the mantle of, I will be the design ops evangelist
for the organization, then at least you can get some support.
Yeah, exactly.
Yeah.
So for those that are aware that they are doing design ops work, what should those folks that
have high level of maturity or capability, what should they do to improve their craft?
Yeah, that's a great question, because 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, 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 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 from 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.
You 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 far 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, you know, 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, um, 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 centuries, like 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.
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, their 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, 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, you know, just the stuff we've
been talking about, where to focus their efforts, how to integrate design ops into their organization,
like 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
ops takes over months and quarters inside organizations as people make some progress
on those efforts.
So I'm excited about that.
You 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 with 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 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 on 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 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 connect with me, connect with me on LinkedIn.
I'm on LinkedIn as KW 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
chat about some of these things.
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 8 through 21 and February 12 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 rate
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.