IpX True North Podcast
The IpX True North Podcast is a global industry resource for all things people, processes, systems, and technology created to share conversations with our network of thought leaders, innovators, and founders changing the shape of the digital future. Here we share their stories, impact, vision and tools for success in the areas of process optimization, engineering, the model based enterprise, operational excellence, and digital transformation.
IpX True North Podcast
Designing for Digital Adoption: Why UX is Good Business with Nick Cawthon
User experience design is not just about aesthetics—it's essential to ensuring adoption of enterprise software and achieving return on technology investments.
• UX is frequently treated as a "nice-to-have" rather than a strategic business necessity
• The double diamond approach combines generative thinking and synthesis to create user-centered solutions
• Early examples like Uber and iPhone demonstrate how thoughtful UX removes barriers to adoption
• When users encounter poor experiences, they create workarounds that introduce costly errors and inefficiencies
• Organizations should build feedback loops throughout implementation, not just at final testing
• AI tools promise to accelerate development but require careful application to avoid magnifying poor decisions
• Successful digital implementations require viewing experiences from the user's perspective, not just meeting business requirements
• Continuous feedback cycles help identify problems before they become embedded in final products
• Enterprise UX should consider the entire digital thread, focusing on connected systems rather than isolated tools
Start integrating user experience considerations from day one of your implementation projects. Visit https://gauge.io/ to learn how to mitigate the risk of project failure through proper UX design and implementation.
Stay in touch with us!
Follow us on social: LinkedIn, Twitter, Facebook
Contact us for info on IpX or for interest in being a podcast guest: info@ipxhq.com
All podcasts produced by Elevate Media Group.
Welcome to the IPX TrueNorth podcast, where we connect people, processes and tools. Hello everybody, welcome back. This is the IPX TrueNorth podcast, where we explore the intersection of operational excellence, digital transformation and the people driving that change. My name is Brandi Taylor, your host for this episode, and today we're diving into a topic that every organization faces when rolling out new digital tools how do you ensure that your users are actually going to use these tools? So rightfully so? Digitization projects focus on business requirements and configurations, sometimes only to realize maybe too late that the system feels clunky, maybe it takes too many clicks or it frustrates users to the point of resistance. So joining me today is Nick Kaufman, a UX specialist with deep experience helping organizations translate business needs into user-friendly, efficient and effective software experiences. Thanks for joining me, nick.
Speaker 2:Brandy, that was an excellent description and you even got the pronunciation right. Thank you so much.
Speaker 1:Oh good, I would hope you'd correct me if I made that mistake.
Speaker 2:Thank you for having me.
Speaker 1:Oh yeah, it's a pleasure. So today, really, it's a conversation in my mind about designing for adoption from day one. Right and why. Good UX is good business, and we often discuss on our side at IPX the organizational change management piece of adoption, but we don't often enough talk about it from a usability perspective. So you know, let's go ahead and jump into this perspective.
Speaker 2:So you know, let's go ahead and jump into this. Yeah, you had a great lead in when you talked about business requirements and clunky experiences. That's sort of my bread and butter and where I live the notion that if we have a six-month design and development process, that we can save it all towards the end and do usability testing and figure out acceptance testing and all those aspects of did we do the right thing. I think that that gets thrown into question of what do we ask ahead of time? What kind of usability studies or in-depth interviews or qualitative research can we do to ensure that it never feels conky, that it just works? And those are the areas that I like to play in.
Speaker 2:The British Design Council has this double diamond analogy very abstract, but it starts with this generative thought of not pretending you know the answer, but going out and validating that you're making sure you design the right thing and then, with enough research and understanding of strategy and differentiators in the market or emotions and vulnerabilities that the users might go through, you gather back and then you go from a generative thought process and for those of you who are listening at home, my hands are moving outward on the left side of a diamond to now a synthesis process, where you're trying to understand what it is we just heard and that leads you to think okay, now that we understand requirements and where we're going to save the user's time and improve their experience, how could we do this?
Speaker 2:Let's take from a green slate and that goes back to a generative and then a synthesis at the end. That's the double diamond approach and that's where UX comes in. It helps facilitate that process amongst PMs, amongst engineers, stakeholders, and tries to be that human in the loop, that user-centric approach to the design and development process of any product or experience.
Speaker 1:I love it. So, you know, I think everyone typically thinks of this as something that's developed into the tool, and there's a lot of that. But I also want to make sure that you know today we're thinking about this from an implementation perspective too, right, because these tools are meant to be configured, you know, and so we want to make sure that. Are there things that we can do, you know, from our perspective as well, as companies implementing tools or as users or as IT team or whoever's writing these requirements. Is there something we can include there to try to have some of that as a forethought? So I guess, before we jump in too deep, I would love, do you mind just giving our audience an introduction of yourself and maybe a little bit of your background, so we understand kind of your experience and where you're coming from.
Speaker 2:Sure, here's the origin story. For those of you who are listening during the summertime of 2025, and that might have school-age kids in the house, this is camp season, where they go off to their various camps. And I remember a time maybe I was eight or nine years old where I was at a camp and one of the counselors sat us down at the table to do some drawing exercises, and I remember that I came away from that 15, 20 minutes of a drawing exercise. I'm really pleased with my outcome and what it is that I had done, and I had sort of held on to that memory many, many decades later now as one of these affirmation of you know, this is not a bad thing to do with my time and with my mindset.
Speaker 2:I think I was one of the early instances of a flow state where you know as a kid you don't quite know what flow states are and how rare and wonderful they can be to all of us that are constantly trying to achieve them.
Speaker 2:But that has given me reflection about who it is and what I want to do, and I've held on onto that throughout the universities and then into my early career, and so those visual designs into interaction design and then interaction design, when it became more of a experience-based concept, where it wasn't just the interaction or the interface, it now became the entire experience of somebody as they went through a product tool, technology event, whatever it might be, that spun us designers off into being researchers as well, so that our subjective presentation of a ui or design was now being processed by somebody else.
Speaker 2:And where did they get confused and where was it intuitive? And that has been sort of where I've sit ever since is to be able to conduct research and strategy to inform educated design decisions, to sort of mitigate risk of are you designing the right thing? It's like no, we can prove that we did the homework, so that it's not just this showcase of technology or shiny new tool. This, in fact, is meeting a user need and will be adopted upon arrival. That's about 40 years and 30 seconds, so thank you for letting me know that.
Speaker 1:Awesome, okay, no, that's perfect, thank you. So to kind of continue on with our discussion. So, from your perspective, what are the biggest misconceptions that organizations have about user experience? And I know we keep saying UX. I just want to make sure everyone understands that we're talking about user experience here with enterprise software projects.
Speaker 2:Yeah, you know, misconceptions 20 years ago was that anything with a perceived aesthetic was seen as weak or not enterprise grade, if you think of the old sort of Oracle databases of the past or the Sun Microsystem CD ROM where you install or have just really bad UX of their interfaces. But there was a badge of pride because it was built by engineers for engineers and so that must be of quality. A horrible metaphor that I'm using is a Russian tank isn't known for its seat cushions. A Russian tank is big and robust and, current geopolitical situations aside, it brings to mind this sort of impenetrable efficiency because we built it to be big and strong.
Speaker 2:But the iPhone changed that, where this notion of it just works, and that it clearly played attention to it and it had a design aspect to it and, most importantly, was wildly successful and it made Apple the most valuable company in the world at the time.
Speaker 2:And it changed the perception of design and there was also this notion of Apple products of just working is that they changed the perception of experience, where they anticipated human needs and points of confusion and were very good at understanding those paths of decision and consideration and really began to be the forefront of what it meant to deliver an experience.
Speaker 2:Another early example is Uber, where there was this notion of a peer-to-peer economy that wasn't as commonplace as it is today in the airbnbs and all the other gig economy companies of the world, where when you opened up that uber app and you saw these taxi cabs driving around, those were fake, but what the ux provided you was an affirmation that oh, they're everywhere and I've never used before, but I can see all around me that there are people inside of them.
Speaker 2:So therefore it must be safe, it must be convenient, because a reason that I'm using this app is A I don't want to talk to a dispatcher and B I don't want to stand on the side of the road with my arm in the air because it's embarrassing. And so Uber was wonderful with that little animation, alleviating two of the vulnerabilities that the consumers might have had in adopting what was a fairly new concept of a ride sharing service and that came with research and understanding of the user and providing of a good user experience. Even if it was fake when you open the app, it helped alleviate that adoption consider it adoption any of those barriers as well as sort of gave you affirmation that it was going to be more easier and convenient than a traditional way of doing things.
Speaker 1:I love these examples because you know, I think a lot of the people that work in the organizations that we deal with you know they get tools, they just use them right, whether they like them or not, they're not really thinking about this too much and they're just doing it because they're told to and it's their part of their jobs. But I love the iPhone example and the Uber example, but for me, iphone I just I can't help but think back to the Blackberry I had before my first iPhone and yeah, it was cool and everybody had that. But my gosh, like, that little keyboard was absolutely awful. It tried to, you know, it tried to mimic a small laptop, right, and it did a terrible job of doing such and so it was so easy for when the iPhone came in, that made such sense with that, that small size and and just the the user intuitiveness, you know, and the ease of operation. So it's such a great example for those who aren't familiar with this concept.
Speaker 2:And that keyboard was a huge barrier to adoption for many was they wanted a tactical sensation of typing. They couldn't imagine a virtual keyboard. But now I've got a couple of those sort of antique relics displayed in my living room of all of these technologies that either I'd burned through or just want to touch again Everything from the Visor Palm Pilot to the Blackberries and the Nokia Flip Bones of the world. But there was a sort of a day in which that was a concept that a lot of people weren't wanting to give up is that tactical keyboard, and I think the same thing is true with the technologies that are washing across our bow right now is that there's elements of trust and privacy and patience and curiosity that come in with adopting new tools, of which you must see on a daily basis, Brandy with change management and organizational design of who's willing to adapt and who wants to stay the way they are.
Speaker 1:You got it. I mean even me with small hands, or even my kids with small hands, like I think about any general man I've ever met like there's no, they're fat fingering those little tiny keyboards. But I agree with you, once we've gotten past what our bias is and open to new things, I think there's just lots of opportunity there. So that's kind of key to changing culture and things. So you know, how does tell me a little bit from your lens, like, how does user experience directly influence user adoption? Thinking about it from like a business perspective, when they've implemented a new software tool, it's rolled out within organizations. How does user experience affect adoption and the effectivity of the tool?
Speaker 2:I think that Uber example is a good one because it isolated the embarrassing part, or the frustrating part of what was traditionally a taxi service, where always the dispatchers weren't really good at understanding English or what you were trying to say, To have to call and negotiate with somebody and not have a clear understanding of how long it would take for a taxi cab to arrive at a desired pickup point. I remember there's a little story about my past. I remember when I was in college, you know, back before I knew how taxis work and I was late to the airport, as many college kids are, and I called three different taxi cab companies, all telling them to pick me up as soon as possible because I was going to miss my flight and all three everything into the ring at the same time and so those kinds of points of frustration. To go back to your question about user adoption is that the researcher would understand the visibility and transparency of how long it's actually going to take, which suggests that a service that can calculate it for you, at least give you a number to look at, is going to be a huge differentiator from a service that previously wasn't challenged. And I had mentioned those points of standing on the curb and waving your hands in the air, which is embarrassing because it says, hey, I need a ride, anybody please pick me up. And now to be able to do so from the privacy of your own device was a fairly transformational moment. I think that that analogy of ending the context for which it's being used in will help any business improve their experience.
Speaker 2:Another quick one I am old enough to remember when Snapchat first came out and it was a sort of culture gap for me when I first opened it, because it opened up to a camera and I wasn't used to a social media app opening to a take a picture, because I was just wanting to see what was there and sort of what. There was a feed or something, and it was a jarring experience. But what I would guess is that the researchers or the strategists, the product designers for Snapchat, what they did was they said you want to be able to take a picture as quickly as possible. Our lifeblood is in people sharing photos, so push this.
Speaker 2:As the very first experience and you can see an analogy is that with my, with my pixel, Android Pixel, if I double click the power button, it jumps into a camera, because life happens very quickly and if I want to take a picture of something again, kids are a very fast moving species If I want to take a picture of something, I don't have time to unlock the phone. Scroll through my home screen, find the photo app, open the photo app and take the picture. I want to be able to jump into that action extremely quickly so I don't miss the moment. And those kind of shortcuts aren't evident to everybody, but they're a good example of how there can be an element of frustration, of I missed the moment because I was fiddling around and I couldn't get into that execution very quickly. So those were two examples of how UX might lead to adoption.
Speaker 1:I love it. You know, I think before Ubers, you know, with the cabs, like you said, even someone like myself who I'm not super worried about being embarrassed but it's just feeling confident I'm not. I don't live in a big city, so when I do travel to a big city and now I have to hail a cab, like what Uber did was just eliminate all of the guesswork, right, and I feel in total control. I can see where the gentleman's coming or the woman's coming, I can see their face, I can see their car like I know what to look for, I know exactly where they're at and where they're going to show up. It just the experience is drastic and it's huge. So I love thinking about some of these things that we didn't even realize were poor experiences when we had them.
Speaker 2:When you travel abroad, the notion of how much does it take for me to get from A to B, and the language barriers in a different country. I, my wife and I, when we used to travel into Portofino, into the Italian Riviera, there, I remember one time we got hustled because the cab driver said something that we thought we heard, and when we got there the price was 4X and we're like, wow, okay, here's the money. We'll be walking home no-transcript.
Speaker 1:Yes, I love being able to feel like I'm empowered to make good decisions and even when it's really expensive because I'm in a big city, I still have options. I still can pick someone who's going to be here in three minutes as opposed to 15. And I can decide whether or not I want to save money or not. But it it makes me feel empowered. I love that feeling. So it's it works for me. Okay, very cool. So one of the recurring challenges that we see with our clients is we write and IPX helps this right. We help them with business processes, lead and tools follow. So we write and help people write formal configuration requirements and then. But what people don't know is what truly ends up feeling clunky or inefficient until they've gotten to the point where they're at user acceptance test or even after go live and it's kind of, in some light, seen as scope creep or new requirements. So, from your experience, how can organizations think about that up front? Is there anything we can do to help drive usability expectations early during that requirements gathering phase?
Speaker 2:I've come across this many times in my career, especially with large organizations, where a product is dead on arrival and how do you mitigate the risk so that all of the time and investment that has gone into that product makes sure that it sees the success that it was designed for? And I think that there's also this fallacy of that we are experiencing within our professional lives, that we can jump to the end much faster now that we have these tools at our fingertips that will improve the development, the design and the speed in which those occur. And if we're able to conduct user-centric activities with an admittance of, how would we think about this if we did have time savings in the back end, rather than saying, well, we can do it in half the time, so let's make half the timeline and we'll just rush to the end? An analogy I use a lot is electric bicycles, where these generative tools have given us this newfound feeling of speed and velocity and augmentation. And the danger is that you are on an electric bicycle and you are in 30 miles the wrong direction. Well, that speed and efficiency has just carried you further from the true north that you're trying to go to and now put you even further in the wrong direction. And so to save that time at the end of the development process, of the business process, to use these new tools to buy you time to do more strategy research is where we're going to see improved experiences and again mitigate the risk that everything we did up until that point.
Speaker 2:I spun up a landing page around this Sorry for the shameless plug, but it comes to mind and the URL is doa deadonarrivalgageio and it talks about all the different methods that one can do Prototyping. Again, prototyping is something that admits that you have an idea you want to put people in front of in this case, an application, whether it be mobile or desktop, or an experience, and that you're willing to iterate that prototype quickly so that by the time you get to the end deliverable, you've got everything locked down, it doesn't feel clunky, it feels intuitive and that it takes into account all the data in an elegant manner.
Speaker 1:I like that and I also think you know we all from a company perspective, you know we all talk about being agile. I think from an implementation perspective, I think it's really helpful to to not have that big bang approach right when the developer goes off and does a bunch of configuration and then comes back and says here, we've met the requirements. So how do we think about it? From an iterative fashion, where we're seeing snapshots of of capabilities throughout time, so that way we have some visibility throughout and we've already incorporated maybe a percentage of resources. We've scoped it in, not knowing exactly what this is yet, but we want to make sure that we're thinking about these things so as they come up. It's not saying well, that scope creep right, like we've met the requirement. Well, we didn't really know. You're always going to uncover requirements as you start to implement and use these solutions. So how do we make sure that we're thinking about that throughout, ahead of time and then as well, throughout the development of the project?
Speaker 2:Yeah, the good PMs build this in and you know, as a consultant, I come into contact with two or three a year with two or three different projects. And the ones that have that sense of time, have that sense of pressure of we need to launch this by this date, are the ones that often rush the strategy and the research and the conversations that need to occur and the requirements that need to generate from those conversations and, as I mentioned, there is going to be this time savings through the ability to generate engineering design deliverables at a very faster rate than we've ever experienced before. And so you used a good word allow for ourselves to take those inputs in and schedule and budget and resource them accordingly, so that the increased philosophy is met with informed decision-making process. And so I think that also goes into the curiosity of an organization to say, okay, how do we start to think about this in a new way? How do we bring in the honesty to say that we don't know everything, but we do have educated guesses and want to go confirm that before starting. That vulnerability from an organizational standpoint or a departmental standpoint is something that needs to be baked in to say, you know, we are this human-centric organization.
Speaker 2:Here in San Francisco there are a number of SaaS products, very small companies, series A, series B even Seed Round that, because they're so concerned with user adoption, within their onboarding process they will send a link into their CEO's calendar and I'm sure they've sort of guarded the time effectively so that you know there's not more than one or two a day or not more than a handful a week, but to be able to book time with a CEO or a founder of a product and communicate to them directly to say here's how you think I'm using it, but here's how I'm actually using it.
Speaker 2:It's failing on these measures, but here are ways that you never thought I was using it before. I try to adopt a lot of different tools into our process here and every time there is that link into a CEO's calendar to show them hey look, this is my interpretation, my evaluation and context of use, what do you think? And it's wonderful to see these companies, from an organizational standpoint, allowing for that input cycle to be constantly occurring so that the decision making that they're choosing of is this valuable direction to take my company into. Is this a loop? But that needs to be established and maintained as a constant feedback cycle, and that's healthy for any organization, whether it be Series A or Fortune 500.
Speaker 1:Yeah, I agree, and I think about user acceptance testing. You know, I know a lot of times organizations, you know they lean on their system integrator to do all the things because they say these are the capabilities that are included in this contract. And to me, when that happens and this is not against the system integrators they're there to get the project done and to meet the requirements. But what we see sometimes is that they've just included Happy Path. So they've, they've done this user acceptance test plan and it walks through exactly what the business process says and walks everyone through their roles in an ideal world. But in real life that's not always what people do. They're not always going to have their how to right next to them. They may go in and they're going to try to do different things. So to me, I think it's really important that organizations own their user acceptance test plan and try to think about it from I don't know if it's a misuse or just a, you know, like more of a off case kind of scenarios as well, and see what they can do to I don't want to say break it, but just, you know, to make sure that we're trying to think about these things so that way these things are caught now, as opposed to.
Speaker 1:You know, we typically use our acceptance test with the subject matter experts. Then, after it goes live, everybody's happy. The rest of the world then starts to use the tool. That's when you start to have issues. And you know, we've seen this where we call it. We've fed the organization food poisoning in some way, right, because now they don't want to use it. But the money's gone, the project's done.
Speaker 2:Tell me a little bit there about your perspective on user acceptance tests and how do we be better at that? I think it needs to be a constant cycle. It becomes not as the end point of a process but as an ongoing point of the process, where it's a voice of the customer program and it's not from a sales perspective but it is informing strategy and PMs as much as anybody else. And that feedback cycle can happen at conferences, it can happen through observed UAT testing on specific products and it can happen as an open invitation of come find my time on the calendar. The community of users will also help each other, and so to foster out forums and to be able to facilitate those who are the rock stars of your user community is a customer experience feedback cycle.
Speaker 2:We've seen UX get reappropriated into that CX term, where now're trying to really make it feel like you've made a choice, you've joined a community. We are fostering an open and it's not transactional where every time it's at the end of a sale or at the beginning of a sales cycle, but instead it's that a friend just calling to say how's it going or how are you using it, what's happening in your life, a friend just calling to say how's it going or how are you using it, what's happening in your life. That is good user experience because, again, you're absolutely keeping the conversation open for honest and vulnerable feedback to the product.
Speaker 1:So tell me a little bit about how can both sides maybe the from the vendor side and the client side collaborate better to avoid this scope creep label that comes. You know that are for things that are discovered late in the process and you know, typically we see, you know we're trying to get the best price, so we've negotiated these suppliers and vendors, system integrators, down as much as we can and that's why we've chosen them. So you know, from almost from both sides honestly vendors and the clients UX is kind of a nice to have and it's the way that we've set it up from design by negotiating down is that you know the nice to haves are probably not the things that are going to get prioritized. So how can we be better on both sides of this?
Speaker 2:So how are you? You've taken me to a dark place. Welcome to my world, where you have now identified the nice to have, and it goes back to this notion of aesthetics, or there's a misunderstanding of the importance of UX and the risk that's involved with not incorporating. And, as I referred to, there are organizations and representatives that see the value or don't see the value or care about the risk. And so, to look at the organizations that are known for good design and Apple at the time was this wonderful calling card I was like well, they are constantly rated as having the best design principles and the best UX and, again, at the time, the most valuable company in the world, and so it's hard to write that off as not being important or crucial to the lifecycle. It starts within product, where the VP of product or whomever is going through and making those decisions about how much to over or under engineer or how to prioritize what we do, and we don't know where those decision-making processes exist.
Speaker 2:That tends to be our sponsor. We want to make sure we bring in somebody that's able to extract information, emotions and voices and present it in an indifferent manner so it doesn't look like it's being accusatory of one department or the other, but is absolutely neutral in how I'm using this, how this is affecting me. And it's a great alignment exercise too, before kickoff of a project or before everything gets going to say, oh, we all see and hear the same thing. You know, there's no skin in one opinion or the other. We're presenting this out so that the team can be more efficient in a unified, true north goal together. So I know that answer wasn't direct. It really comes in seeing the value of mitigating your risk and increasing the likelihood that all this work will be well received and the product itself or the service itself will succeed.
Speaker 1:These tools are so expensive and licensing is so expensive and you know, I think we've pushed at IPX on the organizational change management side, as I said, that this is not a nice to have right Like. This needs to be its own project that runs in parallel it needs to not be an afterthought in order for this solution to be adopted, used and successful, efficient and effective for your business. All of the things that has been promised is pending on these things, and to me, user experience is no different. So how can organizations build that culture where user experience is not an afterthought, that it's a strategic part of what we're calling operational excellence right. How can we at IPX help these organizations see things differently? Excellence right. How can we at IPX help these organizations see things differently?
Speaker 2:Yeah, I mean show the horror stories. One of them comes to mind as you describe your engagement Adobe, a number of years ago, was looking at their auditing of the technology in place for their support team that would handle ticket requests overseas, and the notion of what the UX of their current solution was doing versus the reality of how that team would operate was a very stark difference. And this comes through process auditing and in-depth interviews and over-the-shoulder show me how you handle these kinds of workflows service design, customer journey blueprints but what was revealed is the number of workarounds due to the bad UX. They were fighting constraints of infrastructure and bandwidth, as well as the feature set that they thought they would use that didn't actually use it, and because data was being passed from one system to another, to another, to another and they were on the receiving end of trying to find out that customer information so that they could better handle the ticket. And the number of ancillary tools that this team was spinning up and using on their own, unofficially licensed, in order to fulfill the job that they were meant to do, showed that the UX of the tool that was provided for them they were meant to do showed that the UX of the tool that was provided for them was suffering, as well as the environment in which they were doing the work under was also needing a revamp. So those kinds of horror stories of the expected use versus the actual use are great illustrators of hey, here's why and how we need to improve Again.
Speaker 2:I'll go back to a young kid reference. For those of you listening at home. Jurassic Park is something that is popular somewhere with the release of the new movie and we were watching Jeff Goldblum in the original talking about human behavior or animal behavior, where you think you know how it's supposed to work, but there's this chaos theory of it will never behave how you think. And I think that software and humans using software is very similar to Isla Nubla, where they're going around in the carts and then the dinosaurs eat the people. That usage is what's worth illustrating as expected experience versus actual experience worth illustrating as expected experience versus actual experience. And how does that translate into our next product cycle of where do we start to guide experience so that we don't have to do the workarounds and the copy and paste and all of the error prone and redundant tasks that can have reverberations?
Speaker 2:I've come off of a financial services client where it was an internal team of about 12 people and the workflow was as such, where if there was a mistake made and they were making deals with other financial institutions, but if they made an error, you use the word fat finger but if there's a sort of a digit or a number off, the impact of that was in the tens of millions of dollars in remits that this financial services firm would have to pay the deal partner and then the cost not only involved with having to redo the entire deal but have it backed up was in such a high impact and that was 100% a user experience challenge of make it so that there's error validation happening earlier on that the contextual information of just enough data to be displayed on any one screen as not to overwhelm the end user so that they're not seeing everything they need to see from a legibility perspective.
Speaker 2:Those kinds of impacts are real and not just aesthetic or subjective but have a true financial cost to somebody getting their job done very easily and somebody flaming out.
Speaker 1:Yes, unfortunately, I think it's those examples of what are you missing by not including this? I don't know if it's a scare tactic, but I don't know how else to get that across is. Try to communicate those the food poisoning examples, right, that's. That's the only way, unless someone has lived this and done this, and then they're just terrified. They've had a really bad experience implementing something. It didn't go well, and then they're they're gun shy, moving forward instead of trying to take those lessons learned and work them in.
Speaker 1:So you know, I think we, I think the iPhone example and the Uber example. So you know, I think the iPhone example and the Uber example, those companies have spoiled us in some way, right. And so when we think about this from an organizational perspective, with big companies implementing tools like ERP or PLM or, you know, requirements management tools, things like that, I think we all expect, we all want a simple interface, right, like, in theory, we want this and we want user experience, but we assume that it's implemented by the developer in the out of the box tool. So that's why everyone wants out of the box, because we don't want to make things complicated, but we have very complex, heavy industries. So how do we what are? Are there any common myths about what people are expecting? They want this simple interface and a complex, process-heavy industry. How do we solve that?
Speaker 2:Yeah, lack of customization, where it is just this way because it's just this way To challenge that or to have an arrangement again. I know you work with large platforms for large organizations, but to work into the contract is that there's this sort of ongoing iteration of our workflow process is not going to be similar to every other customer you have and you're going to sell us something. But we're also going to have a professional services agreement built into this so that you can contextualize different steps along the way. We'll help provide you requirements for that. We'll give you the research and the insight for why this should be in this manner or this should be in this manner.
Speaker 2:But what we don't want to do is start to create noise in which drags down our internal team or our external users where it's not quite right for them and we're trying to fit a square peg into a round hole, and that, I think, is, from an organizational standpoint, just a call sign to say, look, we have to choose something that is again a large enterprise solution.
Speaker 2:But what we want is to make sure that you will work with us to help it meet our specific needs and that, if it doesn't, or if we see that these workarounds are happening again. In this case, it was a lot of sort of going into other documents and pasting data back and forth things that should have been propagated within the platform itself, communication tools through other channels that weren't being used, and forth things that should have been propagated within the platform itself, communication tools through other channels that weren't being used, because the UX of the chat apps inside the platform was insufficient to refer back to what was happening in real time. And so to have that professional services engagement with the company, to say that you will customize these things or help us make it better for our team, I think is an admittance that it is an ongoing process, so it's not a one-time transaction, is experience, and it is that workflow, that flow state that we hope to achieve.
Speaker 1:You said. One thing that I wanted to just discuss a little bit more in detail is the copy-paste right, data copy-paste. And you know, sometimes we think of user experiences as focused at a developer or one tool, and I really want to change perception that we need to own it as someone who's the user side, the business side, and because we need to think about this from an enterprise perspective, that user experience is the digital threat as well. Right, it's end to end and that has to do a lot with our tools also being connected and having the single source of truth and the data being edited in the source of truth and also then shared amongst tools. To me, that is also user experience, would you agree?
Speaker 2:Yeah, your analogy rings true.
Speaker 2:I had a conversation with somebody at a large IT services company yesterday and she had mentioned that a new CEO had come forward and was told that here's the Salesforce numbers and here are the real numbers, numbers, and here are the real numbers. Yes, see, it goes like we can't do this. Those numbers have to be the real numbers and that's it. There can't be multiple sources of truth. There has to be a single source of truth, and copy and pasting is an evidence that integration isn't working. Is that this system isn't talking to this system or we haven't added a bridge in place to remove that manual process of redundant tasks and I know there are tools out there coming onto the market very quickly that will do that for us and hopefully eliminate those jobs or those parts of our jobs, because they are so error prone and also a high cognitive load is to do that repeatedly, all day, of data entry and transfer, manual transfer of data from one system or platform to another, when this is what we should be paying for is to improve that kind of efficiency.
Speaker 1:Yes, and I think that's the minutia that takes over people's lives at work on a day-to-day basis. If we could actually estimate that and capture that, it's an activity that should be done. Reducing and eliminating some of that minutiae, I think, is key, and it's about you know making your resources that are already stretched thin, you know actually doing the value-added tasks that they were hired to perform, as opposed to some of this minutiae, right. So, which brings me into you know one. I'd like to just touch base on AI here for a second, as we're talking about that and you know, maybe tell me a little bit about your brain on AI, of how maybe it's you know, low-code, no-code platforms or whatever it may be, or just AI in general. How is this changing the UX dynamic in enterprise software?
Speaker 2:Yeah, I consider myself lucky to have been around long enough to have seen cycles like this in the past, and there was the initial wave of digital transformation that was going to eliminate pen and paper and fax machines and make everything now in spreadsheets and word documents. And there were those who accepted digital transformation at that first stage and those who resisted against it, and some of those are the most charming, uh, and intimate restaurants and store owners that you can imagine, where everything is written down.
Speaker 2:Oh yeah, they're cute, but in terms of my life and my work I was one of the first generations to come into were designing for didn't need to be constrained in the 640 by 480 desktop screen at the time. Now there was this mobile device in which our context had to shift how we were designing for and I know that's a separate sort of line of thought in terms of UX, specifically because the waves of transformation are even larger. Because, as the cloud became industry standard in maybe 2010, 2015, there were those who didn't trust it, who wanted to see the icon on the desktop, on the hard drive, because they may have had a bad experience with losing data in an early instance of the cloud, and they still stay within spreadsheet applications to do tasks that there are, for example, crms or hour tracking or things like that. That's not or budgeting or invoicing and their familiarity was with on-prem or on-laptop solutions and didn't ever make that to cloud-based because of issues around privacy, of trust, reliability, and I think those three emotions are now going into the privacy, the trust, the reliability of the information that these generative services are giving us. So, to answer your question more directly, brandy, it is a huge deal about what it is.
Speaker 2:I do because one of the things that the algorithms are good at are establishing patterns, and design is a lot about standards and patterns, just as engineering and code is functions and formulas, and we've had these tools that have been trained on our last 10 years of work of designing patterns and principles and organizations, and now, with the snap of your fingers, you can reference and recreate all of that, and so it brings into the question of where is that value of design now If it's not in the interface?
Speaker 2:Now it's in the experience, and so we'll start to find more of an emphasis on help me give some understanding about what it is. I can design and develop even faster, but help me give some understanding of what it is I should design and what kind of emotions do those refer to? Because I don't think our algorithm is quite there yet to really have that. When somebody stands on the curb and puts their hand in the air, that's a humiliating experience for them. That's something that you and I have shared experiences on, and that we can help guide those types of decisions early on in the strategy process.
Speaker 1:Yeah, you know, like you said, like waving your hand for the cab is embarrassing. So Uber eliminated pain. Now, when we think about this from an organizational perspective or a cultural perspective, you're trying to automate the minutiae that people are comfortable with. So, instead of eliminating pain, you may be eliminating pain for the organization, but for the user you're taking away their safety blanket right of the ways that they've always done things. So it's a different challenge.
Speaker 2:It's true from an organization perspective. We talked about UX a lot. I think EX the employee experience is just as important. We're going to see this adoption of AI tools as a core competency within the workplace. Just as somebody has to be good at email, somebody has to be good at file management, somebody has to be good at understanding where the algorithm should and should not come into play. The first time you get an automated reply which is clearly a generated email from somebody that you know, you're kind of an eye roller like, couldn't you have taken the time to actually write that, rather than click the button and do a pseudo voice, something written in your voice but not actually by you? I think that that literacy of where the algorithms will help us and where it will hinder us or just is not appropriate is going to be a competency within the workplace. It's going to be extremely important over the next couple of years.
Speaker 1:So I guess, just kind of closing our discussion today, if you could give one piece of advice to anyone or any organization planning a digital tool implementation today any words of wisdom from your perspective of what could it be to ensure user adoption?
Speaker 2:Yeah, I'm going to again apply DOAgaugeio. I want to mitigate the risk of having gone through these processes and user adoption starts to fail to allow for the saved time. You'll, or should, hear from your design and development teams on the back end of implementation to really emphasize what kind of feedback cycles can we establish before we begin To start with the? How might we, before we pick up our pencils and pens and begin to draw I think that's going to be increasingly important because the velocity is going to allow us to make worse decisions even faster. And then the same thing is true with the backend is to have this feedback cycle and envision how, when we design this as an experience, not just as a product how to incorporate feedback loops so that we can iterate.
Speaker 2:And it's not a two-week period at the end of development to say we're going to do UAT testing and that's no, it's going to be something that's an ongoing. Part of our organization, of our ethos, is to really connect with that human experience, because that's what's not going to get left behind from the algorithm. That kind of voice and opinion, a conversation like this go a long way, and thank you again for having me. Voice and opinion Conversations like this go a long way, and thank you again for having me, because I think that's going to be again one of the important parts about what it is we do is our ability to interpret and communicate human experiences.
Speaker 1:Yes, I agree, I think so many times we think, hey, you know it's people's jobs, we're going to give them a tool, they're going to use it. It's just is the way it is. You know, do it, do your job. But I think just being mindful and intentional about success of the project after the fact, I think is is just important. That's the recommendation today. So this has been super fun for me, nick. It's a it's an interesting discussion and you know it's things that we come into contact with. You know almost on every project in some light, and you know it's things that we come into contact with. You know almost on every project in some light. And so I just want to thank you so much for joining us today and I just want to give you a minute, you know, to give yourself those humble plugs. So where can listeners learn more about you, the work that you do, and about Gage?
Speaker 2:Yeah, for those of you who are in the product or design industry, I'm doing a maturity assessment for the community or design industry. I'm doing a maturity assessment for the community. I will start to report back any kind of segmentation or factor analysis as I see more and more results come in, and you can find that at retraingaugeio. I do have some concerns about my fellow designers and what will happen when we get automated, and so I want to be able to nurture and grow awareness of what tools and constraints might be out there. So that's retraingaugeio. I think I name dropped the doagaugeio, the dead on arrival of what happens when you're within this large sort of enterprise design and acceptance cycle. It's like how do you start to mitigate the risks of something, um, becoming DOA, uh, and so you could find that there, or else just find me on LinkedIn and I'd love to start the conversation and figure out what you're working on and how I might be of help.
Speaker 1:I love it. So you know, uh, we talked a lot about requirements gathering and everything today. You know, I guess, uh, just just to remind everybody, requirements gathering is not brainstorming in Word and it's not pulling everyone together in a room and talking about previous tools and what they want in the future tools. So business processes really do need to lead and tools need to follow and be implemented to automate those processes in a proper way. So IPX does that and Nick does that, so we'd be happy to help with any advice anyone needs as they're approaching the next digital transformation within their business. All right, thanks to everyone so much, and we'll talk to you guys next time. Thank you for tuning in today. Don't forget to subscribe and review the show and for more information on IPX, visit IPXHQcom.