How to Prevent UX Debt While Utilizing AI

A Chatbot Invents a Refund Policy

Jake Moffatt asked Air Canada’s website chatbot about bereavement fares after a death in his family. The chatbot told him he could book now and apply for a discount within 90 days. No such policy existed. When he applied, the airline refused. A Canadian tribunal ruled against it, ordering Air Canada to pay damages of 650.88 Canadian dollars (CAD), plus interest and fees 1. Tribunal member Christopher Rivers noted that the airline “does not explain why customers should have to double-check information found in one part of its website on another part of its website” 1.

The interface looked finished. It answered confidently, in plain language, in the place a customer would reasonably look. Nobody had checked it before a customer relied on it.

That gap, between work that ships and work that has been verified to function for the people using it, is where User Experience (UX) debt accumulates. Artificial Intelligence (AI) tools let teams produce and release work faster than they can evaluate it. The speed is not the failure. The missing check is.

How AI Speeds Up Production

AI measurably increases how much developers produce. In a controlled experiment with 95 professional developers, those using GitHub Copilot completed a coding task 55.8 percent faster than the control group 5. A field study of 4,867 professional developers at Microsoft, Accenture, and a Fortune 100 firm found participants completing 26 percent more individual tasks, roughly an extra day’s worth of finished items in every working week, though the study did not measure review time 6.

The best controlled evidence so far comes from software development. These studies measure coding tasks specifically, not design work, but the same mechanism, AI compressing the time needed to produce a first version, plausibly applies to drafting interface copy, generating layout variants, and building front-end components. A team that needed a week to reach a clickable prototype can plausibly reach it in a day. We expect design and UX work to follow the same pattern, more output per hour and faster iteration, though comparable studies measuring that effect specifically in design disciplines are still scarce.

Why Evaluation Lags Behind

Faster production creates a second problem once code or design work ships. The problem is not that teams lack the tools to evaluate their work. It is that the pace of AI-assisted production has outrun the organizational habits and time set aside to use them. The AI Productivity Paradox Report 2025, a vendor report published by Faros AI drawing on data from more than 10,000 developers, found that code review time rose 91 percent on teams with high AI adoption, close to a doubling 7.

Generation scaled 26 percent, per the Microsoft field study. Review time, by Faros AI’s separate measure, nearly doubled. What teams accumulate under those conditions is unverified work per hour. Any of that work that reaches users eventually costs more to fix, in support tickets, redesign effort, or legal liability, than it would have cost to check before launch. Fast delivery with real review gates produces good products. Fast delivery without them produces the Air Canada chatbot.

Benchmarks for Judging AI-Generated Work

Evaluation needs criteria that are written down and checkable. Two sets exist already.

The Nielsen Norman Group, a UX consultancy, publishes ten usability heuristics first developed in 1990 8. These remain the common vocabulary for interface review. They ask whether a system shows its current status, matches the language users already use, offers a clear exit from any interaction, prevents errors, and helps users recover from them. A heuristic review walks a screen against that list and names what fails. That work takes an experienced reviewer a morning per flow.

Accessibility has a formal standard. The World Wide Web Consortium (W3C) publishes the Web Content Accessibility Guidelines (WCAG) 2.2, which organize requirements around four principles: perceivable, operable, understandable, and robust. Each principle has testable success criteria at three conformance levels: Level A (minimum), AA (standard), and AAA (enhanced) 9. UK government guidance puts the stakes plainly: “If the service does not meet WCAG 2.2 AA, you may be breaking the law” 10.

The baseline is poor. WebAIM’s 2024 analysis of the top one million home pages found 95.9 percent with detectable WCAG failures, averaging 56.8 errors per page. Because only automatically detectable failures were counted, actual conformance is certainly lower 11. Interfaces have been shipping finished-looking and broken since long before AI. AI raised the rate of production.

Judgment Becomes the Scarce Skill

When producing a screen, a flow, or a block of copy costs almost nothing, the valuable work moves to deciding which of them should exist. That means reviewing generated variants against the heuristics and the accessibility criteria, reading AI-written copy for the fluent, confident fabrication that fooled Air Canada’s customer, and holding the authority to say a thing is not ready.

Recognizing that a plausible answer is wrong requires knowing what right looks like in enough detail to spot the difference at speed.

Building Review Into the Workflow

Knowing what good looks like is not enough on its own. The checks have to be built into the process so they happen every time, not just when someone remembers to ask. The UK Government Digital Service publishes three mechanisms concrete enough to copy. Each operates at a different point in the delivery process.

Mechanism 1: Automated checks during development. Tools such as Axe, WAVE, ARC Toolkit, and SiteImprove scan for accessibility violations while code is being written, before it reaches users 10. The GOV.UK guidance instructs teams to “run tests every time you add a new feature” once a service is in public beta. Many teams also wire these scanners into their build systems, the software that automatically tests and assembles new code before it goes live. Configured this way, a scanner can stop a change from shipping the moment it introduces a violation, catching problems before they reach a user.

Mechanism 2: A formal audit and user testing before launch. GOV.UK guidance states that a service must get an accessibility audit and fix any issues found before it moves into public beta, and that it must be tested with disabled users 10. This is a deliberate gate: work does not go live until a structured review has been completed and its findings addressed. Automated tools catch what they can detect. This step catches what they cannot.

Mechanism 3: Ongoing monitoring after launch. Once a service is live, analytics carry the check. Task completion rates and drop-off points, where users abandon a flow, signal where something is not working 13. These metrics turn user behavior into a continuous audit, surfacing problems that neither automated tools nor pre-launch testing caught.

Together, the three mechanisms cover the full delivery lifecycle, catching problems during development, before launch, and after it. None of them slow production down. Each attaches a verification step costing a few days of work, set against the months of rebuilding, refunds, and lost trust that the same failures cost once a tribunal, a journalist, or a departing customer finds them first.

Spruce DX is the digital experience division of Spruce Technology, helping organizations design and build accessible, human-centered digital products.