UX Patterns for LLM-Powered Features in SaaS Products

Every LLM-powered feature ships with a set of UX decisions that are easy to get wrong because they're new. These decisions are a core part of AI product design — and the patterns that work have stabilized enough to apply with confidence. Unlike form patterns or navigation structures, there's no 20-year canon of established best practices for LLM interfaces. Most teams are improvising.

The good news is that enough products have shipped in the last two years that some patterns have stabilized. The following eight are the ones that appear consistently in well-designed LLM features — not because they're fashionable, but because they solve real user problems.

For each pattern, I'll cover what it is, when to use it, and what signal it sends to the user about how the system works.

Pattern 1: Streaming Text Output

What it is: Displaying LLM output progressively as tokens are generated, rather than waiting for the complete response before rendering.

When to use it: Almost always, for text-heavy outputs where response time exceeds 1-2 seconds. The exceptions are short outputs (under ~50 tokens), structured data outputs (tables, JSON) where partial rendering creates confusion, and background processing tasks where the user isn't waiting on a screen.

What it signals: The system is working, not frozen. Users interpret a blank screen as either loading or broken; a streaming response is unambiguously neither. It also creates a sense of watching the AI think, which matches how many users understand LLMs to work — and that match between mental model and behavior builds trust.

Implementation notes: You need a stop/cancel control that's visible throughout streaming. Decide upfront how to handle formatted outputs (markdown, bullet lists, code blocks) during streaming — rendering markdown mid-stream can look broken. Some products stream plain text and then render formatted output after completion, which is a reasonable compromise.

Pattern 2: Regenerate and Refine Controls

What it is: A control (usually a button or icon) that lets users re-run the same prompt to get a different output, and optionally a way to give directional feedback for a refined version ("make it shorter," "use a different tone").

When to use it: Any time the output is variable — writing, summarization, brainstorming, code generation. If your feature always returns the same output for the same input, regenerate doesn't make sense. But for generative features where quality varies, regenerate is essential.

What it signals: The first output isn't the final answer. This is an important mental model shift for users who come from deterministic software — they need to understand that querying the AI is the beginning of a process, not a single transaction. Showing a regenerate button communicates this.

The refinement variant: Rather than just "try again," refinement controls let users give direction: "Make it more formal," "Focus only on the cost section," "Give me three options instead of one." These can be predefined quick-action buttons (useful for novice users) or a free-text refinement input (useful for power users). Some products offer both.

Avoid: Auto-regenerating without user intent. If your product silently retries when the first output seems poor, users can't build a mental model of when the system is being helpful vs when it's working around its own failures.

Pattern 3: Prompt History

What it is: A searchable or browseable list of previous prompts and their outputs, accessible from within the feature.

When to use it: When users are likely to return to previous work. Writing tools, research assistants, code generation features, and any AI feature that produces artifacts users will want to refer back to. Not necessary for ephemeral use cases — like a quick summarization or a one-off lookup — where users are unlikely to return to specific past outputs.

What it signals: The system respects your work and remembers it. History also implicitly teaches users what kinds of prompts work well — seeing your own previous queries is a form of prompt education.

Design considerations: History needs search to be useful past a handful of entries. Consider what to store: just the prompt, just the output, or the full conversation? For most use cases, storing the output (or the artifact produced) is more valuable than the prompt. Users remember what they made, not what they asked.

The privacy dimension: If your product is multi-user or multi-workspace, be explicit about whose history is visible to whom. Individual prompt history should be private by default.

Pattern 4: Feedback Thumbs (Good / Bad Output)

What it is: A simple binary rating control — typically thumbs up / thumbs down or a checkmark / X — on AI-generated outputs, allowing users to signal whether the output was useful.

When to use it: In any production AI feature where you're collecting training signal or tracking model performance. The threshold for including this pattern should be low — it costs users almost nothing and gives you valuable data.

What it signals: The system is learning and cares about quality. Feedback controls also give users an outlet for frustration when the output is wrong, which meaningfully reduces the emotional cost of AI failures. A user who can mark an output as bad and move on feels more in control than a user who just has to accept a wrong answer.

Common mistakes:

• Showing the feedback control too eagerly (before the user has had a chance to evaluate the output)
• Showing it too subtly (only on hover, or in a menu) — it then captures too little signal
• Asking for extensive feedback every time (a "Why was this bad?" modal that appears immediately after thumbs-down burns users fast)

The better pattern for collecting rich feedback: show thumbs down immediately, then offer an optional follow-up. "What went wrong?" as a secondary step that users can skip.

Pattern 5: Context Window Indicators

What it is: A visual indicator showing how much of the available context window has been used — essentially a "memory gauge" for your AI feature.

When to use it: In chat-style interfaces or long-running sessions where conversation history matters. When users can upload documents, when they can paste large amounts of text, or when the session persists across multiple turns. Less relevant for single-turn, stateless AI features.

What it signals: The AI has limits on how much it can remember or process at once. This is a concept that confuses many non-technical users, and making it visible prevents the jarring experience of the AI seemingly "forgetting" earlier parts of a conversation without explanation.

Design approaches:

• A simple progress bar ("Memory: 40% full") is the most intuitive but requires calibrating what "full" means in terms the user can relate to
• A word or character count ("~12,000 words remaining") is more precise but requires users to estimate their own content
• A qualitative indicator ("Lots of room" / "Getting full" / "Near limit") is the most approachable but the least precise

Whatever approach you use, pair the indicator with a clear explanation of what happens when the context window fills — does the AI start forgetting older messages? Does it refuse new inputs? Users need to know the consequence to take the indicator seriously.

Pattern 6: Citation and Sourcing

What it is: Inline references linking specific claims or pieces of information in an AI output back to the source document, database record, or web page the model drew from.

When to use it: Any time the AI is working from specific documents or data the user has provided or that your product has access to. Contract analysis, document Q&A, knowledge base search, customer support with access to help articles, research tools. Also valuable for any output that makes factual claims the user might want to verify.

What it signals: The AI's output is grounded, not generated from thin air. Citations are one of the highest-impact trust features in document-focused AI products. Users who can click a citation and confirm the AI got it right build trust rapidly. Users who trust AI responses but can't verify them are one incorrect output away from losing confidence entirely.

Design details:

• Inline citations work better than footnotes for document AI — users want to see the connection at the point of the claim, not scroll to the bottom
• Show a preview of the source on hover, and a link or modal to the full source on click
• When the AI synthesizes across multiple sources, attribute each claim to the most specific source
• Be honest when sources are limited or absent — "I couldn't find a supporting source for this" is more trustworthy than an unattributed claim

Pattern 7: Edit-in-Place for AI Suggestions

What it is: Making AI-generated content directly editable in the interface, so users can modify the output without copy-pasting it elsewhere.

When to use it: Whenever the AI produces text, code, or structured content that the user will use or act on. Writing assistants, email drafters, code generators, document summarizers, proposal generators. This is the pattern that turns AI from a "generate and copy" workflow into an integrated editing experience.

What it signals: The AI's output is a starting point, not a finished product. This framing is accurate and healthier for user trust than presenting AI outputs as definitive. When users know they can edit, they approach outputs more critically — which means they catch errors and improve quality, rather than passively accepting whatever the model produced.

The workflow implication: Edit-in-place changes what users do after they receive an output. Instead of copying text to a separate document, they work in your product. This has compounding retention benefits — users who edit AI outputs in your product are more invested in your product.

Common mistake: Making the AI content read-only, then offering a "Copy to clipboard" button. This treats the AI as a separate system from the rest of the product. Edit-in-place integrates them.

Pattern 8: Tone and Format Controls

What it is: UI controls that let users adjust the style, length, or format of an AI output — before or after generation. Common variants include: length (short / medium / detailed), tone (formal / casual / technical), format (paragraph / bullet list / numbered list / table), and audience (expert / non-expert / executive summary).

When to use it: Writing-heavy features where output style varies meaningfully by use case. Content generation, email drafting, document creation, customer communication tools. Less relevant for factual Q&A, code generation, or data analysis where the user cares about correctness more than style.

What it signals: The AI understands that the same information can be presented differently for different purposes. Tone and format controls also reduce the need for users to write complex prompts specifying style — they can set it once in the UI and focus their prompt on content.

Design approach: These work best as persistent settings (set once, apply to all outputs) for users who always work in the same style, with the ability to override per-query for exceptions. A sidebar or header panel works better than per-output controls for persistent settings. Per-output controls (quick-action buttons after generation: "Make shorter" / "Make formal") work for one-off adjustments.

The tradeoff: Adding too many tone/format controls before a user has tried the product at all introduces decision paralysis. Consider hiding advanced controls behind a toggle or showing them progressively as users demonstrate familiarity with the basic feature.

Combining Patterns Thoughtfully

These eight patterns aren't a checklist to implement all at once. A first-version LLM feature in a SaaS product might include streaming output, a regenerate button, and basic feedback thumbs — and that's enough to ship and learn from.

The patterns you add should solve real user problems you've observed: if users are frequently asking "can you make this shorter?", add format controls. If they're asking "where did you get that from?", add citations. If they're copying past outputs back into the input to build on them, add prompt history.

For a detailed look at how these patterns apply to the broader design of AI products, see the guide on designing AI product interfaces that users trust. For the specific challenge of handling AI failures and errors, the post on AI error UX design covers that in depth.

Good LLM feature design is cumulative. Each pattern you add well makes the product more capable and more trustworthy. Each pattern you add poorly adds noise and confusion. The filter is always: does this pattern solve a problem I know my users have, and does it do so without adding complexity they'll have to learn?

---

Frequently Asked Questions