Building an AI feature involves design decisions that are easy to underestimate. Here are five patterns worth considering, and the factors that should shape how you apply them.
1. AI Input Design: Format, Scope, and Guidance
The input pattern covers three distinct decisions: format, scope, and guidance.
What modality the user interacts through. A text field, a voice interface, a slash command, and a structured form each carry different tradeoffs. A text field gives users maximum flexibility. Voice is faster when typing is impractical, which makes it a natural default for mobile AI features. Slash commands and structured forms constrain what users can ask, reducing failure modes but limiting the range of possible requests. Format shapes not just how users submit requests but what they expect to be able to ask.
What the AI is working from. A user who asks “summarize this” needs the AI to know what “this” refers to: the current document, the selected text, the conversation history, or a connected data source. When scope is implicit, the AI infers it from context. Notion AI operates on the current page by default; selecting text narrows it. ChatGPT operates on the conversation. These are scope decisions made at the product level. The input interface either makes that scope visible to the user or hides it, which shapes whether users can make sense of why the AI responded the way it did.
How much guidance the interface provides. A blank text field offers full flexibility and no direction. ChatGPT shows suggested prompts before the user starts typing, helping new users understand what the product can do without requiring them to already know what to ask. Prompt suggestions, autocomplete, and structured templates all sit on a spectrum between maximum flexibility and maximum constraint. Where a product lands should follow from how well its users can formulate good requests without help. That ability determines whether flexibility is a feature or a liability.
2. Special Instructions: Configuring AI Behavior
Special instructions cover the mechanisms that shape AI behavior beyond its defaults. They operate at two levels: what gets configured at the product level, and what individual users can adjust.
What gets configured at the product level. Some behavior is set once and applies to every interaction: what the AI knows, how it responds by default, what tools it has access to, and what it is and is not permitted to do. GitHub Copilot’s custom instructions file lets development teams define project-wide coding conventions the AI applies automatically. These decisions are made before any user types anything, and they shape the range of what the AI will do for everyone.
What individual users can adjust. Document and context upload, tool connections, tone and format preferences, and scope constraints can all be surfaced as user-level controls. ChatGPT’s custom instructions let users set persistent preferences that carry across all their conversations. A user who uploads a requirements document before asking a question gives the AI context it would not otherwise have. Each of these shifts what the AI produces without changing the underlying model.
The design decision is what belongs at the product level and what gets surfaced to users. Your product goals shape this most directly. A product optimizing for accessibility and simplicity will configure more at the product level. A product optimizing for depth and user control will expose more. Both follow from what the product is trying to help users accomplish.
3. AI Output Design: Format, Placement, Confidence, and Actions
Output covers how the AI’s response is structured, presented, and delivered. Presentation directly affects whether users trust and act on what they receive. Five decisions drive most of that effect.
What format the response takes. Text is the default for most AI products but not always the right choice. Voice matters when users are hands-free or when reading is impractical. Structured formats, such as tables, exportable data, or code, are more appropriate when users need to act on the output programmatically rather than read it. Images convey spatial or visual information that text alone cannot. Format should follow from the task, not from what the AI defaults to.
Where the response appears. Output delivered inline, inside the document, code, or task the user is already working in, signals that the AI is part of the work. Output delivered in a separate panel signals it is something to consult and evaluate before acting on. These carry different implications for trust, interruption, and how naturally users incorporate AI output into what they are doing. GitHub Copilot illustrates both: its inline ghost text appears directly in the code the developer is writing, while its chat panel response appears in a sidebar. The same model, two different relationships to the user’s work.
What the response leads with. A response that opens with the answer respects the user’s time. One that opens with the AI’s reasoning makes the basis for the answer visible, which matters when users need to verify or challenge it. Consider the difference between an AI that says “three tasks are at risk of missing Friday’s deadline” and one that explains how it assessed risk before stating a conclusion. Which comes first reflects a judgment about who the user is and how much they should be expected to trust the AI at that stage of the product’s development.
How the AI signals confidence. AI output is only as reliable as the data and context behind it. A response that presents uncertain or incomplete information as definitive is more dangerous than one that surfaces the gap. Confidence signaling belongs in the structure of the response itself, not in a disclaimer at the bottom. An AI that says “based on tasks updated in the last seven days” is telling the user exactly what the answer is built on, which is what lets them decide whether to act on it. What the model can reliably do with the data it has access to determines what output can honestly claim.
What users can do with the response. Copy, apply or insert directly, regenerate, edit inline, and export are each different signals about how the product expects users to act on AI output. Copy assumes the user will take the content elsewhere. Apply assumes it fits directly into the current workflow. Regenerate acknowledges the response may not be right the first time. Edit inline treats the AI’s output as a starting point rather than a final answer. Surfacing the right actions shapes whether users trust the output enough to act on it.
4. AI Error States: Designing for AI Failure
AI failures take many forms. Four have distinct design responses.
Content quality failures. The AI produces output that is wrong, misleading, or misaligned with what the user asked. This includes hallucinations, where the AI presents fabricated information confidently, and context errors, where the AI answers a different question than the one asked. A user asks about delivery risk for next week and the AI summarizes what the team completed this week. The response is coherent. It answers the wrong thing. Users may not catch it if it sounds plausible, which means the error compounds. The design response is not a better error message. It is a recovery path: a way for the user to correct course without starting over, paired with confidence signaling that makes the basis for the AI’s answer visible before the user acts on it.
Scope and data failures. The AI cannot answer reliably because it can only see part of what it needs. The design response is honest output rather than a confident answer built on incomplete information. An AI that says “here is what I can tell you based on what I have access to” is not failing. An AI that presents partial data as complete is.
System failures. Latency, model unavailability, and rate limits break the interaction just as effectively as content failures. The design response is clear status communication: tell the user what happened, whether they need to do anything, and how long recovery will take. A message that says “try again in a few minutes” is more useful than a spinner that never resolves.
Policy failures. The AI declines to respond because the request falls outside what the product permits. Refusals without explanation damage trust more than the refusal itself. The design response is a plain language explanation of what the AI will not do and, where possible, an alternative path that still helps the user make progress.
How a team designs for each failure type shapes whether users trust the product over time. Poor recovery erodes that trust. Transparent, recoverable failure builds it.
5. AI Feedback Design: Signals, Granularity, and the Feedback Loop
Two types of signals define the feedback pattern and they are complements, not substitutes. Explicit feedback, such as a thumbs up or down, a rating, or a correction, provides precision but requires the user to stop and evaluate. Implicit feedback is collected through the user’s natural actions: accepting or rejecting a suggestion, continuing a conversation, switching topics, or abandoning the AI response and finding the information another way. Google’s People + AI research is direct on this: combining both gives a more complete picture of what users actually found useful versus what they said they found useful.
GitHub Copilot’s accept and reject mechanic is implicit feedback embedded in the developer’s primary task. No interruption required. ChatGPT’s thumbs require a deliberate act outside the flow of the conversation. Both capture useful signals. The first scales without friction. The second provides clarity of intent the first cannot. A product that relies on only one is working with an incomplete picture.
Granularity is a separate decision within explicit feedback. A thumbs down tells you something went wrong. A category selection, such as inaccurate, irrelevant, or off-tone, tells you what went wrong. A free-text correction tells you what should have happened instead. Each level is more useful but requires more effort, which means fewer users will provide it. Progressive disclosure navigates this tradeoff: start with the simplest signal, then offer more depth to users willing to go further. A product that opens with a thumbs down and follows with an optional “can you tell us more?” gets richer signal from users who have something specific to say without losing the users who don’t.
The feedback loop closes when users can see that their input changed something. That shift, from feedback as a chore to feedback as a contribution, is a product design decision. It determines whether users keep giving feedback or stop. A product that collects signals and never visibly acts on them trains users to stop contributing them.
Business objectives are sharpest here. How much data you collect, how transparent you are about collecting it, and how visibly you close the loop all reflect choices about the relationship the product is building with its users over time.
Navigating 4 Competing AI Design Factors
Your users determine what flexibility means in practice. Your product goals determine what the AI is optimizing for. Your business objectives determine what relationship you are building with users over time. Your technical constraints determine what the AI can honestly deliver.
The tension between these factors is where the real decisions happen. A flexible input that serves experienced users creates failure modes for new ones. Surfacing confidence gaps builds honest trust but may undermine perceived capability. Collecting rich feedback data improves the model but requires transparency about how it is used. These are not problems to solve once. They are decisions to make deliberately, revisited as the product learns, and resolved in ways that reflect the relationship the product is building with its users, not just what it is capable of delivering.
