The New Broken Product: Why AI-Built Apps Ship Fast and Fail Faster

Aug 27

12 min read

AI tools let teams ship working software in weeks or months. The products that arrive on my desk now aren't unfinished they're incoherent. That's a different problem, and it needs a different fix, we designers have a big role.

Ten years ago, a failing product failed in ways you could spot from across the room. It was late, it was half-built, features were missing, the team ran out of money before it ran out of backlog, but that's not the brief crossing my desk any more.

The products I'm asked to review now are "finished" products. Authentication works, payments clear, dashboards populate the way it suppose to work, the API is documented. A team of 4-5 shipped the product in eight weeks what used to take eight months, because they used AI builders, prompt-to-UI tools and component generators to compress the whole production timeline.

And then nothing happens!

Adoption stalls, trials don't convert, support tickets are piled up around tasks that "obviously" work. Demos go beautifully and pilots go badly, eventually somebody in the room says the word usability out loud for the first time, and I get an email from the customer.

Here's the thing worth naming precisely, because getting it wrong costs months and getting it rights take time and cost.

The product isn't unfinished. It's incoherent. Functionality got optimized. Comprehension didn't. The build outpaced the design, and the gap between them is exactly where your user is standing right now confused.

If you're early in your UX career, pay attention to this, because it's going to define the next several years of your working life. The job isn't greenfield design any more. It's repair, stitching things better and making more clearer. Walking into a functioning, incoherent product and putting the intent back into it is now going to be a core senior skill.

This is how I do it.

First: why do AI-built products break in such predictable ways?

You can't fix the pattern until you understand it. And it is a pattern not bad luck, and not bad tools.

Generation is local. Design is global.

An AI tool builds a screen in response to a prompt about that screen. It carries no durable memory of the ten screens you built last Tuesday. Every output is a locally sensible answer to a locally scoped question.

Coherence doesn't work that way. Coherence only exists across the whole system.

So you end up with a product where every individual screen is defensible and the assembly of them isn't. Nobody made a bad call. Nobody made a system-level call at all. But AI system behaving that way.

The cheapest thing to make is now production code

The old economics of design were simple: sketching was cheaper than wireframing, which was cheaper than prototyping, which was cheaper than building. That gradient is why design discipline made commercial sense.

You explored where exploring was cheap.

The gradient has flattened. When generating a working screen costs about what sketching one costs, teams jump straight to the artifact that feels like progress.

Exploration collapses into production. The first idea becomes the shipped idea, not because it won an argument, but because there never was one.

It looks designed, so nobody checks

This one is genuinely dangerous. AI-generated interfaces have competent spacing, current colour, reasonable type. They look like products that went through design.

Ugly prototypes invite scrutiny. Polished prototypes that are structurally wrong often don’t.

I hear the same sentence from founders over and over: "It looked finished, so we assumed it was."

Your test suite passes. It's measuring the wrong thing.

Engineering has real quality gates unit tests, integration tests, QA. Every one of them asks: does the system do what we specified and is it behaving the same way?

Not one of them asks: can a person who has never seen this before get their job done without any help?

A product can pass 100% of its tests and be unusable. Those aren't contradictory facts - they're measurements of different things. Teams that have only ever measured the first assume they've measured both.

Nobody was holding the mental model

On a healthy team, one person carries the user's mental model around in their head and defends it in every decision such as; what things are called, what they mean, how they relate and what the user thinks is happening etc.

It's never written down, it lives in a person and it comes from experience.

Distribute production across prompts and generated components, and that role quietly goes vacant. Nobody notices, its absence doesn't throw an error.

What you'll actually find when you look in to the design!

Same defect families, over and over, learn to name them. Naming them is half of what makes you credible in the room.

Token drift and component divergence

Fourteen greys where there instead of four. Spacing at 8, 12, 13, 16, 17, 20, 24px with no rhythm. Three type scales. Many button treatments (In some cases, I found 4–8 button styles) for the same semantic action. Modals with three dismissal patterns.

Trivial in isolation. Brutal cumulatively every inconsistency is a small demand to re-learn something already learned.

Users never say this. They say the product feels cheap, or clunky. That's what continuous micro-relearning feels like from the inside.

Missing states

The "happy path" exists, but important and unavoidable real-world states are missing such as; empty, loading, error, partial, offline, permission-denied and limit-reached states. Demo data is usually clean and predictable, but real data is often not. A product should be designed to handle messy, incomplete, and unexpected data without breaking the user experience.

Also consider:

Silent failures - the user clicks repeatedly because there is no clear feedback that an action failed or is still processing.

Keyboard accessibility issues - custom controls may not work properly with keyboard navigation.

Destructive actions without protection - actions such as delete or remove have no confirmation, warning, or Undo option.

A complete product experience should account for what happens when things go right, go wrong, or simply don’t go as expected.

Information architecture collapse

Navigation that mirrors the org chart or the database schema instead of the user's task sequence. Features bolted on as new nav items until nothing has a natural home. Everything at the same visual weight, so the interface communicates nothing about what matters.

And the reliable early symptom: the same object called "account" here, "profile" there, "workspace" somewhere else. Where language has diverged, the underlying model diverged first.

Mobile degradation

Responsive layout is a geometric answer to a behavioural problem. Watch for desktop density crushed into a phone, primary actions outside thumb reach, touch targets under ideal 44×44pt, hover-dependent affordances that don't exist on touch, and zero accommodation for interruption and overall mobile sessions are short and fragmented, and unsaved state disappears.

Accessibility debt

Near-universal in these builds. Low contrast, no focus indicators, unlabelled fields, missing alt text, semantics faked with <div>s, keyboard traps, meaning carried by colour alone. Increasingly a legal exposure, not just an ethical one.

Trust failures

Sharpest in fintech, healthcare, legal, enterprise applications. Consent and fees are buried. Irreversible actions styled identically to reversible ones. No visible audit trail and no answer to "what did I just agree to?" The system does not clearly show its status during long-running processes.

Desirability isn't decoration in these domains. It's mostly a function of whether the user believes the system is telling them the truth.

The audit: five phases, about two weeks

Don't open Figma yet please...

The most common mistake I watch junior designers make on a rescue job is redesigning screens in week one. You'll produce something beautiful the team can't afford to build, and you'll be thanked politely and never called again. So please careful.

Work in this order instead to make it manageable for all stakeholders.

Phase 1 - Frame it (½ day)

Get written answers to five questions:

Who is the primary user, and what job are they hiring this product to do?
Which single business metric is underperforming - activation, conversion, retention, support volume?
How much engineering capacity exists for remediation, over what window?
What's genuinely fixed: stack, component library, brand, regulatory constraints?
What have you already tried?

If they can't name a primary user or a failing metric - that's your first finding, not an obstacle.

Phase 2 - Document the design inconsistencies (1–2 days)

Measure before you interpret. Numbers travel further than opinions.

Count every unique colour value, every font size and weight and line-height, every spacing value. Screenshot every instance of each component type and lay them out side by side. List every distinct term used for each core domain object, find obvious other issues and record.

One artboard showing seventeen button variants side by side has ended more arguments in my career than any written report. Show them, don't argue.

Phase 3 - Map the real flows (2–4 days)

Not the intended flows. The actual ones.

Walk your top three to five journeys yourself again and again, screen by screen, capturing every state. Record where you hesitate, backtrack or guess. You're the first usability participant and your confusion is data, as long as you write it down honestly and hold it lightly.

Mark on the map: decision points, dead ends, irreversible actions, and every moment that demands information the user doesn't have yet.

Phase 4 - Heuristic and accessibility review (4–6 days)

Use an established framework rather than improvising. Don Norman - Nielsen's ten heuristics are still the working baseline; WCAG 2.2 AA is what you audit accessibility against. (By the way I follow Don Norman and Ben Shneiderman)

Dimension	The question you're asking
Visibility of system status	Does the user always know what's happening?
Match to the real world	Is the vocabulary theirs, or the database's?
User control and freedom	Can they undo, exit, go back?
Consistency and standards	Same thing, same name, same place, same behaviour?
Error prevention	Is the mistake made hard, before it's handled well?
Recognition over recall	Is what's needed visible, not remembered?
Flexibility and efficiency	Novices supported, experts unimpeded?
Aesthetic and minimalist design	Is anything here not earning its place?
Error recovery	Plain language, cause, route forward?
Help and documentation	In context, at the moment of need?
Accessibility	Contrast, focus, semantics, keyboard, labels, targets

Phase 5 - Watch real users (6–8 days)

Heuristic review tells you what's likely wrong. Only observation tells you what's actually costing money.

Five to eight moderated sessions, running your top two or three tasks, will surface most of the high-severity issues. Under a week. It changes the conversation permanently.

Two disciplines separate professionals from enthusiasts:

Set a task, not a tour. "Approve a payment to a new vendor" not "have a look around and tell me what you think." Opinions are cheap but observed behaviour isn't.

Don't help. The silence while someone struggles is the finding. Record time-on-task, completion, errors, requests for help.

And record the sessions. A 90-second recording of a real customer struggling with a core task can have more impact than a 40-page report.

Phase 6 - Score and prioritise

Rate every finding on two axes - severity (1: cosmetic → 4: blocks completion or causes irreversible harm) and reach (1: rare → 4: every user, every session). Then plot against implementation cost. You get four buckets you can walk a founder/customer through in ten minutes.

	Low cost	High cost
High severity	Fix this sprint. Non-negotiable.	Roadmap it - named owner, dated.
Low severity	Batch into a consistency clean-up.	Document and defer, explicitly.

That last cell matters more than it looks. Saying out loud "this one isn't worth fixing" is what proves you're prioritizing rather than gold-plating.

Fixing it: bottom-up, not worst-first

The instinct is to fix whatever looks worst. The correct move is to fix from the foundation up, because every layer inherits from the one below it.

Repair screens before you repair tokens and you'll repair every screen twice.

Layer 1 - Tokens. Collapse palette, type scale, spacing, radius, elevation and motion into a small deliberate sets/chunks. Make them semantic (surface-primary, action-destructive) not literal (grey-4, red). This is often a two-week job that dissolves a large share of "it feels inconsistent" complaints without redesigning a single screen.

Layer 2 - Components. One canonical version of each. Full state matrix: default, hover, focus, active, disabled, loading, error, empty. Then document when to use it, not just what it looks like.

Layer 3 - Patterns. Forms, tables, filters, modals, notifications, empty states, destructive confirmations, multi-step flows. Most visible to users, most often overlooked by teams.

Layer 4 - Flows and IA. Now you restructure navigation and task sequences. Highest value, highest cost - and it needs everything beneath it to be stable first.

Layer 5 - Content and voice. Terminology, error messages, empty-state copy, button labels. Microcopy is under-owned and disproportionately powerful. Half of what users call confusion is vocabulary confusion.

Run this as a parallel track, not a freeze. Ask a company to stop shipping while you redesign and your engagement ends. Negotiate 20–30% of capacity for a defined window, and show returns early.

The ten things to get right before anyone writes code

Send this section to founders and engineering leads. It's the cheapest advice you'll ever give and the least often taken.

Define the user and the job before the feature list. One page. Not personas with stock photography - an actual constraint document.
Design the information architecture before any screen. Name every core object, define relationships, fix the vocabulary, publish it. Every later naming decision references this. It prevents most IA collapse on its own.
Build the design system before the second screen, not the fiftieth. Twenty well-defined components beat two hundred vague ones. AI tools will happily generate against a system if you give them one - the failure is having nothing to constrain them.
Prototype and test three flows before production code. Onboarding, the core value task, the highest-risk transaction. Five users, low fidelity, one week.
Specify every state up front. Empty, loading, partial, error, success, permission-denied, over-limit, offline. Unspecified states don't get built and users hit them constantly.
Make accessibility an acceptance criterion, not a phase. WCAG 2.2 AA in the definition of done. Retrofitting costs multiples. (Some customers are still not worry)
Choose a mobile strategy deliberately. Responsive, adaptive, or separate native - all legitimate, all different. Defaulting to "responsive" without thinking is how desktop density ends up crushed into a phone.
Name one owner of experiential coherence. With authority to say no. Distributed design ownership means no design ownership.
Write the copy before the UI. Interfaces designed around real language survive real content. Ones designed around lorem ipsum don't.
Agree the measures before launch. Task completion, time-on-task, error rate, activation, support tickets per hundred users. No baseline means no way to prove improvement - and design stays a matter of taste in every future argument.

And after launch

Add a design QA gate. Engineering QA checks function. Design QA checks fidelity, states, responsive behaviour, accessibility, content. You need both.
Test five users a month. Rotating tasks. Cheap, cumulative, and it stops drift re-accumulating.
Instrument the funnel. Analytics tell you where users fail. Sessions tell you why. Neither is enough alone.
Mine your support tickets. Categorise by root cause. It's the most under-used usability dataset in most companies, and it's free.
Audit the design system quarterly. Count how many production components have diverged from canonical. Entropy comes back unless someone resists it.
Review the whole experience every six months. Products lose coherence by accretion, not by decision. Nobody ever chooses to make it worse.

How to actually get this funded

Your diagnosis is worth exactly as much as your ability to get it acted on. Make sure you communicate the way it is't "hurt" them

Translate into their currency. Don't say "the spacing is inconsistent." Say "we have eleven spacing values in production; standardising to six shrinks CSS surface area and kills this class of bug." Don’t say, “Onboarding is confusing.” Say, “Four out of six users couldn’t complete setup without help. Here’s the recording, and it directly affects the activation metric you showed me.”

Engineers respond to systems, determinism, less maintenance. Founders respond to conversion, retention, support cost, competitive standing. Both respond to evidence. Neither responds to taste asserted as authority.

Never critique without a path. Every finding needs a proposed fix, an effort band, an expected outcome. Critique with no route forward reads as an attack, however right you are.

Credit what went well. These teams shipped a working product, often under real constraint. Say so, and mean it, then put the problem in the process, not the people - nobody was assigned the coherence role, so nobody held it. That's true, and it's far more likely to result in the role getting filled.

The four objections you'll hear!

"Users haven't complained." Users don't file tickets about confusion. They leave. Churn is the complaint.
"We'll fix it after the next feature." Every screen shipped on an unfixed foundation raises the cost of fixing the foundation. Draw them the compounding curve.
"Can't the AI just redesign it?" It can restyle it. Coherence is what happens when decisions are held consistently across a system over time. Tools execute decisions. They don't hold them.
"No budget for research." Five users, one week, one facilitator. Price that against a quarter of engineering spent building the wrong thing.

What this means for your career

The economics of our profession have shifted. Better you know it early than find out late.

The value of producing interface artefacts is falling. Generation is cheap and getting cheaper. If your skillset is "I can make screens in Figma," you're competing head-on with a commoditised capability. That's not a comfortable place to stand.

The value of good judgment is increasing quickly. It means knowing which screens are really needed, using clear and consistent names, identifying which findings matter most, knowing when to say no, and defending decisions with evidence rather than personal preference.

The leverage isn't in the pixels any more. It's in systems thinking, research literacy, and the ability to change how an organisation behaves.

So build these habits on purpose:

Measure before you opine.
Learn to run a usability session properly - set tasks, stay quiet, record everything.
Learn design systems from the token layer up, not the component layer down.
Learn to write and articulate. Most of your influence will travel as prose, not artboards.
Learn accessibility properly. It's becoming table stakes and most of your peers are still guessing.
Learn enough of your domain - payments, lending, healthcare, logistics whichever you are worked on - to be credible about consequences, not just interfaces.

A working product that people can't use isn't a product. It's a functioning system with nobody inside it. Our job has always been to put the person back in the middle of it. The tools changed. The job didn't.

Working through a remediation engagement right now? I'm always glad to talk - get in touch