The UX of AI: Making AI-Powered Apps Your Users Don't Hate

How do you make software approachable when the same kind of request can produce different quality, formatting, style, and accuracy? That is the opening problem of AI user experience. Kathryn Grayson Nanz, who introduces herself as a senior design and developer advocate at Progress Software, approaches it from the overlap between design, front-end development, and user research. The technology’s capabilities create opportunities, but its variability makes familiar expectations harder to satisfy.

Developers may talk casually about prompt engineering, hallucinations, and retrieval augmented generation. Most users do not share that vocabulary or the understanding behind it. UX bridges the gap between what developers intend and what users experience. A feature’s technical capability means little if people cannot work out how to use it successfully.

AI features now appear in work software, social applications, and operating systems. Their availability does not settle whether they belong in a particular workflow: the ability to add a feature still leaves the question of whether it should be added. When someone encounters a poorly explained feature, tries it, and receives an unexpected result, the disappointment can extend beyond that feature to AI generally. Repeated failures reduce their willingness to try again. Nanz describes the developer–user knowledge gap here as one of the widest she has encountered. There are only so many unsuccessful introductions a product can afford.

The Macintosh offers a useful analogy. Its early graphical interface borrowed vocabulary and workflows from everyday life, supplied visual representations, and walked people through unfamiliar computing tasks. As users became more comfortable, the interface could introduce more technical language and remove some literal explanations.

Nanz compares the control panels in Macintosh System 1 and System 6. Labels such as insertion-point blinking rate and RAM cache would have meant little to a newcomer to System 1. By System 6, low/high volume imagery and turtle-and-rabbit speed icons were no longer doing the same explanatory work. Her placement of AI users somewhere around System 3 is a metaphor for partial familiarity: people may no longer need every literal visual cue, but developers still cannot assume expertise. Existing software mental models provide a starting point; introduce the unfamiliar pieces gradually and explain how to use them.

Chat makes that balance concrete. Opposing message placement, an input field with a send button, and a scrollable history tell users how to begin. But a direct-message interface does not automatically accommodate reference sources, stopping an in-progress response, or agent tools and integrations. Those capabilities need additional interface support.

The comparison between Microsoft 365 Copilot’s research agent and a new Teams chat shows how familiar components can carry different amounts of guidance.

The agent interface gives users more help discovering what they can do. Reusing a text box does not require reusing all the assumptions of person-to-person messaging.

Why not ask AI to generate the interface? Nanz’s concern is that generation draws heavily on existing patterns while conventions for AI interaction are still developing. A familiar-looking screen does not resolve an unfamiliar interaction problem. She treats this as a provisional limitation: the available patterns and tools may change, but designers and developers still need to solve the gaps they encounter now.

An average generated design may be useful for getting started, or sufficient for a quick landing page. New interaction modes require more attention to how people understand and use the system. Begin with the user’s problems and choose flows that reduce those problems. From her research and conversations with users, Nanz groups the work into five concerns: trust, clarity, control, transparency, and meaningful benefit. These concerns organize the interface decisions that follow.

Nanz identifies trust as the largest hurdle. AI can feel like a black box, and users who have encountered hallucinations have reason to question its answers. Promising that one application is uniquely safe or reliable is difficult to substantiate, especially when the application developer does not train the underlying model. Earn trust by making mistakes discoverable and manageable, rather than denying that they can happen.

Citations give users a route from a generated claim to its source. They can inspect where an answer came from without having to accept the assistant as an authority. That source trail also makes the output usable beyond the application. A report, email, campaign, or presentation carries the user’s reputation; unverifiable material leaves them responsible for errors they cannot readily investigate. Generation may finish the application’s task, but it begins the user’s next task.

Choose the source interface to fit the work:

• Tooltips: Show a short relevant quotation near the claim it supports.
• Inline links: Let users open external source pages directly.
• Reference side panels: Support deeper investigation without losing the answer, particularly in research workflows.

External webpages and internal shared-drive documents may need different navigation and access handling. A research-oriented source panel also changes the assistant’s role: it behaves more like a librarian helping users locate evidence than a subject-matter expert whose answer must be accepted.

Agentic workflows add a different trust problem: the system can act, not merely answer. The stakes of the task and the difficulty of reversing mistakes determine how much oversight matters. Nanz recommends showing an action plan and letting the user approve it before execution. The user can inspect the intended steps while they are still proposals.

She points to Claude and ChatGPT agentic experiences as examples of plans and confirmations. Treat approval before execution as the design recommendation here, rather than a promise about every product mode: the historical ChatGPT agent announcement describes confirmation before consequential actions, not mandatory approval of a complete plan for every task. For repeated workflows, Nanz also proposes settings that let users disable repeated approval or allow a flow consistently. Those choices should reduce babysitting without making the agent’s actions inexplicable.

Trust also depends on knowing what kind of content one is looking at. Online arguments about whether a photo or video is real illustrate the burden of constantly investigating authenticity. Some people welcome generated content; others dismiss it as slop or find its resemblance to human work unsettling. Product design has to account for that range of reactions, regardless of the builder’s personal enthusiasm for AI.

Label generated material where that information will help users understand it. Nanz’s examples include disclosure in an app-store description, a digital or visible image watermark, and an asterisk identifying generated text. The purpose is to avoid the impression that the application tried to pass something off without disclosure. When only part of an output is generated, identify that part so users can focus their manual verification instead of treating everything as equally uncertain.

Users need to understand what the system is doing and what will happen next. The ubiquitous sparkle icon captures a temptation to present AI as magic, but mystery offers little help when someone needs to evaluate a result. Descriptive behavior and clear expectations make the system easier to engage with.

Streaming output serves two purposes. It reduces the experience of waiting behind a spinner, and it exposes partial results early enough for users to assess them. A user can prepare a follow-up question, recognize a needed adjustment, or stop an answer that is heading in the wrong direction before the entire response arrives.

It also helps preserve attention. Nanz invokes the xkcd compiling-code scenario: start a process, walk away, and become occupied elsewhere. In Nanz’s illustrative scenario, a one-minute wait turns into a five-to-ten-minute detour through email, Slack, or a phone. The design concern is the effort of re-entering the task after that interruption; keeping users engaged with useful partial output can help them maintain continuity.

Progress explanations can help users follow a request through the system. Nanz compares this to a person explaining the rationale behind a proposal: the explanation gives someone else a way to understand and question it. Her example follows steps from A to F so a user can locate a misunderstanding and provide a more specific correction. She calls this thinking out loud or showing chain of thought. For implementation, distinguish useful progress reports and explanations from a faithful record of internal reasoning: research on reasoning faithfulness shows that displayed reasoning can omit influences on an answer. The useful interface goal is to expose enough task information for the user to intervene accurately.

Changes also need visible locations. When an agent adds or revises content, mark what changed so users do not have to rediscover it by rereading everything. Familiar patterns already cover much of this work: scrolling chat history to a new message, changing the color of revised text, boxing new material, or marking changed code lines. These cues are especially valuable when the user was not watching the area the agent updated.

The metaphor of an intelligent junior coworker is useful partly because delegated work often needs correction. Users must be able to step in and adjust the result. That starts with a prominent stop or override control during generation, agent workflows, and code or script execution. An emergency brake loses its purpose if it is hidden in a menu or depends on a command the user must remember under stress.

After stopping an unwanted action, the next need is often recovery. Nanz connects this to Nielsen’s User Control and Freedom heuristic: people should be able to explore, change their minds, and return to an earlier state without accidentally committing permanent changes. Nondeterministic output makes that safety net especially useful. The right recovery mechanism depends on the consequences of the task; most applications do not need to expose Git-style version control.

For document editing, Nanz suggests undo and redo across the last ten or so steps. That is a design example, not a fixed history-depth requirement. Choose the depth and structure according to how much an action can change and how costly that change is to reverse.

Recovery should also be selective. Generated output often mixes useful and unwanted material; a user may want to keep one revision while reverting another. Requiring a complete regeneration throws away that judgment and makes iteration less precise. Nanz also cites rising token costs as a motivation for targeted rework, without identifying a provider or pricing period. The practical design requirement is to let users specify what should change while preserving what already works.

Integration makes AI useful inside an existing workflow: it can reference internal documents, send email, create calendar appointments, or draft and share content. But users need to understand what they are connecting, what the tool can do, and what using it will demand of them. Transparency makes those commitments legible.

Permission is more than a binary connection switch.

Nanz recommends explicit sign-off for these capabilities. Someone may approve a supervised action once without agreeing to recurring autonomous use. Permission design needs to represent those differences instead of collapsing them into a single yes or no.

Memory needs a corresponding ability to forget. Retaining information from earlier interactions can help future work, but users should be able to inspect what is remembered and decide what stays. Alongside that control, provide a history showing what access was granted and when, with a way to revoke permissions. Approval is an ongoing relationship with the application, not a one-time onboarding event.

Before approving work, users need to understand its resource commitment as well as its steps. Show an expected duration and cost in the units the application uses—money, tokens, or credits. An estimate can still be useful when the exact amount is unknown: it gives someone a chance to narrow or revise a request before committing to more than they intended.

During execution, make it clear when the agent is driving. If it controls the browser, use a banner, sidebar, or outline to indicate that state. This helps users understand what is happening and avoid accidentally interfering with an ongoing process. Keep the signal visible during long-running work, when someone may step away and return without remembering precisely where the agent was in its task.

A feature delivers meaningful benefit only when it helps solve a problem the user actually has. Developers may already know to provide context, specify an output format, break a large task into smaller requests, and iterate. A blank prompt field assumes the user can discover all of that independently. It also asks them to infer what problems the tool supports, how specific to be, which sources to supply, and when an answer needs refinement. Examples, templates, suggested prompts, and guided workflows make successful use easier to recognize and repeat.

Then ask what happens after generation. Where does a search result or spreadsheet analysis go next? Does a generated image need to be printed, posted online, or sent to a friend? Next-step action buttons help turn output into something users can act on. Without a practical destination, generated content can remain a novelty rather than become part of daily work.

Direct integrations can carry that transition further: create a document in word-processing software from a draft, push code to a linked repository, or open a tracking-system ticket from test findings. These destinations should follow the user’s task. The easier it is to move the result into the rest of the workflow, the more useful the AI feature becomes.

AI can generate content, write code, analyze data, and automate work only to the extent that people are willing and able to use it. Hidden activity can make an already skeptical user feel excluded from their own task. Interfaces that remove understanding, control, and autonomy make adoption harder; trust, clarity, control, transparency, and meaningful benefit provide guardrails for confident participation.

Nanz’s closing argument is that improving models shift the product differentiator toward the quality of the experience built around them. What users can see, how they interact, how much control they retain, and how the system earns their trust are implementation decisions as well as design decisions. Developers own those questions whether or not their job title includes designer. Users still need to remain at the center of what gets built.