DEV Community: Katerina Bulkina

Why Users Ignore Half the Features in Your SaaS Product

Katerina Bulkina — Fri, 31 Jul 2026 22:23:46 +0000

Every product team has experienced it.

A feature ships after months of planning, design, development, QA, and internal demos. The team is excited. It solves a real problem on paper. It even becomes one of the highlights in the release notes.

Three months later, almost nobody uses it.

The common explanation is that users don't like change. I don't think that's the real problem.

I've worked on enough enterprise products to notice something else. Most unused SaaS features don't fail because they're bad. They fail because they never become part of the user's everyday workflow.

As product designers, we usually blame this on bad onboarding or lazy users. We think if we write a great tooltip, push a massive banner, or blast out a summary of SaaS features, people will magically change how they work. But this gap between shipping code and getting real product engagement isn’t a user problem.

It’s an organic reaction from people who just want to get through their workday without surprises. Whether it’s a smart automation tool or a basic Google Sheets plugin, users ignore features when we don’t respect their time, habits, and immediate goals.

That's a completely different problem.

And it's one that can't be solved with another announcement banner.

Good Features Still Get Ignored

The recent explosion of AI features made this pattern much more obvious.

Many enterprise products that had nothing to do with AI suddenly introduced assistants, recommendations, automatic scheduling, or AI-generated reports.

The technology worked. The adoption often didn't.

Let’s look at this purely from the user's side, ignoring the hype in founder and investor slide decks. Imagine a construction foreman who's been planning crews manually for twenty years. He knows every single operational edge case, every worker’s mood, and every local delay factor by heart.

And one morning, the software automatically reorganizes tomorrow's schedule out of nowhere.

From a technical perspective, the optimization might be perfect. From the foreman's perspective, it's terrifying. He doesn't know why the schedule changed. He doesn't know what assumptions the system made. He doesn't know what happens if it's wrong. His first reaction isn't excitement. He’s going to absolutely hate it.

The same thing happens with payroll, inventory planning, procurement, logistics, equipment allocation, and almost every other business-critical process.

If an AI system silently calculates someone's payroll rate or automatically changes equipment assignments, very few people will approve it blindly without checking every detail. It feels like handing something incredibly important over to a total stranger and hoping for the best. It just feels scary. In complex business tools, if it's confusing, it's dangerous.

This is a massive issue in enterprise UX. When we design for tricky setups like a complex CRM UX, an ERP UX, or specialized internal tools UX, a user's main goal is simple: don't mess up. If a feature acts like a black box — asking for full control while hiding how it works — users will actively avoid it to protect their jobs. If the tool makes a mistake, the person gets blamed, not the algorithm. So when AI UX or any complex automation lacks transparency, saying "no thanks" is the only logical choice for the user.

If It’s Hidden in Settings, It Doesn’t Exist

The first reason behind poor feature adoption comes down to basic layout. Often, a really clever feature gets tucked away inside the settings panel. On paper, it makes sense. If you're building a data sync tool or an external data pipeline integration, its logical home is in the integration settings tab.

But here’s the reality of user behavior: if something is buried three clicks deep in a configuration menu, it simply doesn't exist. Nobody opens a B2B app to hang out and explore. They log in with an urgent to-do list. If a new feature doesn't cross their natural visual path while they're doing their main job, they’ll never see it, no matter how clean that settings page looks. Even if the new integration could save them hours every week, they're unlikely to explore it right now.

This is where many teams misunderstand feature discovery.

Visibility isn't the same as relevance. Users notice things that help them solve the problem they're facing at that exact moment. Everything else becomes background noise.

Why Pop-Up Banners & Release Notes Fail

To fix this invisibility problem, teams usually turn to loud UI interruptions. They build huge modal banners that pop up the second a user logs in, shouting about a major update. Product teams think: "Well, they definitely can't miss this!" And they're right, the user sees it, and their immediate instinct is to find the 'X' and close it as fast as possible.

Why? Because when a user opens a SaaS tool, they're already focused. They need to fix a broken ticket, look at a warehouse error, or dispatch a crew. A massive banner blocking their screen is just an annoying obstacle.

They don't skip it because they hate new tech, they skip it because the app is literally stopping them from doing their actual job at that moment.

Relying on release notes to drive feature discovery is just as ineffective. Let's be honest, almost nobody reads release notes except a handful of technical power users. For everyone else, a long text log of updates has zero context. The app fails to show value where it matters most: right in the middle of the task.

In the real world, people find out about new features from their coworkers. A user changes their routine because someone else on their team says, "Hey, I started using this integration, and it saves me two hours every Friday." Once a real human validates it, the user is finally willing to take a break from their rush, dive into the settings, and figure out how it works.

The Power of Habit: Why Change is Hard

The hardest competitor is yesterday's workflow. This is something founders often underestimate.

Users don't compare a new feature against nothing. They compare it against the process they mastered for months, or even years. Maybe they've been using spreadsheets for ten years. Maybe they have a complicated approval routine. Maybe they've built their own shortcuts. Their current workflow may be inefficient from the outside. But it's predictable and people trust predictable.

Too often, features are built because a founder had a great chat with an investor, noticed a competitor adding a checkbox, or wanted to ride a trend.

The team builds it. The feature works. Yet users barely touch it. Why?

Because it wasn't born from the user's frustration. It was born somewhere else. And if a feature didn't come directly from a painful, screaming user need, it’s going to get ignored.

Changing behavior is expensive.

And when design is driven by market pressure instead of real user pain, it doesn't fit the actual user workflow. The new experience has to be much better before users decide it's worth the effort.

Complexity Kills Curiosity

Even when users discover a feature and genuinely want to try it, many products ask for too much before showing any value.

Connect three external services. Configure permissions. Fill in fifteen fields. Invite your teammates. Import historical data. Wait for synchronization. I've seen onboarding flows that required thirty minutes of setup before users experienced their first benefit. Most people never make it that far.

When setting things up is a nightmare, people give up before the feature can even prove itself. On a stressful workday, an unverified promise of "future efficiency" can't compete with a clunky manual process that the user already knows how to do. Every additional step creates another opportunity to quit.

Good SaaS onboarding helps users experience one meaningful success as quickly as possible instead of overwhelming them with every capability. If value only appears after half an hour of configuration, many users will never reach it.

Features Should Introduce Themselves

One principle has become increasingly important in my own design work.

Features shouldn't wait for users to discover them. They should introduce themselves naturally during real work.

Imagine a logistics platform. A dispatcher spends fifteen minutes manually assigning trailers. Instead of showing a generic banner after login, the interface notices repeated manual assignments. At that exact moment, it says: "Would you like the system to generate an optimized assignment based on your current rules?" Now the feature has context. The user understands why it appeared. They already feel the pain it's trying to solve.

The conversation changes completely. The software isn't saying: "Look what we built." It's saying: "I noticed you're doing something repetitive. I can help."

That's the difference between advertising a feature and solving a problem.

Product Engagement Comes From Small Wins

Many teams measure product engagement by counting feature usage. I think that's looking at the wrong metric first.

People don't engage with features. They engage with outcomes.

Nobody wants AI scheduling. They want fewer scheduling conflicts.

Nobody wants automated reports. They want to stop wasting Friday afternoons building them manually.

Nobody wants another dashboard. They want faster decisions.

The feature is only valuable if it becomes the easiest path toward the user's actual goal.

Otherwise, it becomes another checkbox on the roadmap.

Feature Overload Makes Products Feel Smarter Than They Are

There's another side effect that product teams rarely discuss.

As products mature, they accumulate more and more functionality. Settings become crowded, navigation grows, menus expand. Users start seeing dozens of capabilities they'll never touch. This creates feature overload.

Ironically, adding more functionality often makes users feel less capable. They become unsure which option they're supposed to use. They hesitate or they simply ignore everything unfamiliar.

This is a problem of prioritization.

That's why great product UX reveals the right capability at the right time, when users actually need it.

The Best Features Feel Like They Were Always There

When I think about successful feature launches, one thing always comes to mind.

The best ones rarely feel new. Instead, they feel like the product suddenly became more helpful. Users don't remember learning them. They simply become part of daily work.

That's ultimately what great SaaS UX should achieve. Not bigger release announcements. Not louder onboarding. Not more banners. Just software that quietly understands what people are trying to accomplish and offers help exactly when they're ready for it.

Because users rarely ignore features that solve today's problem. They ignore features that ask them to imagine tomorrow's.

The Profession That Changes Faster Than Its Job Description

Katerina Bulkina — Fri, 31 Jul 2026 21:52:09 +0000

If you ask ten SaaS founders today what their designer actually does, you’ll get ten different answers.

One will say: “They do UI.”
Another: “They own UX strategy.”
The third: “They basically prototype the whole product and talk to devs.”
Someone else: “They set up design systems and help with AI stuff.”
And all of them will be right.

That’s the core problem with the modern design profession. The work has changed faster than we’ve been able to name it. The title on LinkedIn stayed the same. Everything inside the role changed.

A UX designer, Product Designer, or UX/UI designer today might be doing things that simply did not exist in the profession five years ago. Not as extra skills, but as part of daily work. And that gap between titles and reality is now large enough to cause real hiring mistakes, product issues, and false expectations on both sides.

The Job Title Didn’t Change. The Job Did.

Titles like UX designer, Product Designer, or UI specialist used to mean something specific. They implied a clean, predictable workflow: you make some static layouts, map out user flows, and throw the files over the fence to engineering. Just a year or two ago, a standard day involved documenting design decisions in Figma and executing a traditional design handoff. Developers would look at the static screens, guess how the animations should feel, and code everything from scratch.

Today, that wall between design and code has crumbled. Modern designers don't just hand over static screenshots. They build fully functional, interactive prototyping states, architect complex design systems tied directly to production code, and spin up custom AI agents to crunch user research data.

At UITOP, this is just our normal routine. Instead of just watching these shifts happen, we’ve baked them straight into our workflow, offering clients a suite of AI services - everything from automated UX research and conceptual design to living demo-prototypes and seamless Figma-to-code pipelines. In fact, if you want a look behind the curtain, here is exactly how we use AI in our process.

It’s totally standard for one of our team members to spend Monday morning configuring Figma variables and conditional tokens for frontend devs, and by Thursday afternoon be building a high-stakes pitch deck for a client’s upcoming conference. This isn’t a case of scope creep. It’s just what modern product design looks like today. Product people are naturally expanding their reach into both the tech stack and the business strategy.

The Invisible Shift From Screens to Systems

One of the biggest changes happened quietly.

Design used to be about screens. Now it’s about systems.

When you work on SaaS design or enterprise UX, you stop thinking in isolated interfaces very quickly. You think in states, permissions, roles, logic, and scalability. You think about how one decision affects dozens of flows you’ll never design manually.

That’s why design systems are part of the foundation now.

But here’s the key change: designers no longer just use systems. They design them together with engineering constraints in mind. Tokens are not abstract concepts anymore. They’re part of how the product is built.

This is where the role blurs into technical territory. Not because designers became developers, but because products became too complex to separate concerns cleanly.

The Race with AI

AI hasn't just sped up our workflows. It has created a whole new set of product problems that didn't exist five years ago. Traditional SaaS design used to be about setting up predictable paths for human inputs. The app sat there quietly until a user clicked or typed something. But when you’re building a product around semi-autonomous AI agents, your main challenge shifts from creating buttons to designing for trust and transparency.

When an app runs on AI agents, the user isn't just clicking through a workflow, they’re managing an assistant. The UI has to clearly show what the agent is doing in real-time, why it made a certain decision, and how the user can step in to correct or stop it. This is a brand-new layer of digital product design that requires a sharp UX strategy to balance heavy data with a clean, low-stress layout.

We’ve worked on tons of AI platforms, and I see the same pattern everywhere: if the interface doesn’t explain what the agent is doing and why, users will reject it. They won't trust the app, even when the AI gets the answer 100% right. As an AI product designer, you have to build "interfaces of trust" that expose the agent's line of thought. It’s as much about cognitive psychology as it is about visual layouts. And it’s now part of the designer’s responsibility whether the title reflects it or not.

Prototyping is no longer optional

While design became more systemic, prototyping underwent its own transformation. It moved from a presentation tool to core design activity.

Modern AI design tools allow us to build experiences that feel real enough for users, stakeholders, and developers to evaluate actual behavior, not static assumptions.

This changes the entire feedback loop:

Founders get to react to real, clicking flows, not a passive gallery of screenshots.
Developers actually understand the underlying logic long before they write their first line of production code.
Product managers catch nasty edge cases early in the game, rather than during a frantic QA session the night before launch.
UX workflows shrink, cutting out weeks of back-and-forth alignment meetings.

And yes, AI-assisted tools deserve a lot of credit for lowering the technical barrier here. You don’t need to spend years mastering complex coding syntax just to build a prototype with rich, complex behavior anymore. And that’s a beautiful thing.

But it also hides something important.

The Paradox of Lower Entry & Higher Expectations

All of this creates a pretty strange situation for anyone trying to break into design right now. Not long ago, a junior could get their foot in the door by focusing on one thing - maybe just UI screens, basic product flows, or UX copy. That was enough to start.

Today, the expectations are very different. You are an all-in-one designer. You’re often expected to understand systems, put together working prototypes, do a bit of vibe-coding, and be comfortable with AI tools almost from day one. The bar is set really high.

At the same time, AI has made the mechanical parts of design surprisingly easy. You no longer need to spend years learning complex code just to test an interactive idea. AI can handle a lot of that for you. And that’s where things get tricky. Designers who learn mostly through AI tools tend to treat everything under the hood like magic. It works, so they move on, without really understanding why it works.

It’s a bit like dealing with kids now — you almost have to convince them to do homework without opening ChatGPT, just so they actually learn how to think. Using AI prompts isn’t a career on its own. Underneath all the automation, you still need to know how to build clean, scalable systems from scratch.

So yes, AI makes getting into the field easier. But staying relevant and actually meeting what the market expects has become much harder. Take the tools away, and a strong designer still needs to know how things really work.

Decoding What Your Project Actually Needs

Because the industry is moving so fast, we now have a million hyper-specialized titles: UX & UI Designer, Product Designer, Graphic Designer, Brand Designer, AI Product Designer, or Forward Deployed Designer. On paper, they sound like totally different jobs, but in reality, the lines are completely blurred. One versatile designer often covers three or four of these roles at once.

When founders and product managers look for help, they usually show up with a rigid, trendy title in mind. They'll say, "We need a UI designer to polish our screens," but when you look under the hood, their trial drop-off rate is terrible because the user flow makes no sense. They don’t need visual polish, they need deep SaaS UX structural repair.

Or, they’ll scramble to hire an expensive AI designer because users find their machine learning features confusing, only for us to realize the real culprit is a broken notification system or a clunky onboarding flow - classic, foundational enterprise UX problems.

Trying to guess the exact title for your job post is a waste of time. If you're a founder, the best thing you can do is just explain what’s broken in the product — where users are getting stuck and which business metrics are stalling. A mature, experienced design team won't hide behind job descriptions. They’ll look at the big picture and bring the right mix of UX, tech, and business logic to fix it.

In fact, if you approach a design agency and they force you to define a hyper-specific, narrow role before they even start looking at your product, consider it a red flag. It usually means they just want to check off tasks instead of taking true ownership of your product's success.

The Uncomfortable Truth

Design is no longer a clearly bounded role.

It’s uncomfortable for hiring managers.
It’s uncomfortable for designers who want a clean identity. But it’s reality.

The profession evolves faster than we can name it — because products evolve faster than organizations adapt.

And until that slows down (it won’t), the best designers won’t fit neatly into job descriptions. They’ll fit into problems.

That’s not a crisis of the profession.
It’s proof that it matters more than ever.

The Big Picture

At the end of the day, software design has outgrown its old shell because its impact on business value has skyrocketed. We’re no longer just talking about making software look pretty or placing buttons. Design now directly dictates how fast your engineering team can ship, how reliable your software feels to enterprise buyers, and how easily humans can collaborate with smart algorithms.

The job doesn't fit into a tidy HR template anymore, and that's a good thing. Modern designers are systems thinkers who can jump between user psychology, AI automation, and clean frontend logic. At UITOP, we’ve leaned into this reality entirely - forgetting the rigid titles and focusing on building high-performance software that actually scales.

The Real Cost of Generating UI Without a Designer

Katerina Bulkina — Mon, 29 Jun 2026 07:40:00 +0000

Every Monday morning, I spend a couple of hours going through what founders built over the weekend with Lovable or v0. They often send over screens that indeed look impressive, but at first glance. Then I start clicking around, and this is when the illusion breaks.

AI design tools work well for what they do. But the problem I keep seeing is that some founders frequently confuse screen rendering with product design. These two are completely different activities, and there’s a high probability that mixing them can cost teams real money.

How a Vibe-Coding Session Actually Goes

Prompt one: "Create a dashboard for logistics management." The result actually looks good.

Prompts two through five: you refine the layout, add filters, adjust charts, ask for a more unique look.

Then prompts six through twelve arrive: "Why are the filters hidden behind the table? Undo that. And make the table wider." At this stage, you typically stop building and start firefighting.

By the time you've burned through hundreds of tokens chasing your own earlier instructions, the session ends with a result that a junior designer could deliver in half a day. This is what vibe coding actually looks like in practice.

Add it up: $50–200 in Lovable credits, plus 8–12 hours of founder time at a typical rate of $75–150/hour. That's $600–1,800 in real cost for a result that a junior designer would deliver in half a day for roughly $100–200.

The tool that was supposed to save money ended up being the expensive route.

What else is worth mentioning is that burning through tokens is actually a symptom of a broken AI workflow. The root problem is that AI has no long-term vision for your interface architecture, and every prompt is handled locally. When you ask it to move a button, it moves the button. But AI has no way of knowing that the button was visually tied to an element two columns over. You fix one point and break two others. This is the loop.

A designer, in contrast, looks at a screen as a living system where each element is connected to several others. Before moving a single element, they ask: Does this need to exist at all? This question is the foundation of product UX, and it is never asked when you're prompting screen by screen.

Data Visualization Gap

AI reads the data it's given and draws a bar chart or line graph. It doesn't think about what question the user is asking when they look at that data, or which visualization format actually answers that specific question.

The prompt didn't communicate the idea in the specialist's head, let alone what a regular user needs. That's the core difference in how we think. AI looked at the data type (percentages) and picked a visualization to match it. But a designer also looked at the question the user asks when they see this data: "How complete is this?" AI interpreted the question as "what does this consist of?"

So the answers look different and solve different problems.

Cost: anywhere from $0 if the designer catches it in time.

In our case, it was $0, because we caught it ourselves. But that's not always how it goes.

What Gets Lost Between the Prompt and the Screen

AI UI generation is fast. The speed is also what makes it easy to skip the question of whether the screen you just generated actually solves the right problem.

But when you type a prompt into a UI generation tool, you receive pixels that resemble a product. Generative UI gives you the output of a decision process, without the decision process itself.

What you don't get is the layer of thinking that happens before a designer opens their tool. This layer includes:

Understanding what question the user is actually asking when they open this screen
Mapping how this screen connects to the flow before and after it
Identifying which elements are load-bearing for the user's task and which are decoration
Anticipating how the layout behaves when real data replaces placeholder text

We had a SaaS UX project where AI generated a timeline interface: weekly status summaries at the top, detailed reports below. Summary first, details second, and this actually sounds logical.

Except when real users interacted with it, the logic collapsed. A user would open the screen to understand why last week's metrics dropped. They'd read the status summary at the top, scroll down to find the details, lose track of what the summary said, scroll back up, then back down.

A few people even started opening two browser tabs to compare information side by side. This kind of workaround is common with AI-generated interfaces, as users adapt to the tool's logic instead of the other way around.

When we redesigned the layout so the weekly status was located inside the column header of the detail table, the interface became one coherent tool, and the user could answer their actual question in a single view.

This is what AI UX design misses: the layout looked logical in the prompt, but only a real user session revealed how it actually behaved.

Fortunately, we detected this issue at the design stage, and it took us roughly 4 hours of rework at $50–80/hour.

If the same layout had reached development first, we'd be looking at 2–3 days of backend restructuring, and this is $800–2,000 added to the bill.

AI Can Also Break Down Brand Consistency

A client of mine, a founder with a product company, was traveling for two important sales meetings. The presentation for the first meeting was ready. For the second, he opened Claude on the flight and generated 50 slides.

Almost all slides looked this way:

When he landed and showed a designer, they went through the deck slide by slide, and almost every slide had the same problem: it looked like a generic corporate presentation pulled from a template library. The colors, fonts, and visual structure had no connection to the product's brand. A person in that meeting room would have had no way of knowing this came from the same company as the website, the product UI, or the materials from the previous meeting.

We rebuilt the entire presentation before the second meeting. Here’s the new design we came up with:

Ultimately, the client did win new partners from that trip. Whether a polished, on-brand presentation has made the outcome better, we can't say for certain. But we know what visual consistency does: it creates trust. When a company's materials look cohesive, people assume the company knows what it's doing.

AI had no access to the product's visual personality, its tone, its audience's expectations, or the specific fonts and colors those users had seen hundreds of times. Interface consistency is usually developed gradually, across every touchpoint, but AI starts from zero each time.

Visual familiarity builds trust because of a well-documented cognitive pattern in UX called the mere-exposure effect: people trust what they recognize. An interface that works correctly but looks visually foreign creates a discomfort that users feel but can't explain. This is one of the most overlooked problems in AI UX today.

The Investment Question

Some founders plan to skip design investment early and add it later when there's more budget. But the cost doesn't disappear. It just moves to a stage where fixing it is harder.

Reworking a vibe-coded interface that's already in development means going into a live system, understanding what every piece depends on, and changing the structure while the product is running. That's a different category of work from building clean from the start, and it's a recurring pattern in AI interface design projects. And engineering hours spent untangling AI-generated layout decisions can be some of the most expensive hours in a product budget.

Before computers, accountants did all their work by hand. When computers arrived, they didn't disappear. They got faster. UX designers are at that same point now. AI is the calculator. The judgment about what to calculate, and why, still has to come from a person.

And this is the gap AI product design tools haven't closed yet. The calculator got faster. The judgment still has to come from a person.

Budget spent on design before development is an investment. But the same budget spent after development is a repair bill. And this sequence is usually the same across every AI development workflow.

Where AI Genuinely Belongs in the Design Process

AI still has a real place in design work. It's good at one specific thing: executing a clear specification fast. For example:

When a designer needs to explore five different layout directions for a component, AI can produce these starting points in minutes. The designer picks, adjusts, decides. That's a genuinely faster way to work.
AI also handles repetitive UI work, like content variants, iterations on an established component pattern, and microcopy for buttons and labels. When the creative decisions are already made, AI is a good production tool.
For founders, AI is useful for making a rough idea visible before a designer is involved. Used this way, AI prototyping shortens the briefing conversation without replacing the design work. Turning a vague concept into something you can point at and say "more like this, less like that" makes the briefing conversation much shorter.
Data visualization: Ask AI to chart a dataset, and it picks a format based on the data type: percentages get a pie chart, trends get a line graph.

A Practical Approach If You're Already Using AI Tools

If AI is part of your process, here's how to avoid the expensive version of these mistakes:

Define the user's actual question before prompting. What task are they completing? What decision are they making? Write it down.
Treat AI output as a reference. Have a designer review the flow before it reaches a developer. Even a short review catches the critical mismatches between what the screen shows and what the user actually needs to do. This review step is the part teams often tend to drop from their UX workflows when they switch to AI-assisted design.
Include your brand guidelines in the conversation. If you have them, attach them. If you don't have them yet, that's worth solving before generating 50 slides for a sales meeting.
Track your iteration count. If you're on prompt 15 and still adding complexity, stop. That's a signal to step back and reconsider the structure. More pro mpt engineering won't fix a layout at this point.

Final Say

Designers used to hear "we don't need UX, just build it." Now, founders say, "I'll generate the design with AI and hand it straight to the developer." The excuse is different. But the result is still the same: product thinking is skipped, and the cost shows up later.

AI is a real tool, and it speeds up parts of the design process that used to take hours. But faster screen generation doesn't replace the thinking that impacts what these screens should actually do. That part still has to happen, and the earlier it happens, the cheaper the whole project will be.

AI Can Generate Interfaces. It Still Can't Design Products

Katerina Bulkina — Sun, 07 Jun 2026 18:41:25 +0000

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.