AI UX and Interaction Design
Why most AI features go unused, the inline-vs-destination decision that determines adoption, and how generative UI replaces the chat box.
TL;DR
- Most deployed AI features go unused because they require a "detour" from the user's actual workflow. Build AI inline, at the point of decision, not as a destination.
- The blank page problem (an empty text box with "Ask me anything") puts the entire cognitive burden on the user. Structured interfaces outperform chat for most business workflows.
- Generative UI lets agents render forms, tables, and interactive components instead of walls of text. The agent assembles the interface. The designer designs the primitives.
The AI usage gap is real. Companies deploy AI features, announce them in all-hands meetings, and watch adoption plateau at single-digit percentages. The problem is not user sophistication or training. It's product architecture.
Most AI features are built as destinations: a separate tab, a chat sidebar, a standalone tool the user must navigate to, formulate a query for, interpret the response from, and then manually carry the result back to where they were working. Every step in that detour loses users.
The AI detour
Count the steps a user takes to get value from a typical "destination" AI feature:
- Notice the AI feature exists
- Leave their current workflow to navigate to it
- Figure out what to ask (the blank page problem)
- Wait for the response
- Interpret whether the response is useful
- Manually transfer the result back to their original context
Six steps. Most users bail before step 3.
Compare this to inline AI: the user is writing a document and a suggestion appears in context. They accept or dismiss with a single keystroke. One step. No detour.
The test for any AI feature: can a new user get value without knowing AI is involved? If yes, you've built it inline. If no, you've built a destination, and you've accepted single-digit adoption as your ceiling.
Inline vs destination: the architecture decision
This is not a UX preference. It's a product architecture decision that determines adoption, cost structure, and competitive position.
| Inline AI | Destination AI | |
|---|---|---|
| User experience | AI surfaces at the point of decision. No context switch. | User must leave workflow, formulate query, return with result. |
| Adoption curve | Gradual, often invisible. Users adopt without realising. | Requires deliberate behaviour change. Training-dependent. |
| Discovery | The feature announces itself through the workflow. | Buried in a menu, tab, or separate app. |
| Inference cost | Runs frequently on small, focused tasks. Predictable per-interaction cost. | Runs infrequently on large, open-ended queries. Variable cost. |
| Competitive moat | Deep workflow integration is hard to replicate. | Chat interfaces are commoditised. Anyone can bolt one on. |
Most products should default to inline. Reserve destination experiences for genuinely exploratory use cases where the user needs an open-ended conversation: research analysis, creative brainstorming, complex troubleshooting with back-and-forth.
Even then, consider whether the destination experience can be triggered from within the workflow rather than requiring a separate navigation.
The blank page problem
An empty text box labelled "Ask me anything" is the worst possible interface for most business users.
It requires the user to know what to ask. To understand the system's capabilities. To formulate a query in the right way. To do all of this with no guidance, no structure, and no feedback until after they've submitted.
This works for power users who already know what they want. It fails for everyone else. And "everyone else" is 90% of your user base.
Structured interfaces outperform chat
Replace the blank page with structure:
Pre-populated options. Instead of "Ask me anything," show the three to five most common actions. "Summarise this document." "Find related contracts." "Draft a response." Give users a starting point.
Form-based inputs. For known workflows, a form with dropdowns, date pickers, and text fields produces better results than freeform text. The form constrains the input, which constrains the model's behaviour, which improves output quality.
Contextual triggers. Surface AI actions where they make sense. A "Generate summary" button on a document page. An "Explain this metric" link next to a chart. A "Suggest next steps" prompt after a meeting transcript loads. The context provides the input. The user just confirms.
Progressive disclosure. Start with the most common actions. Reveal advanced capabilities as the user demonstrates familiarity. Don't overwhelm new users with the full breadth of what the AI can do.
The pattern is consistent: the more structure you provide, the higher the adoption. The less the user has to think about how to use the AI, the more they actually use it.
Generative UI
Traditional AI features return text. The user reads a paragraph, extracts the relevant information, and acts on it. Generative UI changes this by letting agents render interactive components: forms, tables, charts, date pickers, confirmation dialogs.
Instead of the agent saying "I found three available slots: Tuesday at 2pm, Wednesday at 10am, or Thursday at 3pm," the agent renders a date picker with those three slots pre-selected. The user taps one. Done.
Instead of a paragraph describing quarterly performance, the agent renders a dashboard with the key metrics, trend lines, and variance highlights. The user scans visually instead of parsing text.
What changes for product teams
Designers design primitives, not screens. In a generative UI system, the designer creates a library of components (cards, tables, forms, charts, alerts) with defined interaction patterns. The agent decides which components to assemble and what data to populate them with. The designer ensures every possible assembly looks coherent and usable.
The component library is the product's vocabulary. An agent can only render what exists in the component library. Expanding what the agent can do means expanding the component library. This is a design decision, not an engineering decision.
Layout becomes dynamic. The same query might produce a single card (simple answer), a table (comparison), or a multi-panel dashboard (complex analysis) depending on the data. The layout system must handle this variability gracefully.
Error states need visual design. When the agent is uncertain, the UI should communicate that visually (dimmed confidence, yellow warning borders, explicit "I'm not sure about this" indicators), not through a paragraph of caveats.
The copilot-to-autopilot UX spectrum
Different autonomy levels require different interaction patterns. Copying the same UX across the spectrum is a common mistake.
Copilot UX. The user is in control. Show suggestions inline, make them easy to accept or dismiss, provide an edit path. The AI should feel like autocomplete, not an assistant demanding attention. Key principle: never interrupt the user's flow.
Co-driver UX. The agent proposes a plan. Show the plan as a reviewable list of actions with clear approve/reject/modify controls. Let the user edit individual steps before confirming. Key principle: transparency of intent before execution.
Supervised autopilot UX. The agent works in the background. The UI is a notification when something needs attention or when a task completes. Show a feed of completed actions with enough detail to audit, not so much that it becomes noise. Key principle: surface exceptions, not routine.
Full autopilot UX. The agent runs autonomously. The UI is a dashboard showing aggregate outcomes, trend metrics, and alerts. The user reviews periodically, not continuously. Key principle: outcome visibility without operational noise.
Confidence indicators and graceful degradation
Users need to know when to trust AI output and when to verify it.
Explicit confidence signals. Mark high-confidence outputs differently from uncertain ones. A simple visual indicator (green check, yellow caution, red flag) communicates more than a paragraph of caveats. Let the user calibrate their review effort to the AI's confidence level.
Graceful degradation. When the model fails, is unavailable, or produces low-confidence output, the product must still function. This means: fallback to non-AI workflows, clear messaging about what happened, no dead ends. If the AI can't generate a summary, show the source document. If the agent can't complete the task, hand off to a human with full context preserved.
Source attribution. For information retrieval and analysis, show where the AI found its information. Not as a footnote nobody reads, but as inline citations the user can click to verify. Attribution builds trust incrementally with each correct reference.
Voice and multimodal interaction
Voice-native interfaces are a distinct design challenge. The interaction patterns that work for text fail for voice, and voice surfaces unique problems.
Latency is fatal. A 3-second delay in a chat interface is tolerable. A 3-second silence in a voice conversation feels broken. Design for sub-second responses where possible. Use filler responses ("Let me check that for you") to maintain conversational flow while the model processes.
Context is implicit. Voice users provide less structured input than text users. The agent must infer more from less: tone, pauses, partial sentences, corrections mid-stream. Build broader interpretation into voice workflows.
Error recovery must be conversational. In text, users can re-read and re-prompt. In voice, the error disrupts the flow. Design recovery paths that feel natural: "I want to make sure I got that right. You'd like to reschedule for Thursday?" Confirmation through conversation, not through "please try again."
Handoff to human must be seamless. When a voice agent reaches its limits, transferring to a human agent must preserve full context. Repeating everything to a human after spending two minutes with an AI agent is the fastest way to destroy trust in the entire system.
What AI UX-focused PMs look like
| Behaviour | In practice |
|---|---|
| Inline by default | Defaults to building AI into existing workflows. Requires a strong case before building a destination experience. Measures the AI detour in every design. |
| Structure over chat | Replaces blank text boxes with pre-populated options, contextual triggers, and form-based inputs. Treats chat as a fallback, not the starting point. |
| Component thinker | Works with designers on the component library that constrains what agents can render. Expands agent capability by expanding the vocabulary. |
| Confidence-aware | Designs different UX for different confidence levels. Builds graceful degradation into every AI feature. |
| Measures adoption, not deployment | Tracks how many users actually get value from AI features, not how many features were shipped. The usage gap is the metric. |
The anti-pattern: the AI tab
The team ships an AI feature as a new tab in the navigation. It opens a chat interface. The placeholder text reads "How can I help you today?" It's announced in a company newsletter.
First-week usage is strong because people are curious. Second-week usage drops 60%. Third-week usage is the power users who would have been fine with the raw data anyway. The AI tab joins the graveyard of features that exist in the product but not in anyone's workflow.
The fix: delete the tab. Embed the same capability into the three screens where users spend 80% of their time. Show contextual suggestions where the data lives. Let users act on AI output without leaving their current view.
The best AI features don't have their own page. They make every other page better.