Infobrew Session on Good User Experience with Richard Alvarez, CX/UX Service Line Director

Cheers. Welcome to another edition of InfoBrew. Really excited here to talk about design with Richard Alvarez, one of the leader of the design practice here at Apexon. Welcome, Richard.

Thank you. Thanks for having me. It's a pleasure to be here. Excited to talk about UX.

Well, you know, it's one of those things that's really underestimated. Can you give a really good, you know, short dramatic example of where it's been done right or wrong and what kind of difference that's made for people? You and I were kind of bouncing ideas about this very topic. I think one of the things that's kind of circling my head is the cost of doing it wrong.

I think a lot of companies, legacy companies have kind of been in these software development processes before without having a good understanding of what UX brings. They'll take a chance and they'll do it the wrong way. And there's a heavy price to pay for that. Not just frustrating users, but losing users because when we don't listen to them and don't give them exactly what they're looking for, solving their problem, why are we letting them be our beta testers?

More importantly, why are we giving them an opportunity to go look at the competition? It's interesting you're talking about how do you build that relationship with users to really understand what they're trying to accomplish? Because sometimes people don't know what they want until they see it. Absolutely.

Yeah. Yeah. There's a, there's an old saying from, uh, Henry Ford, I believe that said, I asked the users, you know, what they wanted. They all would have said a faster horse, I think, or something along those lines.

And, you know, what I understood was they wanted to get them point A to point B faster. That's the problem we were trying to solve. So for us, it really is just UX means talking to users. We advocate the user that service of the business.

You marry that with the business goals, but first and foremost is our users. Who are they? What do they do? Why are they doing it?

And what problems are they trying to solve? Now, do you spend a lot, how do you start to build that relationship? Is it mostly observational? Is it by interview?

Is it, you look at a process analysis? What approach do you take? All of the above, all of the above. If you, if you ever look at any of our sort of war rooms, it's a beautiful mind, you know, lots of different connected pieces.

There are artifacts like persona building that we do get get get in touch with our users talk to our users and try to understand who they are based on real people uh this is an artifact that we can always point back to and and say you know what would Avery do in this situation I always kind of think of it like a lot of people are familiar with the the tv show friends and those characters are so so well defined and in any situation I can come up with the oh you know Monica would have done this or Joey would would have done that because they're so familiar to me.

It's the same thing we do with the persona. You really try to get in their minds and understand who they are, why they're doing it, what they're feeling when they're doing it. Then we go through an exercise where we're building a journey map and we actually take a task using the persona and understand what are all the touch points that that person, that persona might have with a particular product or a task, and then look for what we call pain points and high points, moments of truth where we can say, oh, here's something that's not working or something that really is working that we want to keep.

And so how do you do that? Do you look for how they react to the technology? Do you look, is it like time in motion where you say look if they do it we watching people a set of people get lost at this point in the process Lots of different ways to do that So in lots of what we do is user interviews and stakeholder interviews. We'll have usability testing.

The design thinking process means that, you know, we're going to focus on a problem to solve, ideate on different ways to solve that problem, build a prototype, put it right back in front of our users and validate that idea. It's a very iterative process. A lot of people ask us, you know, what's it take to go into UX? And my first response is always, how comfortable are you with making mistakes?

Because that's what we want to do. We literally want to be the most naive, the most uninformed, because we're asking a lot of questions. We're trying to get in their heads. We're trying to understand what the needs are.

And so as we put our prototypes together, we're trying to answer these questions and see what works and what doesn't work and iterate on that. And so we do build that roadmap for what a successful product looks like. You and I were talking a little bit earlier about, you know, what's the outcome of allowing our users to be our beta fences. That's what we really want to avoid.

That's why we have a design thinking process, a discovery process, so that we can do that, find where those pinpoints are coming from, so that when we do go into a delivery model, we know what we're building. And, you know, it's not done. It's always going for improvement. But we're in a better state where we have answered some questions, and we're confident that we're solving some problems.

and a lot of what you're talking about involves a lot of empathy so how do you develop that empathy for the user because sometimes they're really different than you are no that's a great point i mean ux starts and it's all about user empathy putting ourselves in our users shoes and understanding walking you know in in their in their shoes and understanding what they do that's why we build personas that's right we do the journey mapping that's why we talk to our users. But I think there's a big debate about empathy from a single user.

We really want to be well-rounded. A lot of what we do is a double diamond theory, which is divergent and convergent thinking. We do want to allow ourselves to get different perspectives and talk with other people on our product team. Those various voices from our users, all different types of users, the competition within our product team, data folks, developers, salespeople, marketing people, anybody.

We want to facilitate those answers to sort of bubble up and think outside the proverbial box, if you will. You know, what else should we be thinking about? You know, it can't just be from, you know, just the one perspective. We really want to balance that out with a full understanding so that when we do provide these answers.

It's not just what you talked about, what one user, what a single user wanted, and we just did exactly what they did. What we do is facilitate them, try to understand where is the problem and how do we get to the root of it. I think a lot of what, another classic example is someone talking about changing a light bulb in the room, and if you just listen to the one user, you know, we might say something like, maybe you need to, you know, buy a better lighting system within your room, or maybe it's changing the light bulb, or maybe it's getting a battery, maybe it's stepping outside, or maybe it's listening to an audio book, lots of different ways to solve that problem.

But we do need to have all those perspectives and get a full understanding on the business side and obviously advocating for users So you know to do that they got to build you know obviously you have empathy but they also have to have to have the trust in you And how do you what are techniques you have to build that trust with users so that they can, you know, share with you not just what they might think the answer is, but what the real problem is? Yeah, you know, I think a lot of that comes from understanding what different biases are.

There's all kinds of biases that we, that you can injecting to a user interview or into any one of these processes. And so I like to think of ourselves as more of a psychiatrist than a doctor. We are not a design team where it says, oh, what's the problem? We need to fix it here, write a prescription, do these things and everything will be fixed.

We're more of like the psychologist that's listening and trying to understand and facilitating those solutions from within our product teams, from our users, and helping that, the right answer is the right path along by facilitating and not by, it's definitely not a cookie cutter approach because we're advocating for users. We're not just going through a process to get to a known answer. We're trying to understand this unique problem and bring a unique solution to it. You're talking about a lot of different sources there, which sounded very divergent.

How do you then converge it back and identify, for instance, for our people viewing, how do they find the best or at least a very good opportunity for UX improvement in their business? Yeah, that's a great question. I think that one of the confusions is that UX design is all creative. And I like to think of it as more science than art because UX is about problem solving and there is a solution, you know, there is a right path to get onto.

And that comes from a very scientific method. We call it the design process, design thinking. So all those ideas, first, very divergent. Anything goes, pie in the sky.

And we go through exercises where we say, like, let's think of, you know, there's all different ways of doing this, but there's one exercise where we say, let's think of the wrong way of doing it. Because sometimes that allows us to think in a different perspective of like, okay, that obviously will not work, but maybe this might work or using completely different, you know, ideas from not this project, but other things we might've worked on. And like I said, you know, various voices in our product team and our users, all of that's very helpful so that when we do focus on an idea or building a prototype, we're validating what works.

And that's a time when, you know, as a team, as a product team, it's meant to, hey, poke holes in this. Tell us why it's not going to work. That's what gets us onto the right path. We go through that very iterative process until we can't poke any more holes in this.

We're on the right path. Let's start producing these things. And how do you get the, you know, sometimes you're going to come up with solutions that are difficult to implement technically. And so then you've got to go and convince the technologists that they really need to go do this, even though it's going to put a lot of workload on them.

Yeah, a lot of that really depends on the maturity of the organization we're working with. If we're working very siloed, hey, that's designs realm, that's development realm, this is when QA comes in. When it really works well, it's a product team. We all working together and we all want the same thing We want to build the best product So our work isn really just the realm of UXers We definitely want to work with our developer partners our data partners our product owners, business people.

And like I said, anybody who wants to get involved in the process, any stakeholder who wants to see the success of this, they've got some opinions and the perspective of what that ideal state might be, what that future state might be. And they can definitely help us to poke holes in, you know, all of our prototypes. Why isn't that going to work? Maybe because, you know, business reasons.

Maybe there is a delivery that was promised by a sales team, or maybe there is a technology that we're working on. We all need to be aligned. And when it really works well, those things come into play in that discovery process too. Hey, this might be the great idea, but it's just not going to work because of maybe some technological limitations or some expectations that we have down the line that we're just not seeing yet.

And so one of the interesting things we're kind of talking about is how to make, almost make this design invisible, almost make it transparent. So you just get access to the technology without the interaction getting in the way of your outcome. 100%. Yeah.

I mean, there's a lot of great design firms out there who are going to win you know, the awards for the aesthetics part of it. Our job is problem solving and being productive for our users to be productive, to get and accomplish whatever task they set out to be. A lot of our clients are in that B2B space. So they don't even have a choice of using a particular software.

This is what the enterprise has decided to use. And so for us, you know, the goal of our products, our design is to understand what problems they're trying to solve. What does it mean to be productive? What does it mean to reduce errors?

What does it mean to reduce redundancies, to reduce those calls for the help desk, to keep the focus on still an enjoyable product, but less on not necessarily make something ugly. Like we definitely want to make that as aesthetically pleasing as possible. But in many cases, it's not about the design for, you know, a lot of those reasons. We're doing it because it's style guides and the brand guidelines and, you know, marketing has a lot to say with that.

So we definitely are in line and in sync with what the aesthetics need to be. Our focus is going to be on being productive, making usable products and keeping a lot of, you know, someone's noticing. I love that logo. That's great.

But it really tells us, hey, we may not have done our job because they're noticing things that we don't want them to really pay attention to. You want them to get the job done. So you're more interested in the house that's wonderful to live in than the one that looks good. A hundred percent.

Yes, absolutely. Well, look, this has been really great. And I think this is a lot of, hopefully a lot of food for thought for the people watching in terms of, you know, where they're seeing friction in their business and in their technology. And, you know, some new ideas about how they can look to remove that friction.

So thank you for that. Thank you, Eber. It's been a pleasure talking with you. Likewise.

Well, to those viewing, I hope you enjoyed this Infobrew and I look forward to bringing you the next one. All the best.