Never done: Evolving UX teams who earn influence

Ben Hewett at UXDX USA. Video: https://youtu.be/x2dg7-arCR0

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Day one: limited scope and limited influence

[00:00:08] In 2018, when Allied Solutions first started building its UX practice, we thought our biggest challenge was going to be redesigning a mountain of legacy software for the finance and insurance industry. We were wrong. We ended up having a bigger problem. Our biggest problem was: how are we going to earn trust and gain influence throughout the organization, so that we could help solve some of Allied's biggest digital problems?

[00:00:41] I want to take you back in time on a journey to walk through how we did that: how we were able to gain influence and understanding throughout the organization and start to work on solving some of those issues. I want to share with you how we started. We moved from a team that looked like this, with one researcher, a designer and a leader, to a team that looked more like this, over the course of eight years at a pretty steady pace.

[00:01:16] I want to talk about where we started on day one, where the path forward was less clear. We didn't quite know where we were going, but it was always there. We just had to have the confidence and rely on our skill set. When we talk about day one, what it really looked like was limited scope, limited influence, limited understanding of the organization. We're talking about a company that has 20-plus software products, and we're working on one. We're talking about working within one line of business out of 100. We're talking about not really understanding what all those lines of business were, or being able to have those conversations with stakeholders to really understand where they needed to go and where their biggest challenges were.

[00:02:06] That's really what this looked like: you can redesign one piece of software and we'll figure out what your next project is later. You can work on one out of the 20 things that we have here that desperately need your help at the moment. And you have to figure out what your iterative UX process, your creative process, really is, and how that fits in an immature agile organization.

[00:02:32] That's a tough place to be. We operated like this: one researcher, one designer, paired up with project management, with engineering, working on one product in a sea of all these other things, very focused on a project mentality at this point in time. And this was already 2018, when a lot of people had moved on to a product mentality.

[00:02:57] I'll take you back to our humble beginnings here. You'll notice the lack of daylight in this room that we kicked off in. My personal favorite piece of this room was our makeshift inspirational posters. You can't make them out here, but you'll see a nod to Steve Jobs, and of course our favorite: pay attention to what users do, not just what they say.

Earning a reputation, and the line out the door

[00:03:21] That's what it looked like. We took on big challenges, relying on our skills to speak for themselves. Our talents drove the progress that we were making, and we were able to show that we can change legacy software and do better by our users. We made meaningful progress, increasing user satisfaction scores, decreasing time on task, and all of the UX-level metrics that we were trying to chase. And we made the case for UX as a discipline throughout the organization. They started to believe. We started to make some progress. They started to understand, "Okay, there's real value here," just by looking at what we were doing.

[00:04:03] When you deliver results, people start to talk. They start to share: "Oh, have you seen this? Have you seen that? That's coming out of the UX team." We became a stop along the client tours that were happening at Allied, with clients coming in, and we would overhear them peeking in our little door saying, "Oh, this is the UX team. They make things look pretty." Raise your hand if you've heard something like that. Yeah, okay. All over the place.

[00:04:35] That's what it was like for the first several years. That's who we were; that was our reputation. We knew that we were chasing something bigger, that we were going after real results for the business. That's when we started to realize that sometimes you are the product. When someone is talking about you as if you're providing value, you are the product.

[00:04:59] Pretty soon we found ourselves in a different situation. With a line out the door, we were still working with that project mentality, and there was too much demand and not enough supply. We weren't able to get to projects fast enough, so they'd just move on without us. Then you end up with a mountain of UX debt piling up behind you, and you continue to have that issue. I see some smiles and some head nods. This is sounding familiar to some people, I hope. That's great.

[00:05:26] So this ended up starting to feel more like this. Things are closing in around us. What are we going to do about this? How are we going to handle all of this stuff? There were only three to five or six of us at this point. We started to reflect, and we started to think, "Well, wait a minute. We know how to do this. Let's UX ourselves." If we're thinking about how we deliver software in an iterative way, why are we not doing that with our team? Why are we not reflecting on ourselves and iterating and growing in that way? So we took that approach.

Maximize your team's potential with a growth mindset

[00:06:01] I want to give you three main things to take away today, and this is the first one: maximize your team's potential by using a growth mindset. Always be improving. Be reflecting on how you might get better. What are your gaps? How can you improve? Remember that learning isn't an achievement or a single event. We know that from education at this point. Create a culture of continuous learning and improvement. Make it embedded within your teams. Several people have talked about culture already today.

[00:06:39] I love this quote from Albert Einstein. I do love to arrive at a destination when I travel, but I also really appreciate the journey to get there. And isn't that just what a growth mindset is, where you're constantly improving? "I love to travel. I hate to arrive."

[00:07:01] So we started to set better intention. We started to lay out our core values: what is it that really makes us who we are and what we believe? How do we get there? So we started with core values. These are our core values. They've been the same since we started eight years ago. We have revisited them a few times, and only one word has changed the whole time. These are our deeply held beliefs. They're things that we want everybody to believe when they first join our team.

[00:07:31] First one: we value outcomes over outputs. We'll talk more about that in a little bit. We're collaborators, advocates and advisors, not order takers. Advocates is the word that was added a few years ago. We're advocates. We believe not all problems are worth solving, but those that are should be solved well. That speaks to the quality that we're trying to achieve; we're always keeping the bar high. And then, for all you Eames fans out there, we seek the best for the most for the least.

Vision, identity and culture

[00:08:02] We started with core values, then we created a vision. Our vision is our North Star. It's where we're going. It's what we're trying to achieve. It's the place we go next. It's easy to understand. It unifies the whole team. And it's actionable; it's not pie in the sky. This rallies the team to get you moving where you need to go. This is something that changes. You iterate on this over time.

[00:08:29] This is our vision. I don't need you to read all this, and I'm not going to read it to you. You'll see some of our core values are embedded within the vision. What I am most proud of about this vision is not that it reflects where we're going, but rather that every word in it was scrutinized by all the members of our team. Every single word is intentional. That creates buy-in. That's where the culture comes from. Everybody is pursuing this.

[00:08:58] When you have a good vision, it can help you make decisions, and it can help you manage your stakeholders. Where are we playing? Where are we not playing? What are we going to be doing? What are we not going to be doing? How do you fit with the rest of the teams throughout the organization? What are the things that you're not going to do because they're someone else's responsibility? Or what do you need to pick up that someone else has dropped?

[00:09:24] We created an identity. You'll see some of that throughout the presentation here. This is us: we're the UX Lab department of Allied Solutions. Part of our identity is defining the disciplines that we work in. We define our disciplines as UX research, UX design and UX engineering. At this point in time, that's where we're at. That's very specific. We're not doing some of these other things. We weren't a product organization at this point. So it's helpful to know what you are and where your boundaries are.

[00:10:01] We created a culture, and going back to growth mindset: how do you create a culture that's based on a growth mindset? Well, you talk about learning openly. You set goals; you don't set requirements. You document the progress that you have made. We have skill maps for each discipline that allow you to see: where was I last year? Where am I going? Where do I need to go? What do I need to improve on?

[00:10:30] And you encourage sharing across roles. Just because we have those three disciplines I just mentioned doesn't mean that a researcher can't go and do some low-fidelity wireframes. It doesn't mean that a UX engineer can't participate in user interviews. So you can blur some of those boundaries, especially if you want to encourage everybody to work as a team. You create space for vulnerability. None of us have everything all figured out. So it's worthwhile to create transparency: this person is working on this skill set. "Hey, you're doing the thing that they need to learn how to do. Might you go and talk to them, and teach them how to do it?"

[00:11:10] And we set the tone on day one. We actually do it before day one. We just had a new person accept an offer a couple of weeks ago, and we've already sent them onboarding materials. "Hey, here's what it's like to work with us. This is what you can expect from us out of the gate. This is what we expect of you. This is how we expect you to continuously learn your craft over time." So that they know how to get to our office from the parking garage when they first get in the door.

[00:11:44] With an identity and a vision, we continued to gain organizational support. We were able to start acting like we knew what we were doing. People started to pay attention. They started to see, "Oh, okay, they're organized. They've got their stuff together. They're going to be able to help us out on this other project." We were able to leave that feeling of everything crowding around us and slowly but methodically transform into embedded product teams, where we had a researcher and a designer paired with engineering and a product manager, all the while having a disciplined approach with consistency across all of them. This is about the time we started building our design system.

[00:12:25] Our space got a few upgrades. It looked a little bit different. When you start to be organized, you gain some more support. This is just a visual reminder of that every day, where we walk in and say, "Oh, remember what we used to look like? Remember what this used to be?" It's kind of fun. We look back on those days and it's kind of funny.

Demonstrate your value to the business

[00:12:41] So I would say you earn the right to evolve. When you put the effort in and you start to grow, you earn that right and you build that trust. You build that influence. This is the second thing I would like you to take away: how do you demonstrate your value to the business? Do you speak like the business? Do you really understand what the business is looking for, whoever the business is in your case?

[00:13:09] How does your team increase revenue? How does your team reduce costs? The equation is not overly complicated, but the more you show intention, even if the things you come up with are hypothetical, it demonstrates that you have that mindset, that you're thinking about them. I'll bring back one of our core values, which is that we value outcomes over outputs.

[00:13:39] When you talk about things in terms of deliverables, the number of screens that you designed, the number of sprint goals that you achieved, the velocity that you're achieving, the features that you released in a certain period of time, those get lost if the meaning's not there, if the value isn't there. "Yeah, you had a hundred releases last week. That doesn't mean anything to me," especially if we're not increasing revenue or decreasing costs.

[00:14:11] So if you can translate your deliverables into demonstrations of value, you start talking about things like reduction in onboarding and training time, increase in sales volume, increase in close rate. We've got a huge call center, so that might be things like decreasing the amount of time that someone is on the phone, or decreasing the number of phone calls that come in the door in the first place. When you start to speak in those terms, people, again, start to pay attention. "Oh, they understand."

[00:14:40] We created case studies to help with this. The original version on the left here is the old version of myinsuranceinfo.com. We redesigned it, and a lot of us in the room can very clearly tell, "Okay, this one's going to perform better." But someone in our business might think, "Oh, well, this one looks fine. Why redesign it?" What we would say to them is that it's not really about what it looks like. It's more about how it performs and what it does for the business.

[00:15:09] So we set out on a project where that site had one job to do: to get somebody to submit proof of insurance. Everybody's got an insurance card in here. When you get a loan for a car or something like that, you have to provide proof of insurance. That website helps us do that, but only 54% of the people were submitting it, and that was one singular use case. When you're talking about 2 million visitors every year to that website, that's a whole lot of phone calls it could create, because people don't trust the website to actually go through and submit that document.

[00:15:44] Our goal on this was something around increasing that by 6%, and we knocked it up by 24%. So we started with these success metrics in mind. Goal number two was to reduce call center volume by 5,000 a month. The business started to say, "Oh, well, you can work on this project, because it'll pay off if you can reduce phone calls by 5,000 a month at $5.43 a call," or something like that. And we projected that we were able to do it by 17,000.

[00:16:19] Then what about speed to market? How fast can we do it? Because the last time they wanted to redesign a website, it was going to take 18 months. That was 2018. That should not have taken that long; I think we can all agree with that. We did it in four and a half months. That might still have been too long, but that's where we were, and that's where we were able to demonstrate speed to market.

Build trust by caring what others care about

[00:16:41] So I would challenge you all to start building trust by caring about what other people care about. We care about product. We care about UX. We care about engineering. But what do the other people in your organizations care about? Ask them questions. Get curious. Use the skills that you have to learn more about the other parts of the organization, and build that trust by caring about what they care about.

[00:17:02] We were able to create advocates. Wouldn't it be nice if you could pick up the phone, call the CEO or the C-suite, and say, "This is the next thing that we want to work on"? That's just not the reality, especially when you're starting from no program, no UX, no product team. How do you build that trust? How do you create those advocates? It was a windy road for us. We had to go through our product managers, through operations leaders, all sorts of people, and we had a lot of setbacks along the way. People saying, "Hey, hold up. What are we doing here? What are you doing, trying to influence this? That's what we do over here. Where did you come from? What is it that you're supposed to be doing here? Why did you get tapped to do this?"

[00:17:49] So we took things on road shows. We'd take that case study I just pulled up on what we call road shows, where we'd go and talk to all these different people, and then magically that person would say, "Oh, you know who you need to talk to? This other person over here." Okay, I guess there's another person I've got to talk to. When you start to build those advocates, obviously you're able to get things done a lot faster and have a bigger influence on the organization.

Never done: still evolving

[00:18:14] So, going from what it looked like on day one to what it looks like today: that person I mentioned who was the leader is actually now our VP of product, UX and engineering. We're expanding into different disciplines. Instead of it just being UX research, UX design and UX engineering, now we're venturing into front-end engineering and service design.

[00:18:39] And we're still evolving. We're not done. We're realigning our teams around business value streams, and you might be wondering why we're doing that when we were already embedded in products. Well, it's important to understand that Allied is not selling its software. So the lines of business don't directly correlate with the number of software products we're working on. You might have multiple software products supporting one single value stream. So now we need to talk about how we align towards the business objectives, and you might have people supporting multiple software products.

[00:19:16] We think we'll be successful. We know we'll be successful, because we have a solid foundation that we built on. And if we're not successful, we'll iterate again, and we're fine with that. So I'd say that by prioritizing the conditions for learning and growth, you're going to be able to make it. You're going to be able to figure it out and get there. You might have to iterate more than one time in order to be successful and gain the influence.

[00:19:50] The last thing I'll suggest to you is that when you prioritize the right things, vision before structure, adaptability before velocity, safety before scale, you're going to be okay. You might have to take a little bit more time. You might have to go on more road shows. But you'll figure it out. How does your team want to effect change in the next five years? Get them involved. Does your team even feel safe asking the questions? "Hey, I don't know anything about business value metrics. I don't know how to get there. How do I get there?" Enable them.

[00:20:25] And are you built for agility and influence, or only for speed? We talked a lot about speed today. Are we just going for speed? I don't think so. Growth isn't a project; it's a practice. You're always growing. You are never done. Every team that's represented in this room is in the middle of its evolution, because you're not going to be done. There is no destination. You're just going to keep going. So I'd ask: is your team designed to evolve as fast as your business is changing? It's changing pretty fast these days. Thanks.

Q&A

[00:21:10] Host: Great job. All right, let's get into some questions here. Let's queue them up. How did you start presenting your team as advocates, advisors and subject matter experts rather than order takers? And could you share more about how your process was before versus now?

[00:21:31] Ben: How did we start presenting the team as advocates and advisors? I think a lot of this goes back to getting curious with the people we were working with. There were real-world problems we were trying to solve for our business, and connecting those dots to what our users needed too. Our first venture into software product was one where the problem to be solved was that our clients were leaving because the software was so bad. And remember, we don't sell that software. So our big financial institution clients were leaving because the experience was so terrible. By connecting to the business in that way, we were able to say, "Okay, it's not just that clients are leaving. If you can transform a product and create a better user experience, they'll become advocates for you, for the whole company."

[00:22:44] Can I share more about our process, what it was like before versus now? The process we had was very project-based. We built out a project intake process, all the things that you would have in an EPMO, an enterprise project management organization, and we had to do that with three people. We're talking about wearing many hats: a researcher, a designer and a leader trying to figure out what all those operations looked like. Now, because we've embedded with all the product teams, a lot of that stuff takes care of itself. You have all those other roles already, a product manager, product owner, scrum master, those sorts of things. Those roles are taken on by other people, and you can now focus on your discipline.

[00:23:45] Host: And how do you show a demonstration of value that happened because design was involved, rather than just because something was built in a new way?

[00:23:56] Ben: That's a really good question, and sometimes you can't. Sometimes you can't demonstrate it, because, like in some of that case study, the rest of the business didn't stand still while we redesigned the website and solved some of those problems. So sometimes there's not a straight-line correlation. But there's the sheer fact that you are thinking that way, and you might write a hypothetical. That's how we were able to get to work on the project. We pitched it. Several of us have an agency background, so we're used to pitching the next idea. When we see a problem, we take the initiative and say, "Hey, you know this thing's going to be an issue over here. What if we could reduce phone calls by X%?" I'll take a guess: what are the metrics that you care about? Okay, maybe we can help with that.

[00:24:53] The best you can do is to have analytics on some of the systems, and that's actually another new discipline that we're going to be rolling out soon. If you have analytics, you're going to be better able to measure some of those things and then make the case for the next thing: "We'll measure it. We're measuring right now, and we're going to measure it again."

[00:25:10] Host: It makes me think: if you're working on a product and it's successful and working really well, do you think design needs to look for ways to explicitly prove its value on top of a product that's already successful?

[00:25:25] Ben: Now that we're working with embedded product teams, the product managers help a lot with that. They're able to help define, before we start working on a thing, where it is we're going, and then we have analytics, so we're able to measure it after the fact.

[00:25:41] Host: In establishing UX, did you ever have clients or stakeholders who didn't take UX seriously, and how did you go about getting their buy-in?

[00:25:51] Ben: Yeah, for sure, for a long time. I'll tell you one of the biggest challenges we still have: our organization is very sales-driven, and our clients are big financial institutions. When you have a sales-driven organization with big financial institution clients, a single deal means a lot to those individuals and to the company. So when we talk about getting access to our users, that becomes a barrier. We've been able to build bridges over time by inviting those salespeople into some of those conversations.

[00:26:33] We say, "Okay, here's a demonstration of value. Here's a thing that we worked on last time. What do you think?" "Oh yeah, we worked on that. We were the ones that drove that." All of a sudden that opens the door for a single salesperson to say, "Okay, you know what? You can talk to my clients. Let me introduce you to two or three of them." And then we invite them: "Hey, hang on just a second. You join us too. We don't really want you to say anything while we're on the call, but join us for the conversation so you can see how this works, so that the next time I pick up the phone and call you, you can say, 'Yep, not a problem.'" Then that becomes a quick email: "Hey again, I need another client." "Yeah, no problem."

[00:27:08] Host: This next question's going to be a fun one, based on some of the conversations we've heard about design engineer versus UX designer. What do you mean by UX engineer versus UX designer?

[00:27:21] Ben: We have UX designers, who are maybe visual designers or interaction designers on our team, and UX engineers, who are building our design system. The designers are designing the components that go into our design system, and the UX engineers are building the design system into code that is then used by the front-end engineers. That's how we've separated those two.

[00:27:50] Host: How do you justify the need to grow the team if leaders seem to think AI can do everything?

[00:27:59] Ben: Fortunately, we don't really have that problem right now, but we're getting there, and we know it's going to be a challenge. I think at this point it's a matter of being really diligent and getting out ahead of that. How are we using AI right now to scale the amount of work and the value that we can provide in a way that doesn't involve adding more people all the time? Maybe now that we've got a researcher and a designer paired on a single value stream, it's not one-for-one. Maybe one researcher can now support two. Maybe. We'll have to figure that out.

[00:28:40] Host: You mentioned UX debt. How do you create the space to address it when it may not be the business's priority?

[00:28:49] Ben: We have that challenge, and it's not that much different from tech debt, where you're able to identify these things: "Hey, this would work better if we were able to pay off some of the UX debt." Quantifying it, and then attempting to quantify the impact. We had that issue when we were trying to start our design system: "Wait, why do you need people devoted to the design system? Those people could be working on products at the same time, building everything." We were able to demonstrate it in very simple terms. We have a different case study: here's what it would look like to build a table prior to the design system, and here's what it looks like to build a table now. It's very impactful just showing the lines of code that are involved and things like that. Sometimes I think that's the most useful way of doing it: in order to be more scalable and more efficient, we have to pay attention to the design system.

[00:29:58] Host: Do you have a mechanism for collecting the UX debt?

[00:30:03] Ben: No, probably not as good a one as we need, to be honest with you.

[00:30:10] Host: I like this next one. Did the evolution of your work intake process involve saying no to more requests than saying yes?

[00:30:20] Ben: We didn't like to say no a lot. We liked to say "not yet": "Hey, we can start to work on that at this point in time." I actually have a project manager background, so I was able to help with figuring out when we might be able to work on something. But it's certainly a challenge, with people saying, "Okay, well, if you can't do it now, I'm moving on without you."

[00:30:54] Host: Cool. We're just about out of time. Maybe quickly hit on: how do you deal with prioritization of work with an embedded team structure?

[00:31:03] Ben: We're starting to work a lot closer with our business leaders and what they're trying to achieve. I think that's been a breakthrough for us. It's not just our software product managers; it's other business goals and objectives and strategic priorities that are better defined. We found that when that is better defined, and you have actual success metrics that you're going to be chasing, you're better equipped to prioritize that work. And we're improving the skills of our product managers and product owners to help us prioritize all that stuff.