Abbey Smalley on Mastering Cross-Functional Collaboration in Design

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

Abbey Smalley: It's my pleasure thanks for having me so much, and Alex, it's been funny, I know we were just chatting, we've been chatting for a while, and it's finally a chance for us to catch up and share a little bit, so grateful to be here. 

Alex Smith: Absolutely, yeah, thanks so much, and to get started, but can you give the audience a bit of context on kind of your recent journey in design?

Abbey Smalley: Yeah, absolutely. Well, hey folks, my name is Abbey Smalley. So I'm a Product Design Leader. It's hard to look back, but I've been in this field for about 20 years. And what first attracted me to the field and what has kind of guided my journey from then is I love the concept of art and design meets psychology. And I have found myself in spaces that are more complex ecosystems. I love thinking about systems and frankly just simplifying things. And so I found myself in healthcare and retail working on enterprise type systems. I really love leading teams and helping them be more effective together and delivering for customers. So that's a little bit about myself. In my previous role, I was formerly at Amazon as a Design Leader on a data analytics platform. 

Alex Smith: Nice. Okay. Awesome. Well, thanks for that context. I think one of the things that we were chatting about that I think super important is designers today are really wearing a ton of hats and also working with a ton of teams, be it marketing, research, product development. I think one of the things that I'd love to dive into with you is how teams can effectively work better together cross functionally. 

Abbey Smalley: So yeah, I do have a couple tips on how to be effective, and some of this is, is basically around some of the themes I've seen on the most effective collaborative cross functional teams. So the first one that I bring up that I see a lot is just honestly having a basic core understanding and respect, candidly, of everybody's purpose and roles. An example that I would give you is like, yes, of course, we're working together, we're trying to be kind, but sometimes for example, I've come into spaces where a product owner may have only worked with someone, say, that has a graphic design background previously. So they don't understand that product design in UX is really something that's very data driven, outcome driven as well, not just like something gets thrown over a fence and like, just make this thing. This shouldn't take much thought, right? Because I'm telling you exactly what we need. So on the other hand, it's also our role and all of our cross functional partner roles to help educate each other. Like, actually, here's why that might be difficult, or here's why that won't actually deliver the outcome we're looking for together. So folks need to be open to learning more about what roles we have to play individually and together, and respectful enough to understand that they might need to learn more so we can be truly effective team members together. And, you know, I think one other thing that's really important here is there are many moments in product building and you had alluded to this in the very beginning, where we have to work very closely together and you can't deliver collaboratively. And so the best teams I've seen be effective. We all have certain roles and things that we do, like think of a Venn diagram in our circles, but really there's always this gray space that gets made in between. On, when we collaboratively work together, it isn't just mine or yours, and the most effective teams I've seen, they lean into that gray space versus being scared or even offended, if you will, that we're stepping on toes. So for example, I've been in a situation where a product owner actually had a background in research. I absolutely want to make sure we're making that person space to be involved in user criteria for testing or, or talking to users. That isn't just something that should be owned by the design team. And on the other side, product owners to leave space for designers to contribute to product vision, not own it. There's still lanes that we need to be in to own to really say, like, who needs to make some final calls, but contribute to that vision based on some of the data or understanding of the users they have. So really making space to say, we need to lean into that gray space and not be offended by it is pretty critical for success. You know, another one I think that's really interesting is and I've learned this one. I think. The hard way while being a people leader, too, and working with cross functional teams of partners and understanding it took me a while to understand this, but the tip I have is making sure that cross functional teams not only have aligned and prioritized goals that are mainly outcome based, and we've used that word a lot, Maybe it's a trigger word for folks. That means not just getting something out the door, right, but actually achieving a certain goal. But that's actually also how they're measured at the end of the year. It's human nature to perform towards what we're measured on at the end of the day. So not only have shared aligned goals, but actually being measured on them for your performance at the end is super critical.

Alex Smith: I'd love to hear your advice because I feel like those goals can arbitrarily come down from like C suite or like CPO or CTO, you know, like, yeah, how do you inform that if that's one that teams need to evolve on? 

Abbey Smalley: Yes, all of our teams, and I can just say this with a blanket, can get better at measuring what matters and asking questions if they don't know. If they don't know how they should be performing and what they're effectively being measured on, they should ask. And if there's a gap there, they should recommend something and they should ask. And I hope we have a healthy moment where they can ask those questions with good curiosity with their leader. If they don't have that, start asking some of those prompts. And when you are creating your work or working on outcomes or workflows yourself, like, go ahead and say, like, my purpose of this was to do X. Like, I understand we're trying to hit this measurement. That's why I made this decision. 

‍Alex Smith: That's super practical, and I love that just because it's communication.

Abbey Smalley: Another one that I think is really important is having just enough process. I find that a lot of teams think that process is a very dirty bad word. I'm here to tell you that I am a process fanatic, but that doesn't mean a lot of process. It's just enough process. And here's some reasons why I think the process is important in a lightweight way. One is it ensures quality. This could be around something that is a workflow that actually achieves a goal. And some of the acceptance criteria could also be about making sure implementing a design system consistently so that you're really supporting not only efficiency, but consistency for your users. This is also about making sure you're bringing the right fidelity of your designs at the right time. For example, I've been on teams that cross functional partners like Product and UR and Development won't look at something until it's, like, high fidelity polish, with visuals and color. But then they're making comments about Is that the right blue versus like, oh, I can see how a user's moving through this workflow. I can see this is solving their problem. And so a lot of designers will then take all this extra time up front to make something look polished when it shouldn't be polished yet. This is a concept. People should be able and feel comfortable giving input because this doesn't feel like it's just about to go out the door. Making sure that you're getting the right visibility and approvals at the right time. For example, I've seen teams where development might not see something to the very end, but then at the very end, when you're like, okay, time to build it, there's feasibility issues. And if they had just seen something, maybe even in sketch type form, they could say like, how are we going to do this?  Like, we don't have that capability or like, that doesn't fit this timeline. They can give suggestions so that we don't have to go all the way around the wheel and say, oh, go back. That didn't work. So enough process to make sure there's enough, the right visibility at the right time at the right fidelity makes things go a lot smoother. So there's less iteration that needs to be done. There needs to be shared alignment with the cross functional team and where the team needs to be fast and iterative and willing to launch and learn versus where they should really be more risk averse. Align on where you should go fast and align where you need to have a little bit more time to get some quant and qual and more solid input. I see a lot of teams get frustrated by not aligning on these things on both sides. You know, I've worked with some designers that want to test everything to the nth degree, but we are slow as hell.You know, or they don't want to test anything. And the reality is, if you can align it, like, you're right, these things, like, we should move iteratively fast through phases, and it's okay to be wrong. And these are things that we know need to take a little more time. You're going to have a lot less frustrations on the timeline, or where something is, or why do you need so much time to do X?

Alex Smith: I think that's genius. Once again, it comes down to communicating across the teams, which is the core issue of a lot of these. Yeah, it's like, hey, here's when we're going to go fast. Here's when we should both slow down because this is, this is what the users, you know, if we change this, it's going to be detrimental or something like that. And I don't know if these conversations are always had, you know, right. The way to design maturity framework, which…

‍Abbey Smalley: Yeah.  

Alex Smith: Which doesn't necessarily talk to the fact that there's an organizational maturity framework and it goes beyond design, right? Like it, it does touch on that, but yeah, having these conversations are essential to, to grow and design maturity. Let’s switch gear here to advice you have for new designers that are entering the field today?

Abbey Smalley: I know that I can't inform a lot of people's new paths because my pathway was one a time where people didn't really know what UX was. And so the path in today is very different, but what I think will be very effective and helpful for designers today that they're either entering this field or looking to up level their career, is not just think about yourself as a designer. You are a business owner and a right.. You are thinking about the whole business problem. You are thinking about how you're achieving goals for users to make them satisfied, but also create outcomes for the business. So you can be alive again tomorrow to create more great things for your users because the business is also thriving. So if you can put on the hat, I'm not just a designer. And I work with these people that are different than me. You're all business owners together. You own a different slice of that pie with your skill set, your design and psychology and research and all these things skill set. But that's complementing it. And the more you can think of your career and your role as a holistic business acumen, the more successful you'll be because you'll know when to apply the right design aspect.

‍Alex Smith: So true. Especially during these times. Like I think that is, that is eternally relevant advice, especially in a time like now in a market like now. So thanks so much Abbey, for, for joining the show today and sharing all these insights. 

‍Abbey Smalley: It's been my pleasure. Thank you.