The AI Answer Is Not the Finished Product

The short answer: Tesler’s Law is a useful way to think about AI UX because a simpler interface does not necessarily mean a simpler task. AI can take on genuine work, but an apparently finished response may leave people to check evidence, resolve exceptions, approve decisions, and recover from mistakes. Good product design accounts for that entire journey—not just the moment the answer appears.

Imagine a customer-service agent working with an AI assistant. A customer says a parcel arrived late and asks for a refund. The assistant produces an immaculate reply in seconds: an apology, an explanation, and a promise that the refund is on its way.

There is one problem. The assistant has not checked whether the order qualifies.

This is a hypothetical example, not a reported incident. But it captures a choice AI product teams encounter constantly: should a system be rewarded for generating a convincing answer, or for helping somebody finish a task correctly?

Those are different achievements.

The interface got shorter. The journey did not necessarily get easier.

A conventional support workflow might force an agent to open an order, read its delivery status, check a policy, calculate eligibility, and compose a response. Put an AI assistant on top and all those steps appear to become one instruction: “Handle this refund.”

The command is shorter. The obligations remain.

If the assistant is connected to reliable order data and properly constrained, it may perform much of that work. That is a meaningful improvement. If it simply drafts plausible language, the checking moves to the agent. If it can issue a refund without controls, the risk moves to the customer, the business, or both.

The design problem is not that AI sometimes gets things wrong. Every workflow has failure cases. The problem is when the interface makes a proposal, a verified fact, and a completed action look indistinguishable.

A good AI product must tell the user which of those three things they are looking at.

What Tesler’s Law gets right—and what it does not

Larry Tesler’s formulation of the law of conservation of complexity asks who should handle an application’s irreducible complexity: the user, the application developer, or the platform developer. Tesler’s own account dates the formulation to around 1984.

It is a design principle, not a physical conservation law. Some work really can disappear when a product automates it or makes a better decision unnecessary. AI systems can also perform tasks that previously required specialist expertise. We should not pretend that every improvement is merely a disguised transfer.

The useful question is narrower: when a product looks easier, which necessary decisions still need to happen—and who is now expected to make them?

Consider the difference between three kinds of AI output:

• Information: “Here is the refund policy that applies to this order.” The interface must show where that information came from.
• Recommendation: “This order appears eligible for a refund.” The interface must show the evidence, unresolved conditions, and what judgment remains.
• Action: “The refund has been issued.” The system must have actually executed an authorized transaction and recorded the result.

These are not interchangeable states. Yet a chat interface can render all three as an equally polished paragraph.

The response is not the product. The reliable transition from request to result is the product.

Faster writing does not always mean faster work

Research is useful here precisely because its findings are not one-directional.

These results are compatible. Assistance can remove difficult work in one context while adding enough checking and correction to slow another. The unit of success cannot simply be “seconds to first draft.”

For an AI feature, ask instead: How long until the user reaches a correct, usable, recoverable outcome?

Design the decision, not just the reply

Return to the hypothetical late-delivery refund. Here is how a team could turn a generic AI box into a trustworthy product workflow.

1. Help the person state the job

“Handle this” is not enough when several legitimate outcomes are possible. Let the agent choose the intent: explain policy, assess eligibility, draft a response, or request a refund. Show the relevant order and customer context rather than expecting the agent to rewrite it in a perfect prompt.

A selector is not a retreat from AI. It is useful product design: it narrows ambiguity before ambiguity becomes an error.

2. Attach evidence before conclusions

The assistant should retrieve the applicable policy version, order status, and transaction history from authoritative systems. Place the source alongside the claim it supports. If the relevant policy or order record is unavailable, say that the refund cannot yet be assessed.

An accessible source is better than a paragraph that merely sounds researched. A source link still requires scrutiny, but it gives the agent something concrete to inspect.

3. Keep drafting separate from deciding

An AI-generated reply can be helpful without being an authorized business decision. Label it Draft response. Do not let “We have issued your refund” appear as the proposed text unless the transaction has actually succeeded.

The safer draft might explain that eligibility is under review. It may sound less impressive. It is more truthful about the system’s state.

4. Put exact rules in the right place

If the refund depends on a known eligibility rule, calculate it from the stored policy and transaction data using tested, deterministic application logic. Use AI to interpret the request or prepare a message, not as the sole authority for the amount to be paid or the account to be charged.

Not every rule is simple. Exceptions, conflicting records, or discretionary goodwill gestures should move into a visibly different path rather than being hidden inside the model’s prose.

5. Make approval and execution observable

Show the proposed refund, reason, supporting facts, and person authorized to approve it. After execution, display a transaction identifier and actual status. If the payment service fails, tell the agent it failed; do not preserve the illusion of success just because the reply was already written.

That final state is a crucial piece of interface design. Without it, a fluent answer can be mistaken for a completed job.

GOODSCOOL JOURNAL / FIG. 02

Read full figure transcript

Fig. 01 · Ownership / decision flow Conceptual framework · not measured performance The answer is only step three. 01 Define intent Choose between explanation, eligibility assessment, drafting and execution. Owner · Support agent 02 Gather evidence Retrieve the actual order record, delivery status and applicable policy. Owner · Data service 03 Prepare draft Generate suggested language without presenting an unperformed action as done. Owner · AI assistant 04 Apply rules Use tested application logic for eligibility and explicit business constraints. Owner · Rules engine 05 Review exceptions Send discretionary or consequential cases to an authorized approver. Owner · Named approver 06 Execute & record Perform the authorized transaction; display success, failure or unknown status. Owner · Transaction service The transfer is the design decision: generation, verification, approval and execution are separate jobs. GoodScool conceptual framework, based on the article's hypothetical late-delivery refund. Stage owners describe a recommended architecture, not an audited system. Read left to right, row by row on desktop; top to bottom on mobile.

Verification needs an interface of its own

We often ask users to “review the AI response” as though review were a single, obvious action. It is not. Reviewers need to know what to compare, what to distrust, and what they can change.

For an AI product, verification might mean checking a policy citation, examining a changed line of code, comparing two document versions, or testing whether the system performed the promised transaction. Each task deserves a different interface.

Here is a practical distinction:

• If the claim depends on retrieved evidence, surface the source and the relevant passage.
• If the system changed something, show the before-and-after difference and make reversal possible where feasible.
• If a decision is consequential, require the appropriate authorization before execution.
• If evidence is missing, make the missing information visible and provide a way to proceed without pretending it exists.

Confidence is especially easy to misdesign. In research published in Nature Machine Intelligence in 2025, Mark Steyvers and colleagues found that longer model explanations could increase readers’ confidence without improving answer accuracy. Read the study.

A decorative “98% confident” badge is not a solution unless that number is meaningfully calibrated for the task. Often the more helpful signal is plain language tied to evidence: Policy found. Delivery status verified. Refund eligibility unresolved.

This is not about adding warning text everywhere. It is about giving the person the information needed for the next responsible decision.

GOODSCOOL JOURNAL / FIG. 03

Read full figure transcript

Fig. 02 · UI teardown / reconstruction Illustrative example · not a deployed support tool A confident sentence is not a verification interface. Before · AI only AI RESPONSE GENERATED Assistant “Your refund has been processed.” The interface supplies neither policy evidence nor an actual payment status. Evidence link Missing Transaction record Not shown A single polished response combines claim, assessment and action into one ambiguous state. After · Verifiable workspace REFUND REVIEW NOT ISSUED Awaiting approval 1 Source record Delivery data linked 2 Policy rule Check complete 3 Authorization Required 4 Execution Not started Request human approval The interface separates evidence, permission and transaction status before telling the customer it is done. 1 Link claims to the underlying order record. 2 Distinguish retrieved facts from rule evaluation. 3 Make authorization a separate decision. 4 Never show success before execution confirms it. GoodScool fictional interface reconstruction, not a screenshot of a commercial product. The interaction shows a pending review state; no simulated refund has actually occurred.

Let the cost of being wrong change the interaction

A writing suggestion and a money movement should not have the same interaction contract.

For a low-stakes action, such as proposing a headline, the product can offer a quick draft with an easy edit or undo. For a refund, it may need verified policy and approval. For decisions affecting health, legal rights, or account access, the necessary safeguards may be more demanding still.

The exact threshold depends on the product, applicable rules, and the consequences of failure. The general product question remains stable: What is the cost of a wrong guess, and what can the user do before that guess becomes irreversible?

This is consistent with decades of human-AI design work. Microsoft’s 18 Guidelines for Human-AI Interaction, published in 2019, call for systems to explain their capabilities and limitations, support correction, and make mistakes manageable. None of those requirements disappears because the interface now looks like a conversation.

In fact, the more natural the conversation feels, the more important the product’s underlying states become.

Measure the finished task, including the invisible parts

Many AI demos measure response speed. A product team should measure completion and reliability across the whole task.

For the refund assistant, a useful measurement plan would include:

These are proposed product metrics, not published GoodScool results. They require a baseline, consistent event definitions, privacy-aware instrumentation, and a comparison with the existing workflow before anyone can claim improvement.

When possible, compare the total of request formulation, system processing, review, correction, and approval time. Some of these phases overlap, so avoid double-counting. And do not reward teams for reducing review time if the real effect is that people stop reviewing.

The fastest workflow is not necessarily the most useful one. The goal is a dependable result at an appropriate cost.

One exercise for the next design review

Choose one AI feature already in your product. Not the most impressive one—the one people depend on to get something done.

Walk through a single realistic request and answer five questions:

1. What does the user think is finished when the model stops typing?
2. What evidence must still be checked?
3. Which rules can the system apply reliably, and which exceptions require judgment?
4. Who can approve, correct, reverse, or escalate the outcome?
5. How will we know whether the entire task improved?

If those answers are missing from the interface, they are probably living in somebody’s memory, an internal document, or an informal review process. That may work in a demo. It is a weak contract for a product people rely on.

The next generation of AI UX will be judged after the answer

An AI product can genuinely eliminate drudgery, spread expertise, and make difficult tasks accessible. The research already offers examples. The opportunity is not to make people perform every old step with a chatbot beside them.

But when generation becomes cheap, the quality of the surrounding workflow matters more. Evidence, permission, correction, execution, and recovery determine whether a promising suggestion becomes a trustworthy service.

Tesler’s Law gives us a useful question about who handles the hard parts. AI adds a more practical one: What happens after the system says it is done?

Design that part well. The answer is only the beginning.