How to make UX matter in places where it isn’t expected

Vandana (Vinni) Munjal at UXDX Community: Guardrails, Governance, and Trust: Getting Teams to Act on Research. Video: https://youtu.be/2M1Fa5IlRuA

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.

Why organizations make room for things they didn't know they needed

[00:00:09] Vinni: Today I would like to start with a question that I have been thinking about for a while: why do organizations make room for things they didn't know they needed? While thinking about it, I don't think it's because someone pitched it well, and it's also not because someone made a compelling business case for it. What I feel actually makes it needed is that the thing became so embedded in how the work got done that removing it was no longer imaginable. And with that, we are no longer talking about adoption. We are actually talking about how we build infrastructure.

[00:00:58] Hi, I am Vinni, and today I am going to talk about how to make UX matter, and make UX a trusted infrastructure, in places no one expected it to exist. Before we go there, let me give you a brief overview of the space I work in. My company, The Heritage Group, is a multi-billion-dollar holding company with more than 7,000 employees across its portfolio of businesses in construction, chemicals and environmental services. When you look at the environment where I operate, you don't really think directly about where UX would live here, or what the identity of UX in this organization is.

[00:01:43] When I arrived, I came in as a contractor. There was no UX function, there was no design team, there was no roadmap for what they wanted out of me or what they wanted out of UX. What they did have was multiple systems: HR portals, internal tools, operational platforms. These tools were accumulated over time, layer by layer, each solving an immediate problem, but no one really asked, is it even making sense to the people who are actually operating it?

[00:02:17] But that is also the truth about most organizations, because a lot of organizations don't build systems, they don't build tools; they just inherit them. They have a problem, someone suggests a tool, you get that into your system. All those solutions work on a one-solution-fits-all premise, but they were not built with purpose or intention, thinking about the unique challenges that organization had to face. I feel that is also a very interesting space where UX can come in and exist.

A game board for benefits

[00:02:54] Now, you must all be thinking a little bit about it: yes, this is a unique space, yes, this is unexplored territory, but how did I even enter this space? How did UX land in The Heritage Group? It all started with a leader coming out of a meeting with a sketch and making an ask: we need to build a game board for our benefits. The leader wanted people to utilize the benefits to the maximum, because they were already paying a lot of dollars for them. People not utilizing their benefits was not a good thing for the employer, and at the same time, employees were missing out on these amazing benefits. The intention was pure. They really wanted people to get access to all these amazing things that were out there.

[00:03:45] It was a very interesting brief when I was brought in, and I also felt that it would be fun to create something like this, a game board. Just think about all the amazing things that you can do with this brief. I understood the assignment. I understood the brief. I understood what they needed. But what I did not understand was why they needed it.

Employees weren't disengaged, they were lost

[00:04:08] So I decided to begin with a clarity exercise, and I did all the things that we UX people like to do. I talked to my stakeholders. I questioned my SMEs. I convinced them to let me talk to employees. I did all that stuff. What I found was that employees were not disengaged; they were lost. The current benefits portal was nothing but a repository of PDFs. If you were going there to find something, you might have to click on 10 different PDF links, look through all those PDFs and see if you were able to find your answer or not. The entire thing was so complicated that it was really not worth investigating how to find your benefits.

[00:04:56] That brings us to the next part, where I had to pass on that clarity to my team, who were excited about a game board, the engagement platform that we were going to build to make the leader's dream come true. I made the case that the leadership wanted engagement, but employees just wanted easy discovery, and to reach engagement we still needed to work on the structure and usability. This is the space where we cannot directly reach engagement without investing our time in understanding the basic foundation of the system. When I built this case, the team understood. They knew that, yes, this was required.

Honor the ask, change what it does

[00:05:41] We decided to take this further to our stakeholders. Now, this is the interesting part: how do you go and tell a leader that their idea might not lead where they expected it to lead? It's not a fun thing, because, as a lot of you might understand, when you're talking about leaders, you don't get an hour-long alignment check with them. It's a once-in-a-lifetime opportunity. We were given a brief from the leader, and the leader was expecting the answer. They were not expecting to hear that this is not the right direction. So how do you navigate that? You honor the ask, but you change what it does.

[00:06:24] When we initially thought about the needs of employees and what the leadership wanted, we focused on building a structure, on building a solution that was solving employee problems. It was targeted towards helping them understand their benefits, helping them discover what they needed when they needed it. But to honor leadership's ask, we wrapped that in a fun, exciting theme. On the surface you would see that, yes, it is a gamified version, it has engagement, but deep inside it was just pure problem solving. And when we proposed this idea, we were not proposing to actually implement this exciting theme. Our focus was: this is the solution that people need, but they don't need the theme. They don't need the flashy solution.

[00:07:15] We met leadership where they were. We showed them the employees' reality without dismissing their idea, and we established a case that people don't need engagement, they just need clarity. It clicked with the leadership, and they agreed to the approach. This is what clarity at an organizational level looks like. It's not a fancy or elegant problem statement. It's making the invisible visible to the people who hold the power to make decisions, decisions that impact the lives of thousands of people. Only after all of that are you actually able to bring clarity for the user, which looks like something very simple: findable, and it just works.

Consistency with no budget

[00:08:05] When we convinced leadership to focus on the foundational structure, we got the buy-in. But the buy-in was the only thing we got. We were given the assignment to make that solution work with no new budget, using the same CMS that already existed. On top of that, the content on the portal did not have any defined ownership. We were dealing with a space where there was no meaning, there was no structure, and the tools we had were barely functional. So how do you actually make it happen in an environment like that?

[00:08:42] I like to say that consistency is poor people's tool, poor people's superpower. So we stayed consistent. Every improvement had a reason not to happen. We could have waited for the perfect environment. We could have waited for the budget. We could have waited for people to come to alignment. But we didn't wait. We just did what we could.

[00:09:08] We started by dealing with the biggest challenge, which was search. Search was not there; the CMS did not support it. So we integrated Google Programmable Search and made search live in one day. It was not perfect, but it was working. It was giving people the ability to come inside that portal and actually find what they needed.

[00:09:32] Then we utilized the momentum from the success that we achieved with that search, and we worked on more content. We built more pages, one page came after another, and it just happened. When you look at it, you might think that it was pure execution, that we just worked on making a design system or clarifying the design language. Yes, all those things happened. We worked on our navigation. We worked on our information structure. We worked on how people were going to access that information. But at the same time, this was not just making it happen. It also required bringing together all the stakeholders, all the people who were behind this content, which also meant sometimes making other teams talk to each other so they could come to a conclusion that was beneficial for the employees.

[00:10:25] How do you navigate alignment across multiple stakeholders and teams? It's simple: you make it easy to say yes. You don't ask them to do something terribly wild, and you don't go and say, yes, we need all these multiple things. You just start small, you show them why it would matter, and then you make them the owners of the victory.

From trust to reliance

[00:10:51] The portal established itself page by page, little by little. People came to it, they found what they were looking for, and then they came back again and again, and the portal became a predictable system for everyone to use. Now, the interesting thing that happened was that during a certain time, the organization was going through huge changes. It was not one change, it was multiple changes all together: from switching our dental provider, to migrating the payroll system, to completely changing the HRM system. It was a lot for employees. During that time, the portal became a reliable place where people could go and find their answers. That's when the portal showed its undeniable[?] value, which we did not even aim for. It was just there, acting like a support system no one expected, because it was usable, familiar and stable. So you build trust, trust leads to reliance, and now the portal was a reliable platform.

There's no such thing as a one-man army

[00:11:53] Which brings me to my final chapter, about collaboration. When I talk about my work to a lot of people, and they see that I was behind the scenes developing stuff, conducting the research, building out strategies and doing all those things, people used to make comments like, "You're a one-man army." But what I want to reframe here is that there is no such thing as a one-man army in the world of UX. UX design is a team sport. You can never do things alone, and during all that time I had support. There were people bringing in the context that I was missing. There were people pitching in things that were needed that I was not aware of. It all happened because they saw what clarity and consistency could bring to the work that was being done.

[00:12:43] Another thing I have noticed over the years is that sometimes we hesitate to ask for collaboration, or we hesitate to delegate some parts of our work to other people, because we don't want to share the credit. But what I have felt is that credit is not what's important when you are building a system inside a place that has never seen that system before. That's the least thing you should be concerned about.

Clarity, consistency, reliability, infrastructure

[00:13:11] Having said all that, where is the proof? How did it even work, and how can I say that UX became a trusted place for people in this organization? This is the portal story, where we definitely wanted usage to increase and dependency on HR to reduce, and it happened like we wanted it to. But there was another benefit that came out of it: the organization saw that they were not investing so much in print costs, because a lot of that load was taken off by the portal.

[00:13:43] And that is also not the biggest thing that happened. With the benefits portal, UX proved its value. UX showed what happens when you target the right problem and solve it the right way, instead of looking at the surface and trying to do things. After establishing that value, UX expanded by showing itself as a reliable source during the organizational change and a lot of cross-platform alignments. Ultimately it stayed, with the content governance and decision-making frameworks that we developed to keep the good work going, and it established itself as an organizational capability.

[00:14:30] In retrospect, what I see is that clarity is what made UX useful, consistency made it reliable, reliability made it necessary, and necessity is what eventually becomes infrastructure. When I came to The Heritage Group, I was just a contractor. There was no UX role in the company. But now there exists a UX role. They saw the value, and they wanted to keep investing in this thing. And that is how UX became a trusted infrastructure in a place no one expected it to exist.

Q&A

[00:15:11] Host: Excellent, thank you very much, Vinni. That was a nice story and a happy ending, I guess, which is always the best part of a story. It was great to see the generic advice of demonstrating things being put into actual practice, how you've done it. Thank you for sharing. If anybody has any questions, just remember to write them in on whichever platform you're watching this on, and we'll put those questions through to Vinni.

[00:15:37] I'm going to get started with one. I always feel people give the advice, "Oh, I went in and I decided I was going to validate the idea." But I've heard so many people say, "I never get the opportunity. I never get the permission. I never get the time to try to validate, because I'm always being asked to do something else. I know that the idea probably could use some work, but I just don't have the space to do it." What advice would you give to somebody who was in that situation?

[00:16:12] Vinni: Before I answer your question, can I just make a comment on when you said the happy ending? I'm not saying this story was designed to be heard as, yes, there was a happy ending. In the current situation we still deal with the constraints. We still deal with all those challenges. It is still operating in an environment where the discipline is an everyday choice to show up and be consistent, saying that, yes, we have to push this thing, and we have to show people what we can do with this skill that no one has ever seen before.

[00:16:47] Which I think also adds up to the question you asked: how do you convince people for validation? Again, I don't have the golden answer for this, but I can talk about my situation. You don't get the chance to validate every time. Sometimes you do, sometimes you don't, but you keep on showing them the reason why you need to validate something. If I have to give more description from the portal story: at the beginning, when I came in, they really just wanted me to start working on that game board. The first thing I was asked when I came in was, "When can you start prototyping?" And I was like, "Hmm, I don't know, because I don't understand the problem."

[00:17:29] In some cases you just have to be honest. You have to tell your stakeholders, "I don't know." They come to you, they look at you as the UX person, and they're like, "We were expecting you to give us the answer." To that I say, "Yes, I can help you find the answer, but I don't have the answer, and this is how I can find it." Every time I make a validation request, sometimes I get approval, sometimes I don't, but I always start by making a case for clarity: this is why I need it, this is what we are missing if we don't get that answer. And then the responsibility is not on me, right? Because you have already shown your leaders and your stakeholders that because I don't have that information, this is the consequence that we might deal with in the future, and then it becomes a village problem.

[00:18:17] Host: Brilliant. The other part of your story that I thought was really interesting was how you twisted your advice, because, as you said, it's the UX of the people you're talking to. You want to make sure their experience is good, so you don't tell them their idea is terrible. You tell them, okay, let's twist it so that their idea still has an element of truth. Have you ever gotten pushback while doing that, though, like, "Why are you wasting your time on this? I've already told you what to do"?

[00:18:51] Vinni: A lot of times. When I propose research, I even hear comments like, "We are the smartest people in the room, so why do you think we need to involve more people in making the decision?" It happens a lot of times. Again, it all depends on how you pitch that case, and then once you hear the setbacks, in that moment you have to decide: is this battle even worth fighting? Because if you keep on fighting every single battle, you lose your collaborators, you lose your stakeholders. In the moment when you are getting that pushback, you make a decision: is this worth it? If it is worth it, then you go back with a second case of evidence for why you're making that point, or you do more research and build more evidence to make your point. Other times, you just choose to have a good collaboration over proving your point right.

[00:19:49] Host: Great. And do you have any internal tips that you could give people, your rubric for saying, you know what, this is a fight I really should keep going with, or this is one I should walk away from?

[00:20:01] Vinni: Again, it's knowing the stakes. I always think about the people we are doing it for, and whether, if I don't speak up, it is definitely going to impact the lives of other people at the end point. It's a lot of contextual decision making, understanding your environment. And sometimes I don't know the complete picture, so you have to find more answers and just keep on going. Again, I'm being repetitive, and I know that this is such generic advice, but this is really how things happen. You start with clarity, you keep going with consistency, and the trust and collaboration just keep coming to you.

[00:20:46] Host: Great. Yeah, it sounds generic, but it's that hard work of just going through the flow. The next question I have: you mentioned that when you went in, you were the UX department of one. That's a regular experience a lot of people have. Do you think this advice applies just to that situation, that team of one, or does it also apply to somebody working within a much larger organization, where they're a smaller piece of the pie?

[00:21:21] Vinni: I've been in a space where you are the first UX hire two times, and I've seen that in multiple different phases. My first experience was in an engineering environment, and the second was this, an employee-centered space. There you definitely have more ways to show the value of UX, to make those impacts with small changes, because you're building up that skill, which needs more handling of people, making them adopt something they have never utilized.

[00:21:59] But at the same time, if you think about this entire structure of clarity, consistency and trust in a bigger environment, you may not have hero arcs like this, where you could change leadership's direction. And this was one of the one-off cases, right? There were multiple other projects I worked on where the clarity was as boring as saying that this project is not worth it. No matter what the scale of the organization is, or even if I take the example of AI in today's use case: only if you make your ask clear, or establish clarity on your own ground about why you are doing this and what you are doing, are you able to get a good output out of it. It's the most generic advice, but I feel it's literally applicable to each and every single space, and not just to UX, but to a lot of roles and a lot of other things that you have in your life. I have even started following the UX design process in my own life. It's kind of a lifestyle for me now.

[00:23:07] Host: Excellent. Okay, I just have one final question for you, because I don't think it can be 2026 without asking, and this is to follow on from Mike's talk: how are you embedding AI into your processes? Or are you?

[00:23:25] Vinni: We definitely have all those initiatives in my organization going around AI adoption, all the things that everyone else is doing. But bringing it back to the point: AI is only as good as your understanding. If there are flaws in your understanding, those flaws are what are going to be amplified if you try to inject AI in multiple wrong places. But I do use AI a lot, and I have my own workflows where I've been channeling it.

[00:24:03] I do a lot of things, right? I develop, I research, I build strategies, and it's not possible for one single human to do all that. So I would definitely credit the AI abilities that we have available today for enabling me to do all those things without burning out or going way down. But understanding my organization's structure and environment, I would definitely say that a lot of organizations need those foundations set up before they can actually automate things with AI. UX is very crucial in that space: helping people understand what's missing, what's needed, and how to clearly establish those foundations before they can actually become AI ready.

[00:24:51] Host: Yeah, it's a brilliant point. I think a lot of people think, oh, we don't need to invest so much in process with AI, but it's actually the opposite. You need to invest more so that your AI can automate it as well as possible.