AI vs User Experience: The Battle for Better UX Design

Discover why most AI implementations fail from a user experience perspective in this revealing conversation with UX design expert Makoto Kern, founder of IIIMPACT. Learn how companies are repeating the same mistakes from the dot-com era by prioritizing flashy AI features over actual user needs, and why user-centered design remains your competitive moat in an AI-driven world.

Makoto shares insider stories from major enterprise clients, revealing how proper UX strategy can turn around failing products. From oil and gas software to robotics interfaces, discover the critical alignment process that prevents costly product failures and accelerates time-to-market with less risk.

Resources from this episode:

• Connect with Makoto: https://www.linkedin.com/in/productuxdesigner/
• Learn more about IIIMPACT: https://www.iiimpact.io/

Listen to the Episode

Watch the Episode

Transcript

James: Hi everyone, this is James from the Control+ Listen podcast. Thank you for tuning in. We have a special guest for you. This is Makoto Karn, founder of IIImpact. Thank you so much for joining us today. Great to have you on the show.

Makoto: Thanks, James. Happy to be on the show and excited to talk about our topics today.

James: Definitely. I think we have some really interesting stuff to talk about, and a lot of it is very on point for the current climate in the tech space. To start, before we get into all of that, can you talk us through the history of IIImpact and your background?

Makoto: Sure. I started as an electrical engineer and robotics engineer. That’s what I went to school for and trained for. I got into redesigning software when I was working in the manufacturing space, because that’s where you see a lot of engineers building software for other engineers, but not really for people on the factory floor.

My job was to tweak things and make them more efficient. That’s where I was introduced to how the user actually works with software. With IIImpact, I started to get involved with designing websites. I was on Craigslist finding projects, and I got to a point where I was so busy that I decided to quit my job and start IIImpact full-time, which was crazy.

During lunch breaks, on the way to work, and on the way home, I was making sales calls and really hustling. It was an interesting time. I was consulting, running my business, and from there it just grew. We grew out of Chicago and then moved to Austin, and that’s where my business really blew up.

I started networking with a lot of people in Houston and got one of my first biggest clients there. That’s where we were introduced to the energy space. We’ve been doing a lot of enterprise software ever since.

I still remember our startup client from 10 years ago. They had to redesign 30 software applications for the oil and gas industry. I was competing against another UX agency that I was actually following and looking up to, hearing about all their work. It was exciting, but I thought, “There’s no way I’m going to beat them.”

They ended up getting acquired by Capital One. So I told the VP of Product, “Look, I’ll be here whenever you need me. We’ll take ownership of whatever you do. You have to trust me.” I was sitting in front of all the executives. They were showing me the software and asking questions.

I said, “You’re talking about UI stuff. UX is something deeper. Maybe the software or interface doesn’t change. Maybe it’s something else. You have to understand the users. There’s a different process involved versus something that’s just visual.”

From there, we’ve been on the Inc. 5000 three years in a row. We’ve helped Fortune 500 companies and startups. It’s been great because we’ve seen the evolution from the dot-com boom to the dot-com bust and then the focus on user experience.

We’re seeing the same thing happen now with AI. We’re really trying to push companies to become user-centered instead of feature-centered. That’s your moat. We try to give our clients a cheat code to get from boardroom to code faster, with less risk, de-risking things and getting there faster and better.

That’s our story. We’ve got a pretty big team. We were at 50 at one point; right now we’re around 30–35 people. We’ve got UX, product strategy, and front-end development.

James: I love that story of the underdog overcoming the Goliath. Honestly, if you’re a company that can provide really dedicated service, sometimes it’s better to hire someone like that than a massive conglomerate, because you get that attention.

Makoto: Yeah. I’ve worked with and consulted for the big dogs—Accentra, Deote. I’ve got people on my team who worked for McKenzie. They all come in with big numbers, and there’s a big spectrum of what you might get. It’s like a box of chocolates with those guys.

You kind of know what you’re getting with McKenzie, but with Accentra and Deote it could be a mix. I know people who have been on those teams who are phenomenal, but I’ve also been on teams that are 10 years behind—and the client is paying the maximum amount you should be paying.

With us, we call ourselves the “mini McKenzie,” but we take ownership of what we recommend and we stick by it. That’s why a lot of our engagements are multi-year, and clients see the value.

James: Talking about what you offer, can you walk us through some of your offerings?

Makoto: Sure. Number one is product strategy and UX design. Everything to do with the front end is our sweet spot.

The product strategy piece isn’t just planning features. It’s preventing the wrong features from being built. Most companies want to jump straight into wireframes and development. They think that’s the fastest way to get there. When I see that, I know it’s an immature company.

Most companies don’t communicate and they’re misaligned. That product strategy piece is so important. That’s where we tie in business goals and objectives. It’s almost like therapy. Managing people is much harder than doing the design work. You’ve got a lot of egos in the room, and you have to put them in their place and say, “What is the strategy? Everyone’s not aligned.”

We align that with who your users are and what their pain points are, and from there we create a roadmap for six to 12 months so they know:

• These are the features.

• These are risky features; we’d better test them before we spend a ton of money.

• These other features we can start designing right away.

We create that process. At the same time, with UX design, our designers know exactly what questions to ask and what to build. Most of the time UX designers are going from one SME to another, and by the time it gets to the HIPPO—the highest paid person in the room—they say, “No, I want to do this,” and now you start over.

That process normally takes months and costs a lot of money, and what you get at the end is different from what everyone thought. Our process is to get leaders aligned, then be part of UX design and set up success through design systems and things that scale, and then hand off to our front-end team that understands the tech.

We can design the best thing, but if we hand off—like a lot of companies do—to the dev team and say, “We’re done,” dev will look at it and say, “We can’t build this. It’ll cost 100 hours. Let’s change it to something else that will take five hours,” and that hurts the user experience. There’s no communication.

Following that process all the way through and then testing is the whole gamut of what you need to do as a consulting company. That’s when you see a really mature company: when they have all that in place. It’s hard to have all that, especially when you have legacy software, one product you’ve had for the last five or ten years, and now you have to redesign and do something new. They’re not equipped.

James: So it’s a holistic approach, is what you’re saying.

Makoto: Yeah. And that’s where people drop the ball. They divide it into segments instead of looking at it all the way through as one collective effort.

To champion change from the bottom up is nearly impossible. You have to do it from the top down. It’s an art to talk to the executive team, get them to trust you, and then move forward.

We have to shift the mindset: what we do is not a commodity. It’s not a race to the bottom. If you want to race to the bottom, great, but we’re not for you.

Especially now with AI, everything is faster. You can copy things faster, you can compete faster. So you’d better start iterating faster ahead of your competitors; otherwise you’ll be left behind.

James: Talking through the process itself, what does the redesign process actually look like?

Makoto: Most projects—or a high percentage—fail because everyone wants to jump to wireframes. To put it simply, if you’re going to build a house and you build a three-bedroom, four-bathroom house without talking to the people living in it, do you think they’ll be happy? Probably not.

So what do you do first? That’s where we start with what we call our strategic immersion process. We force alignment before we touch any design, and we do that with leadership.

Once we get that squared away, we do a reality check: “What’s broken?” Not what you think is broken—we want to tell you exactly what’s broken, what’s not working, what the pain points are, what’s not being solved.

From there, we create a risk-based roadmap, because some features have high potential return but also a very high level of effort. If you start building those and only discover after launch that users don’t want them, it’s too late.

You can spin up a prototype quickly and talk to users, but every step can be done wrong. People fall back on a poor process that was thought up 10 years ago. They’ll present designs in front of users in a big group. The squeaky wheel gets the grease. You get feedback that isn’t targeted.

You want: “Pretend you’re doing this task and walk me through it.” Instead, the highest paid person in the room says, “This is what we want,” but it’s not what the users want. You have to be very intentional in how you test.

We see a lot of times that whoever is paying the biggest invoice has too much say, and that becomes a problem down the line. It’s not scalable.

After that, we move into wireframes and traditional UX testing, but now we’re informed and seeing how everything aligns. When you have multiple ideas, you can ask, “How does this relate to our business goals? How does this relate to users’ pain points?” It’s an easier conversation.

Then you hand off to development. Even after handoff, there’s something people don’t realize: we need to make design go from subjective to objective. You do that through metrics and constantly checking them.

For B2C you want to see conversion rates, where people are dropping off. Even in enterprise you still want to check things like time on task, how long it takes people to learn, NPS scores—those are very important. You have to be data-driven.

That’s how our process works.

James: It kind of makes me think of that expression “Can’t see the forest for the trees.” You’re too deep into it from the company side to see what the issues are, too invested.

Based on that, what is a common issue in the UX space that companies overlook?

Makoto: If you’re hyper-focused only on the user, that’s an issue. About 10 years ago, when I was getting into more of the design work, especially in enterprise, designers were so user-focused that they ignored the business.

You can’t be only user-focused. That’s why you saw the rise of the product owner. The product owner has to view things from the business side, the dev side, and the UX side.

I’ve always looked at it that way, so I naturally became a product designer rather than just a UX designer. Companies think UX is just about the user, but it’s actually about your business outcomes as well.

Stakeholder misalignment masquerades as UX problems. People build features users never asked for because no one validated assumptions. We’ve had SMEs who did the job for two decades and then started working for a software company. They have a lot of assumptions.

When we got in front of actual users doing the job now, a lot of those assumptions were wrong. You lean on someone’s expertise thinking they know exactly what’s happening, but day-to-day reality is different. You have to get that right, especially if it’s going to cost hundreds of thousands of dollars and six months of time to build something.

Another issue is confusing modern-looking design with effective design. Most UX problems aren’t UX problems; they’re strategy problems in disguise.

James: When I was looking through your site, I saw some of the spaces you’re working in. There were three I found really interesting: robotics, energy, and logistics. Do you want to talk us through some of your work in those spaces?

Makoto: For sure. We’ve designed things for one of the biggest companies in the world, Slumberge. They have situations where people in the field work with these interfaces, and some of it can be life-threatening.

If they’re fracking and something’s happening with the pressure, they have to see it and notice something is wrong. Feedback from those users is crucial.

There are also people in the office—executives—looking at this. So there are different use cases for the software we build for them. It’s awesome to be in those big companies because you see how siloed they are. They have huge design teams and huge development teams, but nobody talks to anybody. They move very slowly.

When we get in there, I just want to move. I want to get things going and show them, “This is how you do it right,” instead of just pushing through red tape.

Working with smaller, more nimble companies, maybe in the 50 to 200 range, is different. Our biggest and longest client has been with us for 10 years. They build energy software for renewables and oil and gas. We’ve worked on everything from upstream and midstream to downstream across the entire oil and gas process.

With robotics, it’s always a serendipitous thing for me because that’s what I studied for my master’s. We worked with Yasakawa, who are number three in the world.

That was an amazing experience when they reached out. They had tried to work with a different UX design firm. I call their old teach pendant the “Blackberry” of teach pendants: a massive device you use to program robots, with tons of buttons and a tiny screen, super complex.

Their robots can do a thousand times more than one of their competitors, but their competitors were killing them because it was so easy to set up their robots—you could do it within a day. With Yasakawa, it took a month of training and was complex.

That’s a typical case where it doesn’t matter how many features you have; it’s about how easy the interface is. For robotics, the core problem is usually, “Let’s get this manufacturing line up as quickly as possible so we can start producing.” They didn’t solve that. They thought more features were what users wanted.

Those are two areas I always love to get into.

James: You see that a lot in electronics spaces. People will often choose the simpler one to use and learn because they don’t need some of those extra features. Some people need them, but the average user may not consider them when deciding what to buy.

Makoto: Yeah. And I can tell you, with any kind of tech disruption, when you see Product under a CTO, that’s immediately the wrong structure. Product and UX should each have a seat at the table.

Dev wants to get things out. They want to build features and put everything in front of everybody at once because they’re proud of it. That’s great, but you need the opposite mindset in the room: “We have to make it easy. Cognitive load has to be low. Friction has to be low.”

If everything is under one technical lead who isn’t user-focused, they’ll naturally be feature-focused.

James: Another thing I’ve noticed is that within every industry there’s been a lot of change in how things are done. In the product release space, what do you think has changed the most in recent years, and why are traditional methods not working as well as they used to?

Makoto: We’re watching history repeat itself from the dot-com era. Everybody was drunk on the idea that if you had a website, made it look like Craigslist/eBay, or added “.com” to your name, you’d make millions. They forgot about the user.

Same thing now with AI. I see clients saying, “We need to do this with AI,” but the pattern is the same. Back then it was, “I need a website,” and the website looked terrible. That was 1999.

Between 2000 and 2007–2008, you had the crash, but then a focus on usability and user-centered design. Apple really pushed that. Steve Jobs was a natural at thinking about the user experience. It wasn’t just the interface; it was everything from when you get the box shipped to you, how you open it, how it’s packaged—everything.

After 2007, you had Google and Amazon reducing friction—things like the “one-click buy” button. Companies mastered the digital space with websites and apps.

Now it’s, “We need AI,” and they’re building terrible AI experiences. We’re seeing the same thing again. Companies are forgetting users’ needs. They’re building impressive AI demos with horrible real-world usability.

Everyone is adding AI features to their product, but analytics show users try a couple of prompts and then go back to what they were already doing.

James: Me personally, I’ve had a few issues with AI assistants as well. A lot of companies are using them, and the experience hasn’t been as fine-tuned as it should be before rollout.

Makoto: For sure. You’re seeing a lot of wrappers. Wrappers are fine, but as soon as OpenAI or someone else improves theirs, your business might be out of business. You have to do more than just create a wrapper that can be copied in two weeks.

James: Changing gears slightly, I saw a term on your site that I found really interesting: dev team augmentation. What exactly does that mean, and why is that so necessary in today’s market?

Makoto: It’s a term that I think appeals to the customer visiting my site. If they need help or more horsepower, we offer that. Dev augmentation or design augmentation is more hands-on work versus strategic.

It’s a revenue generator: you’re adding billable people. But if you’re thrown into a team with bad processes, it doesn’t matter. You need people, processes, and product—that’s what makes a company successful. If you have horrible processes and you throw good people into them, they’ll still suffer.

Even though I say that, my tech lead always says, “You can’t make a baby with nine people in one month.”

We’d rather add expertise than extra bodies. We want to solve the problems that created the capacity issue in the first place. You want to understand the knowledge and transfer it.

If you need augmentation, your real problem usually isn’t resources; it’s process.

James: I’ve seen that at a lot of companies I’ve worked at as well. It’s the wrong approach, and they’re just not understanding that.

Moving to something different again: what do people miss in the timeline and strategy part of the release process? That should be at the very start, but it isn’t always.

Makoto: Everyone wants to focus on speed, but the real problem is starting with the wrong assumption. You want speed and direction—especially now, when everyone can copy what you’re doing so fast.

You need alignment with leadership and your teams before you execute. You have to validate before you start building, and you have to understand the cost of being wrong.

I’ve seen people stop work on the main features we’ve proven users want so they can say, “Let’s integrate co-pilot.” That’s not what users want.

Fast execution with the wrong strategy is worse than slow execution of the right strategy. But everybody optimizes for speed.

James: I think they don’t think about the fact they’ll have to come back at the end and redesign everything anyway when they find out people don’t like it after launch. Was it worth it?

Makoto: Exactly.

James: Is there any chance you could share some client stories where you’ve really helped a company turn things around?

Makoto: All of them. We turn everything around.

James: That’s great to hear.

Makoto: I mentioned one earlier—competing against the other UX agency. But back to robotics, I love that story because it was serendipitous.

Yasakawa reached out to us. We saw their robots and what they could do. People in this industry think they can hire any agency and get the same result, and they realize there are very different ways agencies approach things.

Especially when it’s hardware and software combined, and something this complex. If you hire a traditional UX agency, they’ll make pretty visuals, but there’s no way they can deep-dive into this without understanding robotics.

Within six months we implemented our process. I was there recording how a robot picks and places things, how it works, how they program it, what people see. You’re taking something with tons of physical buttons and turning it into a touchscreen interface.

It was a big leap, but they wanted to compete with other companies that were super easy to set up—very quick with low cognitive load per screen.

They were wide open to our suggestions. They saw me there a lot, videotaping, recording, and then showing, “This is why we’re doing this.”

They redesigned and launched. If you go on their site and see their teach pendant, that’s the exact design we helped with. They presented it at South by Southwest, which is crazy. They said it was amazing.

Those kinds of stories we love to see—our clients’ success.

James: That’s great. Moving away from your company specifically, I’d like to talk a bit about the industry and trends in the space you operate in.

AI has come up a few times and it’s going to, because everyone is talking about AI right now. What do you see as AI’s role in the product release process? Where should that be implemented?

Makoto: I’ve made a lot of posts on LinkedIn about this. Everyone is posting, “Make millions or $100,000 per month with AI agents and automation. It’s saving me this much time.”

Again, the back end doesn’t matter. Nobody cares about the back end as long as it works. It’s like the browser battles—AOL, Netscape, Safari, Google Chrome. Who came out the winner? Google is one of the most used because it’s easiest and has the best results. Who cares what’s happening in the back end?

For me as a user, I want outcomes. Companies are hypnotized by AI and what it can do. There’s definitely a force multiplier with AI that can help. I use it all the time to crunch data and work through ideas. I’m not great at writing, so it improves my thought process. I’ll jot things down or record audio and it refines those ideas with me.

But that’s through my experience. I know the process in my head of how I go from idea to code, so for me it’s a force multiplier.

If I’m prompting it to design an app, it’s still better for me to sketch, figure out what I need to build for the user, define pain points, do all the upfront work, then sketch and wireframe. I can do that faster and more efficiently than prompting for hours. It’s not there yet.

For a login screen, sure—that’s easy. There’s a standard way we know that works, and AI can handle that.

From a development standpoint, I’m seeing the same thing. There are certain tasks where it helps with code and checks things. For other tasks, it’s slower, less efficient, or wrong.

If you’re not aware of that and you hire a bunch of junior devs who aren’t that good and they’re all using the same AI-generated code or vibe coding, that’s a problem. We have cybersecurity clients who are like the guy in the meme hiding behind the tree licking his lips, waiting for hacks to happen. There are glaring holes. There will be privacy issues and security issues.

So I still believe the moat is doing your user research and really thinking about the front end. That’s what will help you build a moat to separate yourself from everyone else.

James: I love that approach because a lot of people haven’t discussed the risks and negatives. They focus on the opportunity. I like hearing the other viewpoint. Thank you.

Another thing I wanted to discuss is global events—COVID, regional conflicts, tariffs. Have those impacted the product release process in any major way?

Makoto: Not directly. With COVID, I’ve always had to compete globally. You can offshore your work. There are different levels of expertise you get.

Remote work accelerated that. I was the busiest during COVID because my entire team was already remote. We were equipped to handle all our clients’ needs, and we blew up during COVID. We hit huge revenue jumps and massive project jumps because we were ready for it.

I’d been running remote teams for 10 years and knew how to do it. Communication is huge when you work remotely.

With macro conditions, there’s uncertainty about what will happen. People look for ways to be more efficient and cut costs. That goes back to communication. The more spread-out your teams are, the more hyper-focused you have to be on communicating.

I always tell my team, “Let’s over-communicate.” It doesn’t have to mean more meetings. It can be fewer documents and more, “Let’s get on a quick call and talk this through.” Conversations over documentation.

Macroeconomic pressures scare people away from innovation. They pull back and say, “We’re not sure where this is going. Too risky right now.”

The problem is, with AI, if you hold back on innovation and your competitor doesn’t, they’ll launch past you very quickly. If you’re hyper-focused on how you innovate and do it right, you won’t waste as much money.

If you hit the brakes on innovation and stop improving, and just do the status quo—watching competitors and copying them—you’ll always be one step behind. Companies have to pivot their thinking and ask, “How do we get rid of waste in our process and focus on what matters?”

James: That makes total sense to me. We’re coming up on time. I have one more thing I wanted to discuss, and I think you’ll have a strong opinion.

UX—user experience—do you find that in the last few years it has become much more in the foreground as a key metric for success?

Makoto: With mature companies, yes. For sure.

But on the flip side, I’ve seen it become more of a commodity. They’ll say, “We just need wireframes.” That immediately tells me something is wrong. They’re falling back into bad habits from 20 years ago: “Give me wireframes at the end of the process. Just make it look pretty. Give me less clicks.”

Less clicks doesn’t mean a better experience; it just means less clicks. Maybe it’s a form with 50 fields on one page. Yes, fewer clicks to other pages, but that’s overwhelming and people will drop off.

There’s more awareness of UX, but also more of the wrong approach: “We need it, but just throw it in at the end.”

James: For me personally as a user, the one thing that really puts me off—and I’ve seen this more frequently in the last few years—is how navigable a website is. If I have to really look to find a basic contact form or basic information, I’m going to look somewhere else.

Makoto: Our patience runs out much faster now because we know what to expect.

James: Exactly. And there’s so much competition. You know that if one company can’t provide it, there’ll be others you can find in seconds. If they’re easy to navigate and use, you’ll go with them.

Makoto: Exactly. Pain and price are two important things in user experience. If you don’t solve those, forget it.

James: Exactly. That brings us to time. One more question: if people want to get in touch or see what you’re offering, what are the best places to do that?

Makoto: We actually have a podcast ourselves. It’s blown up. I think we just hit about 24,000 subscribers. It’s called Make an IIImpact Podcast. We talk about AI, UX, things like that. Check that out.

Visit our website at www.iiimpact.io. You can reach me there. I’m on all the social networks and on LinkedIn. Reach out. I always love hearing about people’s projects, seeing where they’re at, and making an assessment—whether it’s something we can help with or maybe not.

This has been great. I love these types of podcasts. This has been awesome. I appreciate you having me on.

James: Thank you. It’s been fascinating talking with you. Really appreciate it. Maybe come back another time—there’s a lot to talk about.