Su Milazzo on Driving Impact with Design Ops

Alex Smith: Design Leader Insights is brought to you by Fuego UX. Fuego UX is a leading UX research strategy and design consultancy. Hey, Su, thanks so much for joining the show today. 

Su Milazzo: Hi, Alex. Nice to see you again. 

Alex Smith: Yeah, for sure. And to get started, can you give us a little bit of insight into your journey in design? 

Su Milazzo: Sure thing. So I started off many moons ago, I'll say many moons. First trying to get into UX design just by happenstance. I actually saw a post on League of Legends for a UX researcher, and I didn't realize back then that they were looking for a UX researcher with a psych degree, and I saw that, I was like, oh my goodness, I could do this. So that was like my first entry point into design, and clearly I played too much League of Legends, but that's a story for another day. I started off there, and then I got into user interaction design, back then it was called user interaction designer. So that's kind of how it started, and went from one company to others, started in consultancies, worked on activity software, so think about like if you sign up for endurance races, that kind of stuff. Moved to B2B e-commerce and then had a few more journeys and agencies and whatnot. So it's been an evolving process. I think I got into design when it was really becoming more mainstream and popular enough to say it wasn't before. I feel like my career grew with design. Now you can expect to see design everywhere. Like a team of designers, back when I first started less so. And then eventually over time, I moved from designer to managing design teams to eventually actually moving into design ops. It was an interesting transition. That's kind of my high level journey today. 

Alex Smith: That's an awesome, awesome journey. What made you switch from designer to design ops? Because I think, for better or for worse, I think the design part gets lost in Design Ops a lot of the time, and it's a lot more ops than design. But yeah, what made you kind of make that switch? 

Su Milazzo: You know, you asked an interesting question because I often think about like, why did I switch? Why did my brain automatically, not automatically, just happenstance kind of migrate into operation? So I'll talk about a core memory I have when I worked at B2B e-commerce. Basically way back when I was running into isSus with getting my designs out the door. What I mean by that is I would create a wireframe in Akshar. If you know what Akshar is, you know, you've been in the industry for a while. From now it's Figma, but again, story for another time. From there, I would feed it to my offshore developers who were working in India. Now, there's obviously a time zone difference, a language barrier, all that fun stuff, and we were just trying to put it into Jira. And my brain at the time thought, hey, if I put this in Jira with this link, they'll automatically understand what I'm trying to build, right? They would know exactly where to click in the interaction. They would know basically what's in my brain. What I realized quickly over time was that we were running into isSus with developers and QA, not being able to understand what I was trying to do from that user story, from my design. And they asked a lot of questions, and initially I got frustrated by that, like, why don't they just get it? And again, this is many years ago. Now I realize it's because they weren't in the room. They had no idea what I was thinking, so I saw this and I was like, let's iterate on this process. So I remember on my actual wireframe, I used to put a little red box that said, click here to start interactions. I tried doing that, and then quickly over time, I realized, wait, like one of my devs or one of my QAs was asking me, do you want us to code that box? And it kind of like lit up a light switch in me of like, okay, so what I assumed would be beneficial to them is not, they're taking it quite literally, rightfully so. So we evolved this process of handoff, instead of just throwing a wireframe, we 86'ed the red box because clearly that was causing some confusion. And then I started to create interactive videos of my interactions, but the videos were too long and no one would watch them. And so, I iterated on that process again, and instead of videos, I created interaction GIFs of each interaction, because each user story is pretty specific to a specific interaction or a page. So I would create interaction GIFs that would kind of show up in the user story, the ticket, and it resolves so many isSus for me. Like, that to me is like, the beginning of my design ops brain is noticing a pattern of confusion, misalignment, and wanting to fix it. And to me, that process of the red box, which to this day I laugh about, because I'm like, well, of course, that was a bad idea, yo the video, to the interaction gif, it's kind of like iterating on design ops over time. So that's kind of where I think I've always had a desire to make things much more efficient. And that core memory became a constant reminder throughout my career of like, how do I help? People work better together. How do I work better with people to get my designs out faster? 

Alex Smith: That’s funny, the red box. Yeah, but let's go into like, how have you seen now that you've been in design ops, how can design ops teams make a difference? Like impact would be like either design or product teams that they're, they're interacting with. How do you effectively insert design operations into a company where it's driving impact?

Su Milazzo: You ask a tricky question because I feel like this is what design ops is trying to figure out and make more mainstream and scalable as well. Design ops, in my personal opinion, it's still in the early stages of becoming a more mature part of the industry. But I think design ops is still, it's kind of what UX design used to be way back when. When you used to hear mentions of designers and UX design and what it meant. And now I think what is happening is as UX design evolves and mature and now UX design is kind of common practice across most industries, you're going to see design ops slowly but surely pop up as well. When you have an org that has one designer only saying we need design ops, it's kind of tricky because you kind of need scale to help justify it. And I think when it comes to how do you make design ops more effective, it's understanding what problems you're really trying to solve and it, this feels very PM-y, so bear with me. The problem you're trying to solve with using design ops, in my opinion, is making sure that you're kind of removing barriers. Making sure repeatable patterns are truly patterns that can be scaled for designers, and designers do the best work when they're able to get headspace to think about creativity to think about the user of the interactions. How do you kind of clear the noise for designers so that they can truly be creative so they can start think go straight into designing. Obviously prototyping user flows first and foremost, but they don't have to worry about all of the noise, and I don't want to call it noise because it kind of minimizes design ops, but all those redundancies, all the things that a designer might have to go through, how do you help handle and manage that so the designer can hop right into design? How do you get, instead of them hunting down several Figma files, how do you consolidate it into one? And sometimes people will think, oh, if I had design ops, designers will go faster. I don't think that's true. I think Design Ops enables your designers to be able to explore all the things they want to design for, design with, so that they can produce better results. That to me is what Design Ops should be focusing on, not making sure that they have more prototypes or more deliverables. I don't think it's a one to one and I think that's going to be part of Design Ops evolving and coming up with its own identity.

Alex Smith: Yeah, Su, this has been awesome so far. I'm interested in what advice you have for people who might be looking to break into design ops? 

‍Su Milazzo: Yeah. It's an interesting question because a lot of people will think that to get into design ops, I need to be a project manager or have a PMP. And I understand the merits for that, but I disagree a little bit, and here's why. To me, if you have an innate ability to understand change management, and if you have, like, so much of my story about the red box, of looking and finding a pattern that you want to find repeatable and scale it, that to me is kind of an indicator of, like, Design Ops might be your calling, maybe even Ops. And the reason why I say that is like, you can have a good project management background, you can come from that. But if you don't know how to work with people, it gets really challenging to be a really strong Ops practitioner. What I've learned working in Design Ops is like, it's not the tools that are challenging. It's understanding how to work with individuals, with teams, knowing that if you just say, hey, use this process. You're probably going to run into pushback if people are not going to feel like they're a part of the process or they don't have skin in the game. So you'll often hear me say like, how do you make sure that people feel like they were heard? They are a part of the process so that they're more willing to accept something. It's kind of like when growing up when your parents told you to do something, you wouldn't listen. I want to do the opposite of that, right? I want people to feel involved in the process, feel involved with knowing that they're being taken care of and heard at the same time so that when changes do happen and changes will happen, right? We're constantly changing with AI coming in and everything, new tech emerging. How do you help make that seamless and that is another skill set of operations? I think it is really mission critical to understand that change is hard. How do I make it a little bit easier a little bit more? Digestible over time, so it doesn't come as a shock. And that, to me, also helps expedite whatever processes that you're trying to do as well. So that, to me, is the most well, two things for advice. Understanding how people work and change management, and also seeing those repeatable patterns, having a deep level of empathy for that. So, to me, Design Ops isn't very different from design, like a high level POV, because you have to be empathetic to your users. You know, walk a mile in their shoes. You want to be able to quote unquote design for them, but instead of designing prototypes, you're helping support processes, day to day interactions. It's a similar thinking in regards to how do you get to that end result, there's a different way of applying it. I'm really excited to see how everything evolves. 

Alex Smith: Yeah, the same here. Yeah, hoping it, hoping it turns around and picks up a little bit. And I think you're right. Like, it'll grow with the field, just as product and engineering ops out with those respective fields.

Su Milazzo: I'm excited for it too. The fact that UX design has matured enough to have design operations. It's really exciting, right? We've already had product ops. We already have DevOps. So to see it at the beginning, it's kind of like, I'm really anxious, but excited at the same time to see what, how it evolves and how it's going to bring in new tooling and all that fun stuff. It is gonna be a journey. 

‍Alex Smith: I love that. Su, thank you so much for sharing these insights today. 

‍Su Milazzo: Happy to share and happy to see what happens with design ops over time.