👉 Note: We apologize for the recording quality, which has been affected by technical difficulties
Episode highlights
- 00:03:02 – Defining Operations
- 00:12:17 – Empathy and Observability in Research Ops
- 00:21:01 – The Benefits of Ops
- 00:27:10 – The Need for Specialized Ops Roles
- 00:30:20 – What Makes a Good Design Ops Practitioner?
- 00:33:32 – Closing Thoughts
About our guest
Su Milazzo is a design and product operations leader with over 10 years of experience driving change in UX and cross-functional operations. She has a proven track record leading global teams to create user-centered solutions for both internal and external clients.
Su specializes in blending design, strategy, and operations with a strong focus on empathy, inclusive practices, and collaboration across all levels of an organization.
I prefer making gradual changes, introducing small, manageable shifts that people won't notice immediately. Over time, those small changes add up and start making a real difference.
Podcast transcript
[00:00:00] Tina Ličková:
Welcome to UX Research Geeks, where we geek out with researchers from all around the world on topics they are passionate about. I’m your host Tina Ličková, a researcher and a strategist, and this podcast is brought to you by UXtweak, an all-in-one UX research tool.
This is UXR Geeks and you are listening to an episode with Su, who is a Dallas based designer and a current design ops manager with over dacade she’s done everything possible in UX and we talked about the strange, messy world of operation and where design operation and research operations overlap.
Most importantly, we talk about what research operations can learn from design operations and how to actually make your own research when setting up operations. Really nice and practical episode.
Have a tune in.
A very important question. Didn’t ask you for your pronunciation of your name.
[00:01:19] Su Milazzo: Oh, no. Totally fine. So my first name is just Su. My last name is Milazzo.
[00:01:24] Tina Ličková: Milazzo. Okay, good. Mm-hmm. So, Su Milazzo, who are you and what are you doing?
[00:01:30] Su Milazzo: Great question. So my name is Su Milazzo and I’m based out of Dallas, Texas in the U.S.. I’m somebody who’s been in the UX industry for over 10 plus years, and I didn’t start, I did start off, um, in my career as a UX designer, a UX architect, very functional designer.
Throughout my career, I’ve had the privilege and the luxury of doing multiple different things such as doing research myself, gorilla user testing or gorilla research. When you have no money and you have to make research work somehow, so you get really creative with how you want to do things. From there, I’ve also been like a true UX architect, always functional.
If you give me visual stuff, I’m like, absolutely not. More recently, my career has transitioned into design operations slash product operations, which is a new term that’s out there in the world where instead of focusing on delivering upping, I focus on helping the design research content teams. I deliver their work. So a lot of folks will conflate operations with admin and it’s quite different, and I can speak to that from a design lens. All those things that I found frustrating in my handoff process, frustrating in a knowledge POV. What operations I think has to do now is highlight those friction points for internal users such as designers, researchers, et cetera, and really optimize or mitigate.
Them. So that’s kind of me in a nutshell. Other interesting facts, I used to be a yoga teacher. I have a weird obsession with dogs. In fact, I love dogs. Full stop. Like I got my husband to agree to foster a bunch of dogs during covid. That’s pretty much it.
[00:03:02] Tina Ličková: Great. I, I love that you nicely already jumped a little bit into our topic about design ops, product ops, and we will be talking about the intersection of research ops.
But let’s maybe start with the definition, because all of these fields are kind of new and product ops being there. Little bit, I would say sooner. Yes. One can argue. What are the operation about in your opinion, and how do they people help people to work?
[00:03:33] Su Milazzo: Yeah, sure thing. And I think what you bring up from a DevOps, POB being DevOps is commonplace in regards to terminology, hiring, all that kind stuff that’s been there. In my eyes and what I’ve been able to trace back, um, from a historical POB is DevOps came quote unquote first. Then it was product operations. And product operations to a certain extent was a sibling of DevOps, but not completely product operations with focus on, okay, how do we help product teams deliver products?
But then that gets a little bit confusing with what do Scrum Masters do? How does that go in line with the agile methodology? And then most recently, you probably have heard of design ops and even more recently than that, likely research operations. So some people might argue that one came before the other.
I don’t think it really matters as long as you account for both, in my personal opinion. So let’s go back to how I define whatever quote unquote operations, and I say whatever with quotes because you can really put in design, research, content, et cetera in that quoted area. So to me, think of this image, think of an umbrella, and that umbrella is operations.
From that umbrella, you usually have little spokes to help keep the umbrella fabric over it. Each spoke is a different kind of gain support. So if operations is a giant umbrella, I. One spoke is design operations. One spoke is uh, research operations. One spoke about product operation. One spoke is content operations, but what covers the, what is part of the whole umbrella is all of them.
So operation to me is making sure the folks that are delivering your product are able to not worry about the Isha. They aren’t being un inundated by blockers in the process that stop them from moving forward. What does that mean? I talked about the umbrella and how you can have all the different flavors of operations.
What this means is, for example, when I used to be a designer, I would hand off my designs from myself to a design, uh, or to a development team. In India, we would have language barriers, we’d have cultural barriers, and just a lot of confusion about, Hey, here’s a wire frame. Go make black magic outta it with no context.
No handholding. And frankly, that process was broken. It seemed simple. I’ll just give it to them. But what you’re missing is human communication, um, making sure this documentation is fully understood, and also outlining what are the expectations from both parties. The expectations were, here’s the link, but nothing else beyond that.
And no one likes to be just handed a. So putting them on my operations hat. Now, uh, if I look, go back and think about it, I would’ve said, Hey. Dev team, here’s what I’ve created. Here’s what I expect you to do, is here’s what’s in scope and what’s not in scope. How do you do that? I used to do videos. I used to do, put a red box in my wire frames and say, click here to start interaction, but then my developers try to do code the red box.
So I was trying to figure out all those stressors, like in that process of handoff, I’ve already highlighted. Four to five areas of friction points, right? Communication, lack of clarity, and just a lot of assumptions. So what operations tries to do is figure out all those friction points for the in internal individuals that are working on this product and really remove that friction.
So what happened up in that point in time is I created videos that were too long with red box. First. Dad just tried to code the red box. I was like, don’t code the red box. No one wants the red box. I know videos, videos were too long because no one wants to watch a video for more than three minutes, right?
We’re all about instant gratification. So like that doesn’t work with our human in mind at all. So that then, uh, changed into interaction gifts where I would be like, quickly, here’s the interaction, put it into a user story, go off and, um, create from here what that show isn’t basically a process being. A problem being identified in the context of internal handoff.
A process being, uh, initially developed that process then being iterated upon different versions. So red box video interaction game. It’s almost the same thing with design or even a research about how you constantly wanna iterate on something to make sure you get to a really optimal spot. So flip. Folks are always like the empathetic to your users.
I would say operations is being empathetic for the internal individuals that you are working with. For design to be successful operations comes in, tries to be hyper empathetic to those internal users to really see you’re running into these issues. It’s taking time away when you actually doing design.
What can I do from an operations perspective? To take that burden off of you and optimize not only for but with you. So that’s how I’d say operations. I explain it in this manner because when I just give out the definition of operation, I feel like it falls flat. I find through storytelling in these examples that says it showcases like.
This is how operations is used and this is how it can be leveraged. And that’s my definition of it, is show you, or I guess in this case, tell you and you listen and hopefully you have some imagery pop up in your mind versus just.
[00:08:37] Tina Ličková: And when we were brainstorming, we were talking about, and I really loved that holistic operations.
Sure. Just not looking at only into design operations because in in some companies, I know that design operations are taking care also about researchers, and I would like to really understand what do mean with holistic operations. I get the idea of the umbrella. But designers need something very different than deaf need, and they definitely need something different than researchers.
[00:09:10] Su Milazzo: Yeah, I think it goes back. Great call out to the umbrella, it goes back to the umbrella. So the core fundamentals of what you need to be a really operations practitioner are the same. Program management, change management, like those are all the same core competencies. However, how you apply them for different teams, it’s a slight delta to them.
So as a operations practitioner that wasn’t designed, there’s no reason why you couldn’t potentially pivot into research. But what you do is you take those core competencies that you already have from maybe past experiences and take on a period where you’re learning, okay, what do research teams mean?
That’s what I mean by holistic operations of it’s the same core. Just the flavors change depending on what each team needs, and I really find that when you are truly embedded in the teams that you support with, whether it’s a delivery team, that you’re trying to deliver a product or a team, that to your point is like more like a research team.
There needs to be a, it’s the same thing I mentioned before of like. When you are a UX designer, researcher, we keep always hammering into your brain, Hey, be empathetic to your users, but we always talk about external users in this context of saying, be empathetic to your internal users. So if you are supporting a team of UX researchers.
Walk a mile in their shoes. What are the pain points they’re struggling with? Sure. You have the core competencies of what you experience. Meaning from DevOps, product ops. Design ops. How do you maintain those core competencies of all the things we mentioned, change management, planning, program management, and then really dig into what does the research need? What are my researchers struggling in in their day to day? Do they feel like they’re out of the loop? Are they feeling like they don’t feel like under designed on the same page as ’em? That’s what I mean is like taking the core apply. It’s like take going wide and then going really deep into that.
That to me is more holistic of take everything you’ve learned before from other areas that you’ve applied. Supported and then go really deep in with those teams that you are now supporting. If this is where the whole idea of embedded ops is really important to me, the more how to speak to the users you’re supporting and empathize with them, the more likely you’re able to build trust.
You’re able to build rapport, and that’s gonna where. People say ops. I never really just think of design ops or research ops or even product ops. To me, ops is just ops. It’s how you go deep into each team or the team that you’re supporting that make it a little bit different at times. Not saying that you can’t specialize.
For example, I love design ops. I find design operations to be really important because I used to be a designer, so there’s a lot of empathy there. I have a lot. I can speak to the times I used to be designers. Give real life examples. However, in my career, I’ve taken those core competencies of design ops and then inherently ops and applied into product operations.
So in my current role, I’m supporting product delivery teams. I’m supporting product leadership instead. So the same thing of taking that little circle and then moving in different directions almost on a, a sliding scale, but the scale’s not really sliding. It’s just how you pivot your mind and go down deep just changes slightly.
[00:12:17] Tina Ličková: Now there are two things that I wanna ask, and I will start with the first one because the first one goes a little bit into the research area. When you are talking about entity towards your internal users and speaking to them, I would love to know here how you did your research on these users. How did you find out what they really needs?
[00:12:41] Su Milazzo: I think it depends, right? In my past lives, since I used to be a UX designer that helped inherently have a deep level of empathy, that’s something I could easily relate to when it came to creating empathy for my researchers as a designer. Going back to my past experiences and working with design with research teams, I still have a deep level of empathy ’cause there are friction points between both teams. And I guess this kind of goes back to holistic ops as well. Design ops impacts research ops impacts product op, all ops. Each other. There is no, oh, if you just have one kind of ops, you’re covered. I’m like, no. Ops has to be harmoniously all working together like an orchestra for the all the players to be like in like be aligned with one another. That’s why another thing that kind of goes back to holistic opposite is just coming to mind as well, but with the research ops, you almost apply the same ideas of how do I get user interview with my researchers? How do I understand what their perspective and it’s whole idea perception is always someone else’s reality.
What are the researchers’ perception of design? What are the researcher’s perception of operations? How do I speak the same language? How do I make sure that I’m using their vernacular vote, their nomenclature? How do I put on my deep research hat myself, even I’m not a true researcher by trade? How do I apply all the skill sets that I’ve observed and I’ve done myself to a certain extent to apply internally.
So taking all those same research methods that you typically do from the survey. And I think interview is probably the most mission critical. ’cause interviews also allow you to build rapport. That is what I did to really understand what are those pain points with my research team. Now, if you ask your research team, what things would you like me to fix?
Sometimes they may not respond. ’cause sometimes they don’t know. Sometimes it’s really hard when hearing thick of work to say, these are my problems. But everyone has frustrations, right? Having frustrations in a day-to-day work environment is human nature and very normal. From there, I then put on my observability hat.
So one of my favorite pros be the ood loop, which is observe oriented, sided act. You kind of need to put your abor observe hat on to see what’s going on around you. Can you see friction points in different areas between research and design? Research and Deb, that you can help pinpoint and sit and then help peel the layers back?
Similar to like what, whatever speaker is observing the field. When I’m looking at things and noticing things that others aren’t saying, is there a way for me to dig a little bit deeper into that?
[00:15:00] Tina Ličková: To this empathy. There are certain companies, certain people who I heard a little bit like complaining about operations in that way that I and I, I think also these operational specialists or managers were really trying to be empathetic, but what they did, and it definitely wasn’t, their goal is to put more admin, more processes on the designers or researchers. Mm-hmm. How do you make sure that you actually help with the new established processes or tools?
And that is that they are really helping the target groups that you work with and that it’s not much more burden to them.
[00:15:46] Su Milazzo: It’s a fabulous question and I think this is a tricky part when it comes to operations and it’s something I’ve observed in my career when like I used to be a UX designer. My role is very specific of I need to deliver things, work with my PMs and devs, come up with an interim solution, go out.
But I knew my design would be likely developed and used by users. Now, on the flip side, for operations, just ’cause you develop a process doesn’t mean people have to follow it. That is when people are like, oh, operations make all this doc documentation. They’re good to go. It’s successful. I’m like, no. Creating the documentation, creating the processes is not the hard part. It is a change management. That is an incredibly challenging because like deliverables are deliverables, right? Like all processes are similar in some way or another. They don’t change drastically. The core competencies are usually discovery, ideation, execution of some sort, delivery, but it’s pretty standard.
It’s the humans that are challenging, right? No one likes to change. Like change is hard, right? Not to say, uh, no one likes to change, but change is incredibly challenging. And when change is perceived as burdensome as not necessary, you’re gonna have less adoption. So that’s where what it comes to. Oh, we have this beautiful document.
Let’s go. I’ll do it. That’s where the real operation works begin because you have to convince people to work with you. It’s very similar to UX and research. People don’t have to work with you, so how do you convince ’em, Hey, this is a good idea. So one of the strategies I like to leverage is called Trojan Mice.
So when you have a Trojan horse, the horse is too dang big. So I like to Trojan mice. That works. Small pieces of change, small tidbits I can slowly insert. So before people know it, they haven’t realized, oh, I’ve actually impacted them with small bits of change. So it doesn’t feel as drastic. How do you make it, how do you remove that friction of instead of a full process, maybe I focus on just one part of that process to apply immediately and maybe even say, Hey, uh, another thing I would say is… when you are creating a process, if you create a process design or do research in a vacuum, you’re not gonna have buy-in. It’s the same principles where you need to bring in the people that are gonna be impacted by that change and say, Hey, I want you to have some skin and regain for this. Help me help you.
Now you might still meet resistance and that’s really commonplace, but it’s about at least giving them a chance to speak up and be truly included in the process. ’cause no one likes to be told what to do, right? They want to be like, oh, I had a seen. And that’s always. Why reference making sure people have skin in the game.
Because if they have skin in the game, they’re more likely to adopt, react, give these feedback. And so I’m always start small, then go big. I never, uh, recommend people go through a whole, like if people are like, we’re gonna revamp our whole design process, I’m usually like, oh boy, here we go. And the reason why I have that reaction is because if you try to revamp something soup to nuts and then say, everyone go forth and do it, it’s very likely to fail because it’s probably too big of a change.
Too big of a commitment and people probably don’t feel like they were involved in the process, so why would they even feel inclined to leverage that process? So that’s always tricky and that’s where I think with operations not understanding that change management is the hardest part. Adoption and understanding how humans work and really pivoting yourself around that is mission critical.
To me, the best operations practitioners are the ones that can be really fluid and flexible with the team that they support. And the reason why I play on heartbeat on empathy is we’ve all been there, right? We’ve probably been all told, here’s a new process or a new guideline, go follow it. And they’re probably looking at that guideline and a document being like, this makes no sense to me.
Why are we doing this? And what I like to do is harken back to like whenever I talk to OPT practitioners, I’m like, we’re over that moment. Because that’s probably what your user, your internal users are facing would, what would you have wished was done differently? So you would’ve felt like, okay, this actually resonates with me.
So that it’s trying to figure out the small tactics to see what will stick and like design, like research ops should be iterative and we should never try to do like a full like. We should never try to revamp everything all at once. I think that’s a mistake a lot of organizations make is you have to start small and you wanna see actual incremental change, expecting a big change, and that everyone will follow suit.
It’s just unlikely because you’re then saying, Hey, here’s this big change that I’m telling you to do. I’m telling you to disrupt your day to day. By the way, you have no say in what it’s, you’re completely taking away the feeling of autonomy. And from those individuals, of course people are just gonna reject it.
And that’s where it gets really tricky. And I’m not surprised by folks having potentially a negative outlook on offs. I’m not surprised that more admin work gets pushed off to ops and this is another tricky situation where, yeah, sometimes some ops practitioners will do the admin work. Pros and cons to that.
Pros, you feel like you’re helpful. Cons, you end up taking a lot of the BS work and that shouldn’t be what ops do. If you are just taking the BS work, I don’t feel like you’re take, you’re able to really fulfill the true power that OPS has in regards to being able to truly enable things. That’s just work to be done.
Okay, cool. Get an intern to do it, get AI to do it. There’s no reason why that can’t be done. That’s where, to me, the change management piece and understanding who you’re working with and where they’re at is just, it’s the only way OPS can be successful.
[00:21:01] Tina Ličková: It, it comes to me that the research and operations are similar in a way that it’s hard to persuade people to do it because those are slow disciplines and operations. And I have just a healthy year of doing it and I wasn’t really particularly great on it. And I will explain how or why, how do you persuade people that it makes sense to do operations? And maybe the second question would be if you.
Have, and you can decide which question we take. If you have an example of a small change in a bigger scope that make that lead to another small change and became this whole project, because that would be also nice to know. What do you mean by the small changes and in comparison with the big ones.
[00:21:57] Su Milazzo: I think we can answer both, but I’ll start with the first question because I feel like that will segue into the example of small changes in action with the first question.
Oh man, you asked a really tricky question. So I actually had a former colleague, I was telling them that like, Hey, I’m taking on an ops role, and I was explaining to him, and this is a very dear colleague, mine, I’ve known him for a year, then we have really good rapport, and I was telling him like, oh yeah, this is UX, operations, design operations, yada, yada, yada.
He asked me a very poignant question and he didn’t mean it in a negative manner. I think it was just ’cause he was genuinely, um, curious about it. And he was like, Hey Sue, why doesn’t the design manager just do that? Why do you have another role called design operations? Why isn’t that the responsibility of the UX manager?
I’m like, oh my gosh. Fair point. And this is where when you try to come up with like, why is operations needed? That design manager, so I’ll go back to using an example. If you have a design manager doing management slash by managing the team or looking at the deliverables and doing operations, you’re only getting potentially 50% of their brain, maybe less for managing the team, managing a team, dealing with individual contributors and like potentially professional development.
That is a full-time job. All the other admin work, was it just setting up Figma licenses? Creating a design process, making sure that designers are tracking all their work. That’s a different type of brain to turn on. Um, and it’s sometimes difficult to context switch. I think everyone can speak to this. A context switching, especially all the time is incredibly exhausting, mentally speaking and sometimes even physically. I. From my own experience as well, but I used to be, um, a people manager. It would be exhausting going from one-on-ones professional development and then going to client meeting because you’re always switching the, the POV that you’re in.
I would then, when I was working at an agency, you’re thinking about hours, how to forecast my hours, working on statement of work to help pitch to clients. That is when you are split in so many directions, you’re not really able to focus on your craft. And if you’re a design manager, you’re a Desi, a design leader, your craft should be the leadership and management.
Not to say that you won’t do admin work, but that’s where I think design ops really can help play a role or even research operations. How do you allow those leaders, those individual contributors, to focus a little bit more on their craft so that they don’t have to worry about the other things that might take them away from that deep thinking work?
And also, when it comes to design and research, they’re like. There are times you need just two hours to shut yourself in a room, maybe even longer, to really get into the weeds of what you wanna do. If you’re constantly distracted by other things, you’re not able to focus. So I think that’s where operations is.
Try to remove those distractions to a certain extent. Not all of them, maybe like muffle them so that you can truly focus. And you’re right, it, it’s hard because it is seen as a slow moving. Entity. Right? When you think of operations, you inherently think project management, and I’m like, project management is a part of the core competencies that operations needs to know about, but it’s much more than that, right?
I think it’s the change management and the flexibility of understanding how your teams work to truly optimize for them, and having a really deep level of empathy to truly be able to jump off of it. Is what is absolutely needed to not only justify operations but make it successful. And I think for also in regards to that, how a research, a lot of companies will have like 20 designers, one researcher, same thing for ops 20 designers, one operations manager, one operations specialist.
And I think that’s normal. When you have a small team of designers, a design manager, a design leader probably can handle the majority of the design operations or recent operation stuff as part of their day-to-day job. Each issue comes into play when you start scaling. What are that? Team of 20 designers becomes 50 designers.
A team of 50 designers becomes a hundred designers. You probably need more research. You probably need more operations because the more and more people you get into the mix, the harder it is to keep tabs on things. The harder it is to make sure that people are using the same processes, that they are talking to each other, that they’re all aligned, like to call ops, like the sticky glue between all the teams.
And another thing I think is really caught boards for operations. One thing I’ve noticed a lot in my career is our design teams and our research teams would be under the same leader, but completely separated in their work. The research team would be like, oh, design will come to us when we’re ready, and I’m like, no.
I think design and research and product and engineering should be in the room together so that research can forecast out two months from now that this design work is coming up. That’s where I think operations comes into play because we shouldn’t be just thinking about just design team. We might have a primary focus team that we are looking at, but we should be thinking about, okay, if my designer does this or needs this, they need to connect with Product Eng and research to sprints from now.
How do I help prepare them? For those other touchpoint, and then this goes back to holistic operations to me. Yes, you might specialize in design ops, but you’re thinking about all the other ops down the line so that your team can be successful. Right? To me, a design design team can be successful when they’re hitting all those cross functional touchpoints with as little friction as possible, and those teams are also set up for success.
[00:27:10] Tina Ličková: I vouch for the idea of research operations being the connectors of dots through disciplines for people to do best of their jobs. Yes. And here comes maybe one of the last questions because what I’m really interested in also is to know your opinion on why maybe you would advise people or managers to have specialized.
Design ops people and specialized research ops people and devs people, why can’t just an operation person, if you even say yourself that it’s a holistic field, do everything except that it’s insane. Yeah, we know that.
[00:27:54] Su Milazzo: Yeah. I, it gets to the point like where. Speaking about what my friend had mentioned to me, like, why can’t a design manager do that?
When you spread people too thin, they’re not able to be effective. They’re not able to be truly visible. Now, it’s hard to justify, hey, if you have a team of two designers, two researchers, three product people, hire an odds person for each. You may not need that from the get go. You might need one product operations person to help support until the team scales.
However, if you do that, you lose the depths that each operations practitioner provides. Once you get to a point where you maybe have 20 designers, 20 researchers. 20 product people. Having a dedicated research operation practitioner for each can be helpful because they will have not only the horizontal view, but they’ll also have the vertical view because all the operation practitioners across those teams should be able to go deep with their teams, but they also connect with one another to understand how each team is being impacted.
In other words, again, it goes back to this. Stinking umbrella analogy of like, how do you go wide and how do you go really deep into the context for an initial, um, POV, you just gonna go, you just need to go a little bit wide. If, if you have the umbrella and it’s like a one two and you need a bigger umbrella, that means probably more designers, more researchers, all that fun stuff.
But if it’s small trickle, you might just need a small in video umbrella to help support initially. So I think it really just depends on the needs of the organization and just how big the organization is. Uh, people often assume it can be just. Done by one person. It can be if you want them to burn out.
And that’s the same thing of like how do you make sure that the operation person can focus on their craft? Initially it might be just standing up in ops practice from there. It might be defining what ops needs as it iterates over time. And it could be getting into, okay, what does design operations mean?
What does research operation mean? Hey, actually we need research operations because we have 20 researchers and we have no ops for them, and the poor design ops person is sitting in the corner crying. It’s anticipating those conversations.
[00:29:53] Tina Ličková: And going back to a discussion or an episode we have with Kate Towsey, who is a great specialist or expert on research ops.
She told me a very interesting thing that there is a different if somebody can be a research ops or it’s very structured researcher. Yeah. What would you say would make a designer a good design operation person?
[00:30:20] Su Milazzo: This is an interesting one ’cause I think anyone can do operations if they feel like it’s not anyone, but you can.
What I mean by that is you can come from different places to get into design operations. You could technically be a researcher or even a research ops practitioner, go to design ops. You could be a project manager going to design ops. You could be a desire. To design ops, how you get to design ops could be come from a myriad of ways that the core competencies are the same.
I think it’s, if you wanna get into operations specifically, design operations, first and foremost, think about the core competencies of are you somebody that finds those patterns? Are you finding, are you that person that notices this is a friction point that happened over and over again that I feel like I can mitigate.
That’s gonna work for me personally. When I was a designer, I was always coming up with design ops things to do because it annoyed me in my day to day as a designer. And then once I created a solution for that, for example, the handoff that was then emanated through the rest of the design team, they started picking up that, oh, this is easier for Zoom now.
Okay, cool. I’m gonna start doing, and that’s actually, um, a great example of small peak exchange. So what I did for handoff. At the time while creating an interaction gift, that’s pretty small, right? It’s not a major change in the process. The pretty, in that time, um, point in time, I’m gonna make it easier to communicate with my dev by adding an interaction gift to my user.
Stories pretty straightforward, but that’s quickly snowballed into the rest of the design team doing it, and then that became standard practice for all of us to do it. So that’s an example of the Trojan mice that I mentioned before. But it’s it. You find yourself being that kind of person that’s noticing those things and wants to fix ’em, but also has a deep level of empathy.
Knowing that no one necessarily has to adopt your fixes, operations may be for you. And that to me is where I. It’s going back to walking a mile in your shoes, walking a mile in their shoes. It’s taking the same empathy that you’ve learned from your design practice, having recognition and pattern solving.
That to me is what makes a great ops practitioner slash design ops practitioner if they wanna go that route.
[00:32:26] Tina Ličková: And it seems to me, I don’t wanna put words into your mouth or paraphrase wrongly, but. It seems like you need to have the ability or the skill of persistence being persistent and constant in making those small changes to actually influence a big one, isn’t it?
[00:32:47] Su Milazzo: Absolutely. I think you, well it’s the same thing for design and research, right? You have to have some sort of persistence ’cause like how many times have we gotten these day prioritized? ’cause it was important to the business, but we felt strongly about it. I feel like any designer, any research you can speak to, yeah.
They decided to to scope it ’cause it wasn’t worth it. So yeah, that persistence and then also understanding that persistence may not always pay off. So you have to get really creative of how to be different, a different kind of persistence or a different kind of agile to see what might stick. It’s the whole idea of if this didn’t work, if this change didn’t work, how can I change it slightly differently?
How can I apply it differently? And that’s where yes to persistence, but yes, and to persistence and agility and flexibility.
[00:33:32] Tina Ličková: Thank you. It was a great insight on, and I really love your passion for operations and how you explain it and how you are certainly very positively, I would say, managerial in it.
It seems like you know what you’re doing and you’re doing it right, so thank you for bringing your wisdom.
[00:33:53] Su Milazzo: I appreciate that. I, I think it’s a lot of trial and error and I think that’s another thing is be open to, things aren’t gonna go your way ’cause you’re working primarily with humans and humans are tricky and I’m like, you know what?
It is what it is. Let’s at least try it. And I think have, not being afraid to fail. ’cause a lot of implementing processes is painful and it’s super painful. So being okay with bingle fail and that’s not a reflection on you. It’s just, okay if things fail, how do I get a little bit sneakier about it?
[00:34:21] Tina Ličková: Great.
It’s like preach moment, try and say.
[00:34:27] Su Milazzo: Of course. Thanks so much for having me, Tina.
[00:34:34] Tina Ličková:
Thank you for listening to UXR Geeks. If you enjoyed this episode, please follow our podcast and share it with your friends or colleagues. Your support is really what keeps us going.
If you have any tips on fantastic speakers from across the globe, feedback, or any questions, we’d love to hear from you too. Reach out to geekspodcast@uxtweak.com.
Special thanks goes to our podcast producer, Jana Filušová, our social media specialist Daria Krasovskaya and our audio specialist Melisa Danišová. And to all of you. Thank you for tuning in.
💡 This podcast was brought to you by UXtweak, an all-in-one UX research tool.
