Matt Paige:

All right, I am pumped to be joined by Andy Silvestri. He’s a true master of his craft, with nearly twenty years of experience in digital design, including graphic design, creative design, user experience, customer experience, and even product strategy. Even ran his own customer experience strategy and design firm, Field for about ten years before joining us at HatchWorks to lead our Product Design practice. And today we’re going to get into the crucial role UX (user experience) plays in making sure you’re building the right solution, which is a big component of Built Right. But welcome to the show, Andy.

Andy Silvestri:

Hey, thanks, Matt. Yeah, it’s a pleasure to talk with you as always, and really excited to dive in deeper. It’s funny you mentioned Field. That was like another life.

Matt:

That’s actually how we met back in the day, when you were running Field.

Andy:

Yep.

Matt:

Yeah, and really excited to get into this. We’re going to go deep on UX. Andy is a master of the whiteboard in the workshop, I see myself in awe every time I see him lead a workshop. I’m just in the back taking notes like how is this guy doing this? But you’re going to love this episode today. Andy. let’s start off like high level, the tipping point of us because it does get confused, but what is the goal of UX? What’s the goal of user experience?

Andy:

Yeah, it’s a great question. UX is used in a lot of different ways. A lot of people talk about UX this that. I think that there’s this general mindset out there that is all about making things easier for your end user, minimizing clicks, and that kind of things. But it’s really more about just I feel enabling an end user or user base, making them or giving them the ability to be successful, and your solution coming in doing what they need to do. Getting the information or getting to completion of a certain task and getting out. That’s really it, So obviously, ease of use is a factor of that, but it’s really more about enabling your user because complexity is a good thing sometimes. There are systems that need to be complex because they are trying to convey very complex ideas, or they’re trying to allow a user to do very complex tasks right. So it’s not just about how many clicks can we minimize or how can we combine things so that it’s in one place. That’s it again, just all about that enablement.

Matt:

Yeah, that’s great insight and that’s a big thing. It’s like everybody is trying to get to let’s make this super easy, super painless. Yes, that’s good but some systems can be complex. It’s like how do you make the complex simple? And that can be a difficult thing to do. That takes a lot of a lot of hard work on the research side of it.

Andy:

Absolutely, I think that you touch on a key point there. I think that obviously, the further you get in a system, the more complex it becomes, the more specialized whatever it is that you’re doing for your users is, the more you need to understand what your users need right, and you need to be talking with them. So the research component, which I’m sure will get way deep in because it’s where my passion lies, is a big factor to being successful into having that validation in understanding.

Matt:

And when we talk about the goal of UX, you’ve got different stakeholders. Who are you considering when you’re looking at user experience? I mean, people typically go straight to the user, but it’s more than that. Who’s in your thought process when you’re starting your research on the user experience side of things?

Andy:

Yeah, research kind of goes both ways in the sense that you do need to factor in key stakeholders of a business. There is that component of making sure that you know whatever you’re doing within the system, whatever you’re creating for your eventual end users, those could be external customers, hose those could be internal employees. That kind of thing right there, your user. But the stakeholders do have you business needs that kind of drive the foundation of a system, so to speak. So really making sure that there’s a consistent kind of narrative, or a specific kind of objective that you’re getting to, and having the buying of the business is a big part of it, so that has to be kind of factored into, “Hey, how are we kind of approach enabling our users?” As I was saying. What do we need to offer them? How are they successful? What does it mean for them to be successful and how does that refer back to the success of our business, our platform? Giving them this ability equals something on the business end and it hits the bottom line somehow. So again, having both of those threads from a research and understanding perspective is critically important, I think. And, again, part of the process is marrying those together into eventually what becomes the end user experience.

Matt:

Yeah, and you hit on it too. Like if you’re building a solution, it’s got customers. It’s got to be viable. It’s got to make money. You can keep continuing to offer this thing to your customers. That’s that’s that balancing act where, if you sway one way too much on the user side or one way too much on the business side, you can be in a bad spot. It’s finding that kind of harmony between the two. Your user and your business. Something your users love and something that your business loves in terms of viable and continuing to be self sufficient in the future.

Andy:

Yeah, having that feedback loop is critical, right? Because what you want to do is, of course, have continuous research and have it be built in to the DNA of how you’re approaching the user experience of your product or just your business in general. At the end of the day you want to have that feedback loop from customers and users. What are they saying? Okay, how are we kind of bringing that back up the chain and presenting that internally and either debating that folding it into existing initiatives or at least having some level of conversation around, “Hey, this is what our users are saying. We’re looking here, but maybe we need to be looking there because of what we’re hearing.” So again, it’s very important to have that as kind of a backbone of how you’re approaching creating the experience updating the experience, having the experience expand. All those kinds of things.

Matt:

Yeah, it’s a good segue into the next thing I was wanting to hit on. So you talk about a UX Mindset. It’s not just reserved for a couple of folks in the product designer or UX side of the house. It’s a mindset within the whole organization. Take us through that. What do you mean by a UX mind set? Go down that.

Andy:

There’s a couple layers to that. On the surface, there’s obviously the idea of, “Hey, we want to be presenting a good experience, right? We want to delight customers.” You hear that all the time. And then there’s this idea of, “Do the UX! Just UX it.”

Matt:

Just do it.

Andy:

Yeah, just do it. but I think that user experience mindset really starts with that kind of design thinking mindset as well, which is starting with empathy for your user, understanding what they need, getting inside of their heads. Walking in their shoes. A lot of customers a lot of times just assume they know. “Oh yeah, we get it. That’s cool. We’re going to just do this because we know that this is what customers want.” You start to peel the onion and it’s something completely different. In a way, you start with that empathy, you understand, kind of walk in the shoes of your customer, your user. Then, from there, you start to define and you continue to iterate and prototype and present things back to the customers and continue to narrow the focus or get more and more validation. And so really like that’s the cyclical mindset. That’s really what you have to have throughout the process of creating your product or your solution. You can’t just go in with assumptions and lean on those. You have to have that validation. So the more you can just have that as as a directive, “We’re going to empathize. We’re going to get inside the head and try to understand. Not just ask them questions, but try to understand who they are realistically. Who is my customer?” There’s a lot of emphasis sometimes put on creating persona out of your surveys. That’s a great tool for organizations that need to have kind of that crystallization of understanding, but at the end of the day it doesn’t have to be that cut and dry or that polished. You can just still have a running understanding in a narrative of who your user is, just by talking to them and documenting that and continuing the process. So that’s really what I mean about it being a mindset. It’s more about, we’re not just here to do the UX, meaning we need some wireframes, we need some user flows. We need to understand. We need to have that understanding be the backbone of what we’re doing.

Matt:

Yeah, we weren’t planning on going here but give me your hot take on personas. You know, Jill. that’s forty years old and likes comedy.

Andy:

I think they can be very valuable when especially when you have a larger organization that needs to rally around an understanding and you need to disseminate this persona to multiple business units or multiple groups within an organization that might not be very closely tied to product or design or the management side of a product. I’ve seen this happen with typically much larger groups, but you can create marketing campaigns around your personas for internal use. You can do that, and I think it’s very valuable in those organizations when you’re trying to disseminate a particular perspective on your customers. Just so it’s top of mind for your employees and the people that are working within your organization. So again, they have their place. They do absolutely have value. But it’s not necessarily something that always has to happen. There’s this idea that, even in the early phases, of just user definition, meaning that, “Hey, our users are this and we have a dossier on them.” It doesn’t have to be to the level of its personified, as Jill from Vaudowa who does this or that. To your question, they do have very real value and I think they’re an important part of the overarching universe that is user experience.

Matt:

And so much of it’s like, “What is their goal? What are they trying to achieve?” It starts getting into that path of your jobs to be done. That’s where you start getting those nuggets of how you architect and design a solution for your users.

Andy:

And the cool thing actually, just to kind of keep digging on personas for a second. The cool thing is that they can evolve so you can have them established one way from an initial body of work, and again, if you’re keeping that mindset, you’re continually doing your research, are continually talking to customers, you can bring that back into reevaluating your persona. You might have started with saying, “Hey, these are the ways we thought they sliced out. Maybe that’s not true anymore. Maybe there’s more gray area than you initially thought. Maybe there’s more personas in your platform? Maybe there’s more ways in which they’re using our platform or your solution that you never really thought of.” You’re learning through this continuous discovery and research.

Matt:

You mentioned a word a little bit ago. Assumptions. Which, it’s great to have assumption. You gotta have some ideas of hypotheses. I think where we see breakage happening is when you’re not validating the assumptions. Take me through that. The importance of validating because I can’t tell you how many times we’ve been burned by this in our past. You think you know your customer and you have an assumption and you run with it, and then you build something and you find later that it’s not the case.

Andy:

Yeah, right, and again that’s a very common and it’s a very attractive way to approach creating something. Let’s go as fast as we can. We know what we know. We think we know right. And it’s typically, there’s a perception that to do the proper level of research and getting the right data to validate your directions will take a very long time, or it will be a very significant investment. But that’s typically not the case. Realistically, going into even a handful of conversations with customers or your end users can be extremely valuable to getting some level of that validation. There are a lot of thoughts out there around what’s the proper level of research you need to be doing. How many people should you be talking to? Going all the way up until you need to talk to at least twenty-four or thirty-six. It’s usually divisible by twelve. I don’t know. But in my experience, honestly, even after doing some pretty pointed interviews with again your target customers – that’s a pretty big caveat that you have to be targeted in who you’re talking, which comes with, you kind of get there from the earlier definition. But long story short is, if you even talk to half a dozen people, six to seven, you’re going to start to see themes emerge that should marry to helping validate your assumption or disprove them right. So if you talk to six people and they’re going one direction and you were thinking the other, it’s a pretty good indication that you talk to six more or twenty more or fifty more, you’re going to get that same kind of trend. Atthe end of the day it’s a lot about how quickly or how efficiently or how easily, so to speak, can we get people’s feedback. Can we talk to them? How can we access our end user? Right? Is that a fifteen-minute phone call? Is that, in terms of if it’s an internal project, can we talk with co-workers who are using this platform or this system? Can we spin up something that’s a really low effort, kind of objective, and get them into just the conversation? That’s real. I think that it doesn’t have to be some big long drawn out we got to playing out six months of research and we got to do this and that. But as long as you’re saying on top of it right, and you’re not just being like, we did six were good, you have the ability to continue to do that right over the course of your product. I think that’s enough to just keep it going right to always have that touch point and have it again and be like we’re talking about with being in mindset. Have to be a routine part of your mindset in your approach and your process.

Matt:

Two separate threads here that I think are really interesting. the first one being you mentioned a minute ago. When people think of UX and starting like they want to hit the ground running. They want to start getting value. They want to start building, and a lot of people think that the UX side of it is going to slow them down, but talk though that. It’s actually a way to save some money in the long run, if you can validate some stuff up front versus building, rebuilding, and all of that.

Andy:

Right, like I was just saying, I think the temptation is, let’s save the money. Let’s start quick and let’s just start doing things and creating things right. Ninety-nine percent of the time, if you do it that way without any sort of validation, any sort of feedback or input from your end user, you’re going to be changing things sooner than you think, so you’re going to lose that money that you saved up front in the know by redoing or having to rebuild, or god forbid, completely scrap something that you thought was was the right way right. That’s just one way to look at it. You’re either making the investment upfront or you’re making the investment later. And it’s much more painful the further down the path you get.

Matt:

Yeah, the pain definitely escalates. So in that same vein, UX can be daunting for a lot of folks that are looking to take this on, and bring it into their organization, But it doesn’t have to be. How can folks get started like it’s It’s the MVP of UX for an organization that has not done it in the past? It doesn’t have to be this big crazy thing. Talk us through where’s the best spot to get started in kind of a minimal way.

Andy:

Yeah, I would say the best place to get started is to really do that look in the mirror and say, “How can we define our users or end users?” Really, just start with that definition, because they’re going to be the ones who are ultimately determining whether or not, you’re successful. At the very least, drafting that up and saying okay, this is who we’re going for. This is our core target. And if that’s multiple targets, that’s fine. Doing the same process for multiple users is fun. Getting that as a baseline is something that’s really just about again that look at the mirror. The internal kind of let’s do this, let’s make sure that we have the right understanding of who we’re doing this for, who we’re creating this for. Sometimes there’s existing users that you have, of course, that’s easier for certain organizations than others, or you’re starting from a cocktail napkin. From there, then it’s about what are we enabling them to do? Like I was saying earlier, What are the jobs to be done, so to speak? That framework that you can use. What they have to be doing in this platform or the solution in order to be successful. And can we start to think about what that is once we’ve defined that a bit? What is that in terms of prioritization? How do we look at that from like a phased approach? We know that there might be a dozen things that this user needs to accomplish to be successful in various ways. But what’s the most important thing? That eighty-twenty rule. If we were to, frame up this, this twenty percent of a platform or solution, what would give them eighty percent of the value of it? That kind of mindset I think is helpful. And all of this is really whiteboard work. It’s nothing that needs a super fancy degree or anything, It’s more conversation and analysis and retrospection. And making sure that all the stakeholders that are involved in this product are present and have and have input. From there you start to get some traction right around who this customer user is, what their needs and pain points are. You might. even at this point, if you can bring in some conversations with those types of individuals to again start that validation cycle. And from there then it’s like this is framing up as a thing that makes sense. And we’ve started again to get that validation, that understanding, were aligned internally. Our users, who we’ve kind of defined have given us this level of input. We can start to look at, bringing in the more formal process of let’s start to frame up things to show them as prototypes or as wireframes or whatever it might be. Let’s do that high-level conceptual work and continue the process. So you’re just kind of ratcheting up the fidelity a little bit. But like it’s the same kind of process. Okay, We started with words. We’ve gotten validation. We’ve gotten people involved. It makes sense where we’re going. Now, let’s start to show them things right and those can be crude sketches. Doesn’t have to be using fancy high and tools for this are a million tools out there that allow you to do this kind of work. You know, That’s really the process, and just kind of again, like I was saying, ratcheting up the fidelity getting a little bit more and more clarity and invalidation as you go along and keeping that going until eventually you’re like “Hey, this is the system and you know we have a very clear picture of what we’re going to do first.” And then you start to get into, of course, implementing that thing. So that’s where user experience turns into interface design. But it also then starts to become a delivery and a development kind of process. So but you can prototype all the way through that which is great. And you can do so in a very crude manner. It’s not like there is a certain level of fidelity that you have to have to show people of a concept. I guess the one caveat there would be that. Just make sure that whatever your user is, who, whoever they may be, that they can consume what it is that you’re presenting to them from a concept. Sometimes your user base is savvy enough to understand what you’re trying to insinuate through a very crude wireframe or a very rough sketch of something. Other times that might not be the case right, so you might have to be more successful going into those kinds of scenarios with a more polished kind of prototype. That’s maybe more clear and might be more direct, but again, that’s part of you as an organization starting from that basis of understanding your user and saying what do they need to be successful? And how can we present them options or concepts and ideas that make sense to them so that we get the optimal amount of feedback and in the right way.

Matt:

Yeah, so many good points there. You don’t need like this focus group thing that’s this big, expensive drawn out. Just talk to some customers. Start there and I don’t know about you, for me, it’s all about the qualitative. You can only glean so much info from a survey. Yes, they have their purpose, but the qualitative talking, picking up on these nuances. I’m almost thinking we need some type of guide or tool because you see Andy work a customer interview, it’s a thing of beauty. So maybe by the time we air, this we’ll have something out there for that. It’s powerful and it’s this process and, this is where it gets interesting, gets back to that concept of the mindset. All right, this is not a one-and-done thing. This is not something we do in the beginning. All right, we’re done. Move on to the next thing. It’s this concept of continuous discovery and continuous delivery on the build side. This is a Tim Herbig thing that I know you’re a big proponent of. But it becomes part of the organization’s ethos, it permeates the entire organization. But talk us though that concept of continuous discovery, its touchpoints throughout all of the process.

Andy:

Yeah, absolutely. I think that’s what’s interesting there is that you know, at any one time you have those two threads going, You have discovery and delivery, so to speak, and at any one time, they’re kind of like one hand washes the other. Discovery is being done in a way to inform the next phase of delivery. You know, delivery is being done in order to create artifacts and elements that could be used for discovery. So it’s this interesting kind of ebbs and flow. And again, the intensity of one or the other is dependent upon where you are in the life cycle of the product. I think it’s like you were saying, this mindset, having that understanding of how are your teams structured. When you start to get into teams like we have at HatchWorks where we have a discovery, in a definition, product team working in tandem with a delivery team, from an engineering perspective, that team is one team realistically. And every single day there is an ebb and flow of like, What are we using to inform how we develop the next phase of the work? What are we hearing from research that we’ve been doing with customers to inform how we pivot? You know, if we need to, or if we’re enhancing something, or you know, creating something new, and similarly it’s you know, from a delivery perspective of like Hey, we can. we can now demo this thing right. We have this thing ready to go that we could use as an artifact in validation. Or it might spin up things in a sandbox to use as a prototype. You know, so yeah, I think that that’s It’s really interesting. you know, when you get into kind of the fluidity of that kind of team and that kind of process, it all just becomes the cyclical thing where you’re kind of inputing in what you get. It’s going through this idea of defining and building and validating. Then you’re delivering and continuously doing that. So yeah. It’s excellent. That’s the way to do it. 

Matt:

You always hear about the CI/CD but that continuous discovery piece often gets overlooked because it’s not the technical piece of it. It’s that dance, that tango between problem space and solution space, and it’s ever kind of expanding and contracting and expanding and contracting. And that’s the best products out there. That’s the process they follow. It’s not this waterfall manner.

Andy:

Yeah, absolutely

Matt:

One area. So you think of UX… a lot of people are always thinking like I got this back of the napkin idea of drawing it out. You’re going to design this thing and build it, but when you’re modernizing something existing, you’re re-designing something existing. UX, it’s one of the most critical parts, right because you’re users are typically using your system in unintended ways. Ways you don’t even know. Go a bit deeper in terms of like what to consider when you’re re-designing something existing. Same principles apply. but there’s some nuance there.

Andy:

Yeah. it’s great and it’s a really fascinating topic because to your point when you have something that’s established and you start to peel the onion, you go through the process of talking with your users, you’re going to see all the duct tape and the paper clips that have been put in there and all the things that people are maybe they’re using a third party system to kind of augment what they’re doing within your platform. And kind of coming back to it, you’ll see some really, typically the older the systems is, you’ll see some very unique and interesting workflows that you may not even be aware of. Right. So, again, hat’s where it’s critically important in modernizing something and making it new that you take the time to unpack all of that. Because there is a very real challenge in getting people to give up those processes that they have established. You know they’re kind of baked into their workflow. Especially, we see this a lot in internal software that groups use for you name it internally. There’s a very isolated user group, a very specific user group that’s using this thing to do a certain thing, and they have created their own ways to be more efficient and more effective. And you’re hearing things in the pain point side as an owner of this product, of this initiative, that you want to solve. But the pain points that surface to you know to the top are really the downstream of what’s happening underneath the folks are doing with your platform. So it’s really about okay. We got to unpack. We got to do some digging. And that’s that can be a daunting thing ro think about it. We do you start, right? Again, though it’s about just talking with your users and maybe shadowing them on their process. We’ve done this with customers where they’ve been in the middle of moodernization, and there’s been interviews with you prime stakeholders, and also users of a certain platform where they’re trying to get everybody to go on to a new platform that’s kind of being built in parallel with a more modern interface, bells and whistles, looks very fancy. It’s really nice. It was a great design for the new system, but nobody was using it because it didn’t do a handful of the critical things that people were doing with the old system That hadn’t yet been addressed in the new system. So you think about that. If you had known that from the get go, that’s how you would have prioritized your road map. That’s where it’s one thing to start an initiative and say we’re going to just rebuild this. We’re gonna just take what we have and we’re gonna do a coat of paint to it. Everybody’s gonna move into the house and it’s going to be awesome and everybody will live there and be happy. But to get all your stuff out of the old house, you got to move it over.

Matt:

Exactly

Andy:

I think that’s why it’s critically important to take this mindset into a modernization project because you have to be able to do that deeper dive. And from that use that prioritization to inform where you’re going to start phase one right. Like eighty-twenty, We do this in phase one. That accomplishes eighty percent cool. We can deprioritize. These other things that we thought might have been the focus, but are really more nice to have when we really unpack what our customers are doing with the platform.

Matt:

There’s so much opportunity in how users are using your system today. I can’t tell you how many times you and the team have gone in and started talking to people using the system today. And you come back with, “Hey, They’re doing the XYZ thing. It’s not in the platform.” Our customers or stakeholders are like, “Are you serious?” It’s like a surprise factor. 

Andy:

Right? Everything funnels back to Excel or something like they’re using Excel. What are you doing about it?

Matt:

Yeah, That opens up new ideas though, which is cool because you’re like, well, we could solve that problem with our solution. And that’s where the real fun stuff starts. And with an existing solution, human nature is weird, right? You got the endowment effect at play where people are more likely to retain something they have, even if something else is better, because they just value it more. And then loss aversion. They value the pain of a loss more than gaining something. Like the old adage of a bird in the hand’s worth two in the bush, right?

Andy:

Yeah. go with what you know right?

Matt:

You’re Competing against that.

Andy:

I mean, it gets into a habit-breaking kind of process. You have to prove that the new thing you’re doing is truly better for that adoption to happen. And it can’t just be the same thing with a better coat of paint. It has to be better for me to be like, “Okay. I’m going to make the switch.” And this happens across the board with any sort of interaction that you or I use or anybody, right? It’s like you know I’m big on Sonos. I use Sonos all the time because I feel like the interface and the interaction and the integrations were fantastic for putting music throughout my house. But I have friends who use other services and are like you gotta jump over to this. I’m like, “No way, man, I’m invested.”

Matt:

Yeah, and the last thing we’ll wrap, this has been awesome, but the bar is at the level of what customers experience with other things. It’s not. It’s not your thing, but their bar. It could be how they experience stuff with Apple or Google or name your thing. That’s the bar that they expect. That’s another reason why user experience is so critical.

Andy:

Yeah, a hundred percent. We live in a fantastic time, I sound like some old timer, a very interesting time where we have all of these fantastic like there are groups out there like you mentioned, Apple, and they have put a ton of work into really nailing user experience. And the proof is in the pudding. Their products are ubiquitous. Everybody knows them, everybody uses them. There are wars about Apple versus Android. They are an entity within just human experience. It’s not just user experience. And so from that like realistically, you’re being measured whether you like it or not on that bar like you said, You can’t like you’re coming into the game with your service, your solution you, you have to, it’s reasonable to expect your users to expect that kind of experience, right? So again, the more you can kind of adopt, and and really, Um, you know, study and understand what it means to have good user experience again. It’s not about visuals. it’s not even about ease of use, right, it’s about true and utter enablement. Right. The more you can understand, the more you can kind of ingrain that into what you’re doing with your product or your solution, the better off you’ll be, because then you’re gonna be right up there with those heavy weights that have been doing it for years and years and years.

Matt:

Yeah, and not to end on a daunting note there. Definitely, just get started with talking to your customers. You have these examples out there too. That’s the thing. Look to tertiary to other things. Even outside of your category. There’s so many great experiences out there you can tap into. Andy, this has been awesome. There are so many rabbit holes I want to dig deeper into, but we’ll save those for some. Future episodes will definitely have you on again, but thanks for joining us on Built Right.

Andy:

Thanks. Yeah. It’s been a pleasure and any time you want to talk, you know where to find me

Matt:

Yep, sounds good. talk to you later, Andy.

Andy:

All right, yeah.