Perspective
On AI and UX — where I stand.
Twenty years of designing complex systems has taught me one thing clearly: the hardest part of UX has never been the design. It’s been the understanding that makes good design possible.
UX and UI are not the same thing.
You’ll see it everywhere — “UI/UX designer,” “looking for a UI/UX resource,” job postings that treat the two as interchangeable shorthand for “someone who makes screens.” They’re not the same thing. And the order matters.
UX is the work that happens before anyone draws a single pixel. Understanding the users — their roles, their mental models, their workflows, and what they actually need to accomplish in what sequence. Mapping the information architecture. Designing the interaction logic. Defining what the system communicates at every decision point. UX is the vision, the structure, and the reasoning behind every design decision.
UI is the implementation of that vision — the visual language, the component design, the front-end execution that brings the structure to life. It requires real skill. Good UI designers are valuable. But UI without UX is styling a building before you’ve drawn the floor plan.
When organizations collapse the two into a single role — which is often reasonable, especially in smaller teams — the order of the abbreviation still matters. UX/UI is correct because it reflects the actual sequence: understand the problem first, then design the solution. “UI/UX” inverts that. It implies the visual layer comes before the understanding. It doesn’t. It can’t.
I’ve spent 20 years doing the UX part — the research, the facilitation, the architecture, the workflow logic — the work that makes the UI make sense. When I hear “UI/UX,” I notice. It’s a small thing, but it signals something about how an organization thinks about design. And that signal matters when you’re deciding whether a team is going to do this right.
AI didn’t change what UX is. It clarified it.
A lot of people assumed UX was about making things look good. If that were true, AI would have replaced designers already. It hasn’t, and it won’t — because the work that actually matters in UX happens before anyone opens a design tool.
Understanding the domain. Running workshops with the people who actually use the system. Learning what they’re trying to accomplish, what data they need, how their real workflow moves. Navigating stakeholder dynamics, compliance constraints, and implementation realities. Knowing when a developer’s “no” is actually a “not the way you phrased it” — and having the technical fluency to push back constructively.
AI cannot do any of that. What it can do is accelerate — and significantly — once that foundational work is done.
The honest case for AI in design work.
Once you’ve done the hard work of understanding the problem deeply — the users, the domain, the constraints — AI becomes a genuine force multiplier. Concept generation that used to take days now takes hours. Design iteration across multiple variants is faster. Getting clean front-end code scaffolded for developers is dramatically more efficient. In the hands of someone who knows what they’re building and why, AI makes the work better and faster.
In the hands of someone who doesn’t? It just produces bad work at higher velocity.
That’s not a criticism of the tools. It’s an accurate description of the prerequisite. The expertise, domain understanding, and judgment that make AI useful in design contexts — that’s the job. And it’s not going anywhere.
A prototype is not a UX.
AI design tools have arrived — and some of them are genuinely impressive. Tools that can read your design system, connect to your data layer, and generate a clickable, working prototype from a handful of prompts. The reaction in some circles has been predictable: PMs don’t need to open Figma anymore. Just describe what you want and ship what comes back.
This misunderstands what UX is.
Generating a prototype is an output. UX is everything that has to happen before you have something worth generating. Who are the actual users — not as a monolith, but in their specific roles? The admin managing configuration. The manager reviewing team workload. The end user processing transactions under time pressure. The junior user doing their first reconciliation. Each of them has a different mental model, a different starting context, and a different definition of whether this worked.
In complex enterprise domains, the underlying logic is the work. What data does each role need, and when? What actions should be available at each stage — and which ones should be withheld until the right conditions are met? What does the system need to communicate at each decision point so the user knows where they are and what to do next? Where does the workflow branch, and what should each branch feel like?
An AI design tool can generate screens that look reasonable. It cannot generate that understanding. And without that understanding, you haven’t done UX — you’ve done fast assumption documentation.
The discipline is unchanged: research the users, understand the domain, facilitate the right conversations, map the real workflow. What changes is that once you have that understanding, you can direct AI design tools with precision — and produce better output, faster, than was possible before. The expertise doesn’t become optional. It becomes the thing that determines whether AI produces something useful or something that just looks finished.
Four Pillars
Where AI fits — and where it doesn’t.
AI can accelerate
Concept generation, design iteration, prototype variants, front-end code scaffolding — all significantly faster with AI in the loop. The output ceiling goes up when the person driving it knows what they’re doing.
AI can’t replace
Domain research, user workshops, stakeholder facilitation, implementation judgment, and the expertise to know what questions to ask. These require human understanding and can’t be prompted into existence.
Designing for AI
Embedding AI into enterprise products is its own UX discipline — where it helps vs. adds noise, how it surfaces insights, what context it needs to be genuinely useful rather than a liability. These are hard UX problems that require the same depth of user understanding as any other.
The prerequisite
AI in design works when the human driving it understands the problem deeply. The tool doesn’t supply the understanding — it amplifies what’s already there. Garbage in, garbage out. Just faster.
There’s a second problem worth naming.
As AI gets embedded into enterprise software, the UX questions become genuinely hard — and largely unresolved. Where does AI add value versus add noise? What does a user actually need back from an AI query, and in what format? How do you design for a system that generates variable, probabilistic output — where the same prompt can produce different results? How do you surface confidence levels without overwhelming users who just want to get something done?
These aren’t hypothetical questions. They’re landing on product teams right now, often without UX at the table for the conversation.
My position: designing for AI features requires the same rigor as any other UX work — user research to understand the task and the mental model, prototyping to test the output format, and the judgment to know when “AI-powered” is genuinely useful versus a feature looking for a problem.
What senior UX leaders should be thinking about.
The question isn’t whether your team should be using AI. They should be — and if they aren’t, they’re slower than they need to be. The more useful question is: what does AI change about how a UX team should be structured, where senior judgment gets applied, and what we should expect from practitioners at different levels?
My view: AI raises the floor and compresses the time it takes to get to a first draft — which means the valuable work shifts even more toward the things AI can’t do. Deeper domain understanding. Better facilitation. More rigorous thinking about what the user actually needs versus what’s technically interesting to generate. The senior UX role doesn’t shrink when AI arrives. It becomes more important, because someone still has to know if what comes out is any good.
That’s the conversation I’m interested in having — with teams who are serious about using AI well, not just using it.