My entire team at UITOP uses AI tools every day. I use AI for competitive research and copy drafts. And I use it to fill dashboard screens with realistic data so I can actually evaluate a layout. Tasks that used to take a day now take two hours.
That's exactly why I need to talk about what AI doesn't do in AI product design. Because after a year and a half of working with AI-built products, I keep seeing the same sequence of events. And it keeps ending in the same place: a founder who saved money on design in month one, pays significantly more to fix the product in month six.
The Pattern Starts With a Reasonable Decision
A founder is building a SaaS product. The team is small, and there are tools that can generate a working interface in hours. Lovable, Claude, Figma AI. The logic is clear: why hire a designer when the tool delivers a working interface immediately?
The first three or four months often go well. The product is live, early users are signing up, demo calls are happening. The MVP works. Then the numbers start shifting. For instance, onboarding drop-off climbs, or users open support tickets. The product isn't broken, but it's not converting either. The founder looks at the analytics and sees the problem. The analytics don't explain what's causing it.
This is when I get the call.
What AI Builds, and for Whom
Every AI interface produced by tools like Lovable or Figma AI is built from the most common patterns in their training data. In practice, that means they build for the most cooperative possible user: good connection, calm attention, a modern device, no time pressure.
Your actual user is not always that person:
- They open your product on a phone with a cracked screen while commuting.
- Their connection drops mid-flow.
- They misread a button label because they're distracted.
- They tap the wrong option and don't know how to go back. The session times out and their progress disappears.
AI doesn't model such a user. It doesn't generate error states unless you ask for them specifically. And it doesn't build for a screen that's 320px wide and in direct sunlight.
This becomes sharper when you look at AI UX decisions inside generated flows. A UX designer asks these questions. One of my designers was reviewing a Lovable-generated flow and asked Claude directly: Why is this solution structured this way? Claude immediately said the solution needed to be reconsidered. The screen looked fine. But the logic behind it didn't hold up to one direct question from a specialist.
Where Users Actually Leave
SaaS UX problems are most visible in onboarding. This is usually where products built solely with AI lose the highest percentage of users, and it's rarely obvious why from the data alone.
A user registers. The next screen asks for their company name, number of employees, and billing plan. They haven't seen the product do a single useful thing yet. They fill it out because they're still curious.
Next, they're asked to select from a set of cards with labels they don't recognize. They pick the first one and reach the dashboard. The dashboard is empty, no data, no guidance, no indication of what to do next.
They click around, land in settings, then go back, try another button. At some point, they can't tell if the product is broken or if they're the ones using it the wrong way. This moment of uncertainty is where you lose them. They close the tab, don’t come back, and your follow-up emails go unread.
You can see the drop-off in analytics. What analytics won't tell you is what the user was thinking on each screen, or which specific moment made them give up. That's a research question, and it requires talking to users and watching session recordings.
The Problem With Chat-First AI Products
A growing number of SaaS products are built around an AI chat interface as the primary interaction model. The logic makes sense: let the user type what they need, and the AI handles it. But conversational UI introduces a specific design challenge that tools don't solve on their own.
Chat interfaces remove the guardrails. In a traditional UI, buttons and menus constrain what the user can do. In a conversational flow, the user can type free-form input, and the product needs to handle it gracefully.
Chatbot UX failures are often invisible in early testing because founders test with clear, well-formed inputs. Real users don't write clear, well-formed inputs. They write fragments, use wrong terminology, or describe the outcome they want instead of the action they need.
Why AI-Built Products All Look Like Each Other
There's also a visual pattern I notice across AI-generated SaaS products: gray sidebar, blue primary button, Inter font, clean card layout. Such an interface is indistinguishable from the five competitors your user evaluated last week.
Think about the car industry in the 1970s and 80s. A Cadillac and a Citroën were immediately recognizable. Their visual identities were so different you could identify them from across a parking lot. Then, manufacturing standardization and aerodynamic requirements pushed every car toward the same optimal shape. Today, a Hyundai Tucson and a Lexus NX have nearly identical silhouettes. You walk up to find the badge.
SaaS products built on AI tools are going through exactly this. The tools produce what works across most contexts, which means they produce the same output for every product.
Your own visual identity is what shapes AI user experience in a way that sticks. A user who can't remember which product they used last Tuesday will not renew. AI tools don't have a point of view, so they can't give your product one.
Then, There’s a Code Problem
Here's a scenario I worked through recently. A team used Lovable to build a prototype. It looked sharp, and demos went well. But when the time came to build the actual product, the tech lead reviewed the prototype code to plan development.
His estimate was three days. The feature should have been roughly 1,000 lines of code. However, Lovable had generated it in over 10,000 lines.
Ultimately, the developer spent weeks untangling code that a designer-led process would have delivered cleanly. The budget goes into the product either way. The question is whether it goes in at the beginning, when you're making decisions, or at the end, when you're paying to undo them.
Poor AI SaaS UX foundations compound this problem: when the interface logic is inconsistent, developers have to build compensating logic into the code, which makes the entire system harder to maintain.
A designer working from a proper design system hands off named components with consistent variables directly usable in a developer's project. This is standard practice in professional design work. AI-generated output skips this entirely, so developers build the system themselves from the code up, which takes much longer and produces more inconsistencies.
Where AI Genuinely Cuts Time
The answer to all of this isn't to stop using AI tools. It's to integrate them into a disciplined AI workflow where a specialist controls the decisions.
- Client prototypes. Building an interactive prototype in Figma and then spending the first ten minutes of a demo explaining which parts are clickable is a waste of a demo call. Lovable generates a working prototype in hours, the client opens it in a browser and walks through it on their own, and the conversation starts from a much more useful place.
- Realistic screen data. A dashboard with placeholder text tells you very little about whether the layout works. You need to see what happens when a company name is 47 characters, when a value is negative, when there's no data to display. AI can populate a screen with realistic data in minutes.
- Competitive research. Reviewing ten competitor products, mapping their navigation patterns, identifying where they make the same decisions and where they diverge: this used to be a full day of work. With AI, it takes a couple of hours. The analysis is still the designer's. Yet, the time to gather the raw material is just shorter.
The Decision You're Actually Making
If you build with AI tools alone, you're likely making a specific trade: faster output now in exchange for more expensive fixes later. Sometimes, this is right. Getting to market matters.
But it's worth understanding clearly what you're trading.
Before generating a single screen, a team with a UX designer answers: who exactly is this product for, and what task are they trying to complete? Then: what happens when that task goes wrong? This work takes days. It shapes every design decision that follows.
UX designers working with AI tools are completing tasks in roughly half the time they used to. The savings are real. They come from a specialist using AI as an instrument. AI product UX done well is the product of that combination: the speed of the tool, the judgment of the person.
There's a principle in development: if you can't code, you can't vibe-code. You need to understand what you're generating to make good decisions about it. The same applies to design. AI amplifies what you already know.
Three Questions Before You Open a Design Tool
If you're building a product right now, or evaluating one that's already live, start here:
- Who is your user, specifically? Not the ideal user with full attention and a perfect connection. The real one, in a real context, with a real reason to be distracted.
- At which step in your onboarding do users drop off, and do you know what they were thinking at that moment?
- Can a new user reach the first useful action in your product without any help from your team?
If you can't answer all these questions confidently, that's the design work that needs to happen before you generate another screen. AI will make this work faster once you've done it. But it won't do it for you.
Top comments (0)