Designing User Experiences for AI-Powered Applications

A product team adds a summarise button to a customer record. The summary reads well, but the account manager cannot tell which notes it used, whether it includes yesterday's call, or what happens if a detail is wrong. The feature generates text successfully while leaving the user's most important questions unanswered.

Designing an AI-powered application means designing the work around the model output. People need to know what they can ask for, what information the system used, what remains uncertain, and how to correct or reject the result. Those needs should influence the interface before the team chooses a conversational layout or adds a decorative sparkle icon.

The aim is useful reliance: people should benefit from assistance while retaining the information and control needed for their task. This article focuses on product workflows and interface behaviour. The examples are proposed design patterns to test with your users, not claims that one layout works for every AI product.

Begin with the task users already perform

Watch the existing process. An account manager preparing for a call may search recent messages, review open issues, and identify commitments that need follow-up. A useful AI feature could shorten that preparation without replacing every part of the workflow.

Identify the expensive or frustrating step precisely. Users might spend most of their time locating source records rather than writing a summary. If so, improving retrieval and organisation may matter more than producing more fluent prose.

Document what a satisfactory outcome looks like. A meeting brief might need current commitments, unresolved questions, and links to the original records. It may not need a long narrative. These requirements give designers and engineers something more concrete than “add AI assistance.”

Observe experienced and occasional users. Experts may want dense evidence and keyboard shortcuts; newcomers may need examples and terminology. Both groups should be able to understand the result without learning the model's internal implementation.

Choose the interaction shape that fits the work

Conversation is useful when the request is exploratory or needs clarification. It can be inefficient for repetitive, well-defined actions. A structured form, an inline suggestion, or a review panel may give users a clearer and faster path.

For a document editing tool, place suggestions beside the relevant passage and let the user accept or revise them locally. Requiring a separate chat to explain which paragraph should change creates unnecessary translation between the task and the interface.

For an analysis task, a conversational starting point may help users express an unfamiliar question. Once the system understands the request, show structured results that can be compared and filtered. A chat transcript should not become the only way to inspect a business dataset.

Use mixed interfaces deliberately. A short request field, explicit scope controls, and a table of proposed changes can work together. The conversational layer helps specify intent; familiar controls help users inspect and manage the outcome.

Explain capability through concrete examples

An empty input box labelled “Ask anything” invites requests the product may not support. Offer examples that reflect real capabilities and available data. “Summarise open support issues for this account” tells users more than a broad promise of intelligence.

Explain scope near the point of use. If the feature searches only selected documents, say so. If it cannot access archived messages or external systems, make that boundary visible when it affects the task. Users should not discover it only after relying on an incomplete answer.

Avoid lengthy onboarding that lists every limitation before anyone can start. Use a concise initial explanation and reveal relevant details in context. A first-run example can show the source panel, edit controls, and result status through an actual task.

Microsoft Research's human–AI interaction guidelines provide a useful research foundation for communicating capability and supporting correction. Apply such guidance through user testing in your own workflow; a checklist cannot determine whether your audience understands the particular feature you built.

Show the evidence that matters to the decision

A summary should link to the records that support important statements. The source link should open the relevant passage or record where feasible, rather than a large document that forces the user to repeat the original research.

Separate retrieved facts from generated interpretation. For example, “Three unresolved support tickets” can link to those tickets, while “The customer may need onboarding help” should appear as a suggestion rather than a verified account attribute.

Show freshness where it changes the decision. An inventory recommendation based on yesterday's snapshot needs a different presentation from one based on a just-confirmed stock lookup. A timestamp is useful only if users understand what was refreshed.

Evidence must respect access controls. A result should not reveal the title, snippet, or existence of a restricted document merely because the AI retrieved it. Test the source panel with the same permission boundaries as the underlying application.

Express uncertainty without decorative precision

A confident writing style does not establish accuracy. Design the interface so users can identify missing information, unresolved conflicts, and unavailable sources. Those concrete conditions are often more actionable than a generic warning that AI can make mistakes.

Do not display a numerical confidence score unless the team can explain what it measures and has evaluated whether it is meaningful for the task. A model-generated percentage can look scientific while giving users little reliable information.

For an extraction workflow, highlight fields that lack a clear source match and let the reviewer inspect the relevant document region. For a recommendation, show the assumptions that would change the result. These cues help the user decide what to check next.

Provide a useful incomplete state. “I found the order but could not retrieve the delivery update” gives the user a path forward. A fluent answer that silently fills the gap is more difficult to detect and correct.

Separate proposed changes from saved changes

Users should always be able to tell whether the system is suggesting an action or has carried it out. A generated draft, a queued job, and a completed external update are different states and need different labels.

Before a consequential operation, present the specific object, proposed change, and expected effect. For a customer message, show the recipient and final text. For a bulk edit, show the affected records and a reviewable comparison of old and new values.

Use controls that match the consequence. Accepting a suggested heading can be lightweight. Sending a message or changing a business record may require deliberate confirmation under the organisation's workflow. Avoid asking users to approve vague instructions such as “continue with the plan.”

After execution, provide a receipt based on the application result. The assistant's statement that it has completed a task should not be the only evidence. Link to the changed record or show a confirmed operation reference where appropriate.

Design interruption and recovery before polishing success

An AI operation may take longer than a familiar form submission. Show that work has started, communicate useful progress where the system can verify it, and offer cancellation when cancellation is actually supported.

Be precise about cancellation boundaries. Stopping further processing may not undo a message that has already been sent. If part of a multi-step operation completed, explain what happened and what remains. Do not replace a complex outcome with a misleading “cancelled” label.

Preserve the user's input through failures and retries. Losing a carefully written instruction after a timeout turns a technical interruption into repeated work. A retry should retain relevant context while clearly indicating whether it creates a new attempt.

Provide a manual route for essential tasks. An account manager should still be able to inspect notes when summarisation is unavailable. The fallback can be less convenient, but it should be findable and operationally complete for the important outcome.

Make correction specific and inexpensive

A thumbs-down control tells the team that something went wrong but rarely fixes the user's immediate problem. Offer direct editing, field-level corrections, and a way to remove an irrelevant source where those actions fit the task.

Distinguish correcting this result from changing future behaviour. A user editing one customer's summary should not assume the system has learned a permanent preference. Explain whether the correction applies to the current draft, the account, or a broader setting.

Keep accepted work stable. Regenerating a whole document after one small correction can undo sections the user already reviewed. Support local revisions or preserve approved sections when the product can do so reliably.

Collect diagnostic feedback without forcing the user to become a tester. An optional reason such as missing source, incorrect fact, or wrong tone can help prioritise improvements. The primary action should still be completing the user's work.

Give review enough structure to be realistic

Human review is useful only when people can perform it within their workload. Presenting a long generated document with a single approve button may encourage superficial acceptance, particularly when many similar items arrive together.

Identify what deserves attention. Show changes, unsupported claims, important quantities, recipients, and actions with external effects. Let reviewers move directly to the relevant evidence instead of reading unrelated context for every decision.

Design batches around manageable units. An editor may review product descriptions by category or source document, while an operations user may need to approve one order at a time. The appropriate unit depends on how mistakes are discovered and corrected.

Measure review effort during testing. If the feature saves five minutes of drafting but adds ten minutes of verification, the product may need a narrower output or better evidence presentation. Generated volume is not a useful substitute for completed work.

Include accessibility in dynamic interactions

AI interfaces often update content asynchronously, stream text, or reveal new controls after processing. Test whether keyboard and assistive-technology users can understand these changes without losing their place or being overwhelmed by announcements.

Keep focus behaviour predictable. Submitting a request should not unexpectedly move focus into a changing result area. Provide a clear way to reach the completed output, sources, and correction controls using the same interaction methods as the rest of the product.

Do not use colour alone to distinguish uncertain fields, accepted suggestions, or failed actions. Pair visual treatments with clear text and semantic structure. Long generated outputs need headings and navigation that remain useful at increased zoom.

Give users control over motion and ongoing updates where relevant. A streaming answer can be visually engaging but distracting during careful reading. A stable completed view should remain available for review, copying, and comparison.

Test behaviour under imperfect output

A prototype that always returns a correct answer tests only the happy path. Include missing evidence, conflicting sources, a plausible factual mistake, slow processing, and a failed external action in usability sessions.

Ask participants to complete realistic tasks without telling them where the mistake is. Observe whether they notice uncertainty, inspect sources, correct the result, or mistakenly believe a proposed action has already happened. These behaviours reveal whether the interface supports informed use.

Record task completion, correction time, mistaken approvals, and recovery success alongside satisfaction. Users may enjoy an interface that produces confident answers while failing to detect important errors. Qualitative enthusiasm and operational performance answer different questions.

Include users who work under time pressure and people with different levels of domain knowledge. A design that works only when a specialist carefully inspects every sentence may be unsuitable for a broad customer-facing release.

## Design the first use and the hundredth use differently

A new user may need an example request and a short explanation of the source panel. A frequent user may find the same guidance distracting. Let contextual help recede without removing access to it, and preserve predictable locations for the controls that matter.

Offer reusable task settings where the workflow supports them. An account manager might prefer a brief grouped by commitments and unresolved issues. Save that as an explicit preference rather than depending on a long conversation to imply it.

Keep defaults visible enough to review. A remembered date range or account filter can become misleading when the user moves to a different task. Show the active scope near the request and make changing it inexpensive.

Test repeated use over several cases, not just the first encounter. Users develop shortcuts and assumptions quickly. Observe whether they still inspect evidence when the answer looks familiar and whether the design makes important differences visible.

Specify the result contract with engineering

Designers and engineers should agree on the states and fields the interface can rely on. A result may include a summary, source references, unresolved questions, and an execution status. If the backend cannot reliably produce one of those fields, the design needs an honest fallback.

Create examples for empty, partial, and malformed responses as well as ideal ones. The interface should not become a blank panel when a model returns an unexpected shape. Validate the result and show a recoverable state that preserves the user's request.

Clarify which status information comes from the model and which comes from application events. Progress labels such as retrieving records or sending a message should reflect actual activity when presented as facts. Generated narration alone is not a dependable progress signal.

This shared contract reduces late redesign and improves testing. It also prevents a polished mockup from promising evidence or control that the implementation does not yet support.

Keep the interface stable as the model changes

Model and prompt updates can alter output length, formatting, refusal behaviour, and the kinds of mistakes users encounter. Treat them as product changes with potential interface consequences, even when no frontend code changes.

Define the expected result structure and validate it before display. The interface should handle missing fields and invalid output gracefully rather than assuming every generated response follows the preferred format.

Maintain a representative evaluation set tied to user tasks. Review both the model result and the surrounding experience after changes. A more detailed answer may score well in isolation while making the actual review screen harder to use.

Start your design work with one complete journey: request, waiting, result, evidence, correction, action, and recovery. If users can understand and control that journey with an imperfect answer, you have a stronger foundation than a polished demonstration built around an ideal response.

---