LLMs Can't Save Bad UX

Every team I've worked with has shipped at least one AI feature that nobody used. The post-mortem usually lands on "users don't want AI". In the cases I've seen up close, at Entropy Labs and with clients who came to us after a launch went quiet, that was the wrong conclusion. What users didn't want was a slower version of the same problem.

The pattern goes like this. The product has a UX problem: search is bad, onboarding is long, reporting is manual. Someone adds an AI layer on top. The original problem is still there, now with latency and the occasional confident mistake. Users try it once, go back to their workaround, and the team decides AI was the mistake.

Three features that failed

The search chatbot that should have been a search box

A client had an internal knowledge base with bad search: keyword matching, no ranking, no tolerance for typos. People hated it, so they built a semantic search chatbot.

The chatbot understood questions well. Ask "how do we handle refunds for enterprise clients?" and it found the right document. But it took a few seconds to answer, it replied with a paragraph where a list would have done, and when the paragraph was wrong there was nothing to browse. People couldn't scan results; they could only read a summary and hope.

What they needed was Meilisearch or Typesense, with fuzzy matching and ranking, answers in tens of milliseconds, and a list you can skim. It was cheaper to run, too, since the chatbot came with a monthly API bill that the original problem never deserved. The AI version was the more impressive build and the worse product.

The onboarding assistant for a twelve-step setup

Another team had a twelve-step setup flow that most new users abandoned. Their fix was an assistant that walked people through the steps in conversation. It remembered where you left off, answered questions about each step, and was well built. Completion went down.

The twelve steps were the problem. When the flow was cut to four, with sensible defaults filling in the rest, completion roughly doubled and the assistant was retired.

The report builder that taught people not to trust it

This one was ours. We added a natural-language report builder: "revenue by product category for Q3, excluding returns". It demoed beautifully.

In real use, people generated a report, checked it against the numbers they already trusted, found a small discrepancy from rounding or an edge case in a filter, and stopped trusting the feature altogether. Finance people need exact numbers, and "almost right" is a failure state for them.

We replaced it with a guided form where AI does one small job: pre-selecting the filters you probably want, based on what you ran recently. Usage went from barely anyone to a solid share of people who build reports, once the AI's job had shrunk to suggesting which buttons to press.

Latency

Every model call costs time, usually somewhere between half a second and several seconds, and people notice. Search and e-commerce teams have measured for years that even a couple of hundred milliseconds changes behavior, and LLM features routinely add whole seconds.

I think of it as the feature having to pay back its wait. Saving someone ten seconds of manual work in exchange for four seconds of waiting is a win. Saving two seconds in exchange for four is a regression that happens to use a model.

The easiest way to pay it back is to take the work out of the user's path:

• a document is uploaded, entities are extracted in the background, and the tags are there when someone opens it
• data changes overnight, a summary is written before anyone asks, and it's on the dashboard in the morning
• a form opens already filled in from the person's history

When it's almost right

Normal software is right or broken. A button works or it doesn't. AI features are right most of the time, wrong some of the time, and occasionally wrong with total confidence. The confident mistakes are what kill trust: a made-up number in a report, the wrong customer name in a drafted email.

Once people have to check everything a feature produces, it has added a step to their work.

So every AI feature needs a way out: the pre-filled form can be edited, the drafted reply can be rewritten, the ranked results can be sorted another way. The moment a suggestion becomes a decision, like auto-send, auto-file or auto-approve, the accuracy bar goes way up, and you probably aren't there.

We learned this one ourselves. We ran an AI feature that auto-filed incoming documents into categories for about four months before turning it off. It was right most of the time, but the misfiled ones included some that mattered, and people ended up checking its work more carefully than they would have done the filing themselves.

The features that stuck

The ones that lasted for us remove thinking without adding interaction.

• Pre-filled fields, with no new UI, no chat and no "AI" badge. The form is mostly done when it opens. People didn't notice a feature; they noticed the product got less tedious.
• Anomaly alerts worth interrupting for. "Mobile checkout conversion dropped sharply after yesterday's deploy" is useful because nobody had to ask. Most of the work is filtering out the expected changes (seasonality, promotions) so the alert is rare enough to read.
• Transformations you can check, like summaries, translations and format conversion. The input and output are clear, the person can verify the result at a glance, and a few seconds of waiting buys back half an hour of reading.

What I ask before anyone writes a prompt

1. What does the user do today without it? If the answer is "click three buttons", the AI version has to beat three buttons.
2. What happens when it's wrong? "They fix it in two seconds" is fine. "Nobody notices until it's downstream" is not.
3. Is the wait proportional to the value? Four seconds for a summary of a long document, yes. Four seconds for a search that a keyword index answers instantly, no.
4. Does it remove a step or add one? If people have to review the output before acting, you've added one.
5. Would plain good UX solve it? A date picker beats a natural-language date parser, and a fast search box beats a search chatbot.

Once it ships, judge it by what people do. Watch adoption for weeks, since the first week is mostly curiosity, and measure whether tasks get done faster. The complaint "it always gets company names wrong" is worth more than a dozen "this is cool"s.

If the product's UX is broken, fix the UX first. AI on top of a good product can be great; on top of a bad one, it's an expensive way to make the problem easier to notice.