DEV Community

Cover image for Why AI Products Have Terrible UX
Dee
Dee

Posted on • Originally published at blog.deeflect.com

Why AI Products Have Terrible UX

Why AI Products Have Terrible UX

Most AI products have terrible UX. Not because the AI is bad - because nobody who understands both AI and design is in the room when these things get built.

I've spent 10+ years in product design, including five years designing institutional fintech for 70+ banks at VALK. Now I build AI systems. I write prompts and I write interfaces. I can spec a component in Figma and wire up the agent backend that powers it. That combination is genuinely rare, and the fact that it's rare is exactly why AI UX is such a disaster right now.

This isn't a subtle problem. Open any AI product built primarily by ML engineers and you'll feel it within 30 seconds.

Why AI products have terrible UX by default

The people who understand how transformers work don't think in interaction flows. They think in loss functions and benchmark scores. When an ML engineer ships a UI, you get a settings panel with 40 sliders and tooltips that say "controls the randomness of model outputs." Thanks. Very helpful.

The people who understand interaction design usually can't implement AI systems. They can map the user journey beautifully but they don't know what a context window is, can't reason about latency tradeoffs, and treat the AI as a black box that either works or doesn't.

The intersection - people who can do both - is genuinely tiny. Which means most AI products get built by one camp or the other. And it shows.

Here's the uncomfortable truth: a mediocre model with great UX beats a great model with terrible UX every time. ChatGPT didn't win because GPT-4 was the best model when it launched. It won because the chat interface was dead simple. You typed. It responded. No configuration. No onboarding. No explaining what a temperature setting does.

That chat box was a design decision, not an ML decision. And it's worth billions.

The specific ways AI UX fails

Let me get concrete because "bad UX" is a garbage diagnosis. Here's what I actually see when I use most AI products:

The specific ways AI UX fails

Chat-for-everything syndrome

Not every AI interaction needs a text input. Some interactions need a button. Some need a slider (a single, well-labeled one). Some need a select dropdown.

When you build "chat as the UI" because it's easy to implement, you're making your users do the work of figuring out what to ask. That's backwards. The product's job is to make the right actions obvious. If your AI can summarize a document, add a "Summarize" button. Don't make me type "please summarize this document" like I'm filling out a form in 1998.

The chat interface pattern gets cargo-culted because ChatGPT did it and ChatGPT is successful. But ChatGPT's whole thing IS chat. It's a general-purpose assistant. Most AI products aren't general-purpose - they're doing specific things for specific workflows. A focused tool should have focused UI.

Loading states that feel like crashes

Generative AI is slow. A response can take anywhere from one second to 25 seconds depending on the model, the prompt length, and what you're generating. Users are not okay with a spinner for 20 seconds. They need to know something is happening, roughly how much longer it'll take, and ideally a preview of the output streaming in.

Streaming output is table stakes in 2025. If your AI product shows a blank area and then suddenly dumps the full response, you've already lost. It feels like the app froze and then magically recovered. Streaming makes the latency feel shorter than it actually is - that's not a trick, it's respecting the user's attention.

I've seen products where a 15-second model call shows a static spinner with no copy, no progress indication, nothing. Users absolutely hit refresh. Then they get confused about duplicate outputs. This is a solved UX problem that keeps getting ignored because the engineer who built the AI part is done and the UI is "good enough."

Error messages written for engineers

"Something went wrong." Rate limit exceeded. Context length exceeded. Model unavailable.

These are real failure modes that users hit regularly and none of them should surface as generic error states. When the model hits a rate limit, tell the user there's high demand and you're retrying. When the context gets too long, tell them what to do about it - not in token counts, in plain language. "Your conversation is getting long - try starting a new one for best results."

Error handling is where you find out if a designer was actually involved. Engineers write error messages for themselves. Designers write them for the person who just wanted to finish a task.

Settings pages designed for nobody

Temperature. Top-p. Frequency penalty. Presence penalty. Max tokens.

These settings exist because they're parameters in the API. They got exposed in the UI because nobody asked "should we expose this?" They just asked "can we expose this?" Yes, you can expose it. That doesn't mean you should.

I get it - power users sometimes want control. But the defaults should be invisible and the advanced settings should be buried behind a "configure" link that 95% of users never click. Progressive disclosure is a basic design concept. Show the simple thing first. Put the complex thing behind one more tap.

When your settings page looks like a synthesizer, you've failed the design. Users don't want to tune a model. They want to accomplish something.

Treating AI output as final

AI output is a draft. It's always a draft. The best AI products make this obvious by making everything editable in-context. Click a sentence. Change it. The system knows you changed it and uses that as signal.

When AI output renders as static text in a read-only block, you're implicitly telling the user that the AI's word is final. That's backwards. The user is in charge. The AI is a collaborator. The UI should make it trivially easy to edit, regenerate, or reject any piece of output.

Linear's AI summaries are a good example of getting this right. The summary is inline and you can just edit it like any other text. The AI offered a starting point. You own the result.

No feedback loop

If a user deletes an AI output and types something completely different, that's signal. If they regenerate three times, that's signal. If they always ignore the suggested action, that's signal.

Most AI products collect none of this. Not actively anyway. There's no thumbs up/thumbs down. There's no "fix this" button. There's no way for the user to tell the system "you're getting this wrong."

Beyond the product improvement angle, feedback UI makes users feel like they have agency. The AI isn't doing something to them - they're collaborating with it. That's a fundamental shift in how the product feels, and it costs almost nothing to implement.

Nielsen Norman Group has documented this pattern extensively - the products that build in feedback mechanisms consistently score higher on user satisfaction than those that treat AI output as a one-way broadcast. This isn't a new insight. It just keeps getting skipped.

What good AI UX actually looks like

Good AI UX is invisible. The AI is there, doing things, but you barely notice it. You just notice that the product works better than it should.

Autocomplete that predicts what you actually meant to type. Smart defaults that adjust based on what you've done before. Errors that self-correct before you ever see them. Suggestions that appear before you ask for them, in the right context, at the right time.

The goal is never to show off the AI. The goal is to make the user feel competent. There's a real difference between a user saying "this tool is so intuitive" and a user saying "wow the AI is amazing." The first is good UX. The second usually means the AI is impressive but the UX is still making you aware of it - which means it's getting in the way.

Figma's AI integrations are interesting to watch because Figma's team actually understands design. They still struggle with making AI actions feel predictable - there's always a moment of "wait, what did it just do?" - but they're closer than most. That moment of confusion is a UX debt they're actively trying to pay down.

The products I actually like using right now: Notion AI for the in-context editing flow, Cursor for how it makes AI suggestions feel like a collaborator not a replacement, and Linear for keeping AI features out of the critical path so they enhance without blocking.

All three share something: the AI is ambient. It's there when you need it, gone when you don't, and it never makes you feel like you need to understand it to use it.

Why AI products with terrible UX keep shipping anyway

The gap isn't closing fast enough. AI is getting more capable every few months. Design is being treated as optional or "we'll fix it later." The result is an ecosystem of increasingly powerful AI wrapped in increasingly confusing interfaces.

Why AI products with terrible UX keep shipping anyway

This is partly structural. Most AI companies are founded by researchers or engineers. Design hires come later, if at all. And when they do come, the designer often lands in a team where the ML engineers have already made the fundamental UX decisions - they just didn't call them design decisions. The architecture of the system becomes the architecture of the interface, which is almost never the right call.

Google's People + AI Research (PAIR) team has a whole guidebook on this. It's worth reading even if you don't agree with everything in it. The core insight - that AI systems require a fundamentally different design approach than deterministic software - is right. You can't just apply standard UX patterns to a system that might give a different answer every time. The guidelines for how to handle uncertainty, how to communicate confidence levels, how to make AI actions feel predictable without being rigid - that's the hard design work that most teams skip.

The Anthropic model card and usage policy documentation is also a useful lens here. The way they think about how Claude should communicate uncertainty and limitations is essentially applied UX thinking at the model level. That's rare. Most model providers treat the interface layer as somebody else's problem.

The companies that figure this out - that actually hire people who can span both domains, or that build real collaboration between their ML and design teams - are going to clean up. Not because their AI is better. Because their AI actually makes sense to use.

I started leaving fintech for AI specifically because I kept seeing this pattern and had nowhere useful to point people. The posts that get the most traction are always the ones about the interface layer, not the model layer. People are hungry for this.

Fix the UX before you touch the model

If you're building an AI product right now, the single most high-leverage thing you can do isn't to upgrade your model. It's to watch five users try to use your product without any help from you. Don't say anything. Just watch. You'll see exactly where the AI ends and the confusion begins. That's your design debt.

Spend a week on that before you touch your prompt engineering or your fine-tuning pipeline. The UX problems are costing you more users than the model quality is.

If you want to go deeper on the AI engineering side - how the systems actually get built, what the architecture decisions look like from someone who also designs the interfaces - check out what replaced prompt engineering for more technical posts. The design-to-engineering gap is a topic I keep coming back to because I keep seeing it break products that should work.

Fix the interface. The model will get better on its own. The UX won't.

Top comments (0)