A four-question checklist decides whether it's worth adding AI to the product

The feature that worked and still failed

A product team at a large health insurer built an AI to write, from scratch, the full opinion of specialists who review coverage-denial appeals. The technology worked exactly as specified. Even so, the specialists stopped using it, and the few who kept using it took longer per case than those who simply ignored the tool.

A quick assessment with the specialists themselves, reported by UX researcher Victor Yocco in an article published on Smashing Magazine this month, found the problem in short order: reading an AI-written opinion carefully enough to sign off on it took as long as writing one from scratch, and the specialist still had to check for errors they would never have made on their own. The feature added work to a task these people already mastered.

The product's second version solved the problem by reversing what the AI did. Instead of writing the opinion, it started gathering the policy clauses and relevant prior decisions for each case, leaving the writing to the specialist. The search step disappeared, review time dropped, and the part of the work the specialist is good at stayed with them. The technology was the same in both versions; what changed was which piece of the task the AI took on.

The break-even line between what AI returns and what it costs

Every interface change charges the user something before paying anything back: rebuilding the mental model of how the tool works, learning where things are now, and deciding how much to trust what the AI delivers. Yocco cites Nelson Cowan's review of working memory (2001), which limits this to about four items held in mind at once, and the three tasks above compete for that same limited capacity.

In enterprise products, an AI feature asks more of the user than a redesigned menu, because it changes what the person does all day. Handing the synthesis to the AI turns the user into a checker; handing over the recommendation too reduces the work to a signature. A study by Sophia Ackerhans and colleagues (2025), found by Yocco, shows this in medicine: doctors who had to sign off on AI-assisted decisions reported a threat to their professional identity, and explanations of the AI's reasoning increased both trust and that threat at the same time.

An AI feature earns its place when what it returns beats what it costs the user to adjust, for one user doing one task.

Victor Yocco, UX researcher and author of Designing Agentic AI Experiences

Yocco calls this point the break-even line: the return comes in three forms, effort removed, errors the AI catches that the person would have missed, and consistency across people doing the same work. A fraud-triage system that raises alerts an analyst would never have raised on their own is an example of a feature above that line: it costs attention, but the catch rate pays for it.

The framework's four questions

Yocco proposes running four questions together, before any design work begins, with someone who actually does the task (an analyst, a support rep, a claims specialist). A short conversation with that person reveals where the mental effort really sits and whether the feature would help or get in the way.

Question 1 asks you to count everything the task demands of the user, including the checking they inherit. Pre-filling a loan number field, for example, costs a few seconds without sustained attention in the manual method; an AI that fills that field shifts the cost to checking it, instead of eliminating it. An AI that flags the three clauses out of 40 documents that conflict with the credit policy, on the other hand, cuts real effort, because the analyst was thinking, not typing.

Question 2 pits AI against the way the user already solves the task, spreadsheets and workarounds included. In an HR example cited by Yocco, using AI to find internal skill combinations nobody would have thought to search for wins on ambiguity and scale; drafting the notification email to a candidate, on the other hand, loses to the current method, because the format is familiar, writing it takes two minutes, and whoever sends it has firm opinions about tone.

Error visibility and automation bias

Question 3 separates visible errors from invisible ones. An AI travel planner that suggests a museum closed that day produces an error that doesn't show up anywhere on the screen; the traveler only finds out at a locked door in Tokyo. A flight that departs before the connecting flight lands is a visible error, because the contradiction is right there on the screen.

A review of decades of human-factors research by Raja Parasuraman and Dietrich Manzey (2010) shows that people trust automated outputs even when they're wrong, in aviation, medicine, and process control. This trust builds up fast and rarely as a conscious decision, and once it's in place, the user stops applying the scrutiny that would catch the error. That's why Yocco recommends mapping the error surface before design: list the three most likely error types, rank each by visibility and consequence, and turn any combination of low visibility with high consequence into a provenance requirement.

What happens to judgment after a year

Question 4 is the most neglected, according to Yocco, and the most expensive to ignore. An experiment by Thomas Dratsch and colleagues (2023) had 27 radiologists read mammograms alongside suggestions from a simulated AI system. After a training round with always-correct suggestions, came a batch of 40 images with wrong suggestions planted in 12 of them.

The result: the more experienced radiologists, with an average of 15 years of practice, got the correct category right in 82.3% of cases when the suggestion was correct, but only 45.5% when it was wrong. Among the less experienced, accuracy dropped from 79.7% to 19.8%. Experience softened the effect, but didn't prevent it. A year spent delegating the same judgment call without exercising it leaves a professional worse off than those radiologists were at the start of the experiment.

The mechanism Yocco recommends to avoid getting there is simple: periodic blind review, in which the user forms their own opinion before seeing what the AI produced; rotating a slice of cases without AI assistance; or a weekly comparison between the machine's output and a human-made version. A line in the training manual doesn't solve it: the mechanism needs to be in the workflow.

The same test applied to meeting summaries

Yocco also runs the audit on a feature common in collaboration products: automatic meeting summaries. On question 1, the result varies by segment: people who never took notes gain net effort, but those who always wrote up the minutes and distributed them inherit the checking, and the answer changes depending on who's on the other side of the screen.

On question 2, the summary beats the alternative of someone typing while half-listening, which produces incomplete notes. On question 3, a summary that assigns a commitment to the wrong person looks identical to a correct one, and nobody rereads the transcript to check: low visibility with real consequence turns into a requirement for a timestamp linked to each action item. On question 4, nobody loses a skill worth protecting by giving up manual minutes, so the feature passes without needing an extra mechanism.

The 60-minute version, to run before the next roadmap

Yocco closes the article with a compact version of the audit, designed to fit into a single meeting:

1. Describe the task precisely (10 min). At the level of one user, in one session. "Help a mid-level financial analyst find the three highest-risk items in a 40-page report, within a two-hour review window" works; "help users summarize documents" is too vague to assess.
2. Answer the four questions with whoever does the work (25 min). The read of the person who actually performs the task on where the effort really sits is worth more than any estimate from the product team.
3. Map the error surface (15 min). List the three most likely error types and rank each one by visibility and consequence.
4. Write the conditions into the brief (10 min). Provenance display, verification prompts, segment scope, and skill-retention mechanism go into the same document that describes the feature, not into an appendix afterward.

What this changes for whoever decides what goes on the roadmap

Yocco cites Everett Rogers's (2003) concept of pro-innovation bias: the assumption that new capability is already progress, before anyone checks the benefit, boosted by the competitive pressure of a rival's announcement turning into an internal mandate. The four-question audit doesn't replace the decision of whether to build or not: budget, strategy, and commitments already made still carry weight, and no question accounts for that.

The practical value is in bringing conditions, not a yes-or-no verdict, to the product review meeting. Naming the segment the feature serves already turns the answer into a "yes" for someone. Delivering the error surface as a requirement with an associated cost gives a PM something to act on, a timestamp requirement behind every attributed decision, for example, which a vague worry about "users might not trust it" can never do on its own.