UX design for AI products: help users finish the task

Consider a hypothetical support product. A customer asks when a bug will be fixed. The support specialist opens the new AI sidebar, copies in the ticket, explains the customer’s plan, and asks for a reply. The assistant produces a polished paragraph. Now the specialist has to check it against the issue tracker and paste it into the reply box.

The demo ends when the paragraph appears. The user’s task ends when an accurate reply is ready to send. The work between those moments belongs in the design brief.

Useful AI product UX starts with that complete task. Choose the interface around the information the user already has, the decisions they must make, and the result they need to leave with. Then test the effort of checking and correcting the output alongside the effort of producing it.

What does a finished task look like?

Write the outcome without naming the technology. For the support product, it could be: prepare a customer reply that accurately explains the current bug status and the available next step.

Agree what makes that reply acceptable. It must refer to the right issue, distinguish a confirmed fix from a proposed one, and avoid promising a release date that nobody has approved. A support lead can judge those conditions. A visually tidy paragraph cannot establish them.

Watch how people complete the task today. They may use saved replies, open the issue tracker, ask a colleague, or combine several methods. Keep the useful parts of that workflow available while testing the AI feature.

Google’s People + AI Guidebook recommends checking whether AI adds value to the user’s problem and considering simpler approaches where predictability matters. Apply that question before deciding how prominent the assistant should be.

Where should AI appear in the product?

In the support example, the ticket screen already identifies the customer and conversation. A “Draft reply” control beside the reply box is worth testing against a separate chat. It could let the specialist review the relevant issue and edit the resulting text in the place where the task ends.

That does not make inline generation the right answer for every request. A question spanning several tickets may need search. An unfamiliar problem may need a conversation. Sending a reply or updating records introduces action permissions that drafting alone does not need.

Use this proposed comparison to choose a prototype, then test it with the intended users.

These options can coexist. A conversation might lead to a draft in the ordinary editor. The design question is how the user carries useful work across that transition without re-entering it.

What should the user be able to inspect?

Show the scope of the request before generation and keep the supporting information accessible afterward. In the support example, the specialist needs to know which ticket, issue, and customer information the assistant used.

Avoid forcing a choice between trusting the paragraph and opening every source from scratch. A disputed statement should have a usable route to the relevant evidence. Showing a document title helps identify a source; it does not demonstrate that the source supports the sentence.

During the prototype review, introduce a complication: the issue tracker says a fix is under investigation, while an old internal note suggests it might ship on Friday. The draft promises Friday. The specialist must be able to find the conflict, remove the promise, and keep the parts of the reply that remain useful.

This is an illustrative test, not a reported client result. It exposes a decision that a clean demo avoids: whether the product helps someone resolve an unreliable answer before a customer receives it.

What happens when the draft is wrong?

Let the specialist edit the incorrect sentence directly. Asking the assistant to regenerate the whole reply may change text the person has already checked. If regeneration is available, make its scope understandable and preserve the user’s edits appropriately.

Keep drafting separate from sending. A request to suggest a reply should not silently authorize communication with the customer. For actions that change records or contact someone, specify the approval, execution, and recovery states with engineering. The guide to AI approval, undo, and human handoff covers those requirements in detail.

The failure path also needs a useful ending. If the assistant cannot establish the bug’s status, the specialist should still be able to write a reply, inspect the issue, or ask its owner. Preserve the ticket and any useful draft. An apology followed by another empty prompt leaves the task unfinished.

How can a team tell whether the experience improved?

Compare the proposed workflow with the current one on relevant tasks. Include an ordinary request, missing information, and a misleading source. Evaluate the final reply as well as the steps taken to produce it.

Record the time spent supplying context, waiting, checking, correcting, and preparing the result for use. Note where the specialist needs outside help. A shorter generation time can coexist with more review work, so keep the full task visible in the comparison.

Hamel Husain and Shreya Shankar’s guide to building AI evaluation systems recommends studying concrete failures before deciding which metrics to track. For this prototype, record exactly what went wrong, such as an unsupported delivery promise, rather than filing every problem under “AI quality.”

Observe whether users find the mistake and recover. An accepted draft is not necessarily a correct draft. Use a reviewer who understands the task to judge the outcome, and investigate disagreements between that judgment and user behavior.

A prototype comparison helps choose what to build next. It does not prove a production improvement across the customer base. Repeat the relevant checks after implementation, including with users who have had little exposure to the feature.

What should an AI product design partner deliver?

Ask candidates to take one task through context selection, output review, correction, and completion. Request a relevant shipped example and an explanation of the team’s role. A portfolio screen alone cannot show who designed the interaction or implemented its behavior.

Agree who owns retrieval and source quality, permissions, interface design, and evaluation. A design engagement should not leave engineering dependencies hidden inside a prototype. Use the AI product design agency comparison, or the comparison of agencies that have designed LLM products for startups, to identify candidates, then compare their proposed responsibilities against the same task.

Humbleteam publishes this guide. Its AI product design offering is one option to assess against those requirements; the same questions apply to its proposals.

Finish the first assignment with a task brief, the working prototype, the examples used to test it, and the unresolved implementation decisions. In the support example, the outcome is a reply the specialist can inspect and finish in the ticket. That is a more useful next release to discuss than a sidebar that can answer almost anything.