AI Interface Pattern Library
AI Interface Pattern Library
Self-initiated · 2025–2026
For 40 years, interface design has operated on one assumption: software does what you tell it. AI doesn't. The output is probabilistic, failure is often silent, and the user's relationship with the interface is defined less by commands than by negotiation. But the products being built on top of these models are still designed as if the old assumption holds — the same loading spinners, the same error states, the same correction flows, all inherited from systems that never had to guess. I audited six of them to find out exactly where that breaks down, and built a pattern library from what I found.

6
Products audited
6
Pattern categories
23
Standardized prompts
Public
Empirically grounded
My Role
Senior Product Designer (self-initiated)
Methods
Competitive audit, heuristic analysis, pattern definition
Tools
Next.js, React, Storybook, Figma
Status
Phase 1 complete — conversational AI patterns
The Context
Designers working on AI products don't have a shared vocabulary for their failure modes
Most UI pattern libraries were built for conventional software — deterministic systems where inputs produce predictable outputs and failure states are well-understood. AI interfaces don't behave that way. They generate rather than retrieve. They fail silently. They require correction as a routine interaction mode rather than an edge case. What doesn't exist publicly is a pattern library that treats these as a distinct design domain, built from observed behavior rather than first principles. This project is an attempt to build one.
The Problem
The interfaces don't match the outputs they're presenting
When I started using AI products seriously as a designer and researcher, I noticed a consistent gap between what the models were producing and what the interfaces were communicating about those outputs. A response that was partially fabricated looked identical to one grounded in verified sources. A generation that had silently stalled looked identical to one actively streaming. A knowledge gap — something the model simply didn't have in its training data — looked identical to a principled limit, something the model couldn't and shouldn't access.
These aren't aesthetic problems. They're trust problems. And they're solvable — if you can first define what's actually going wrong and why.
The core issue: AI output is probabilistic, but AI interfaces are designed as if it isn't. Every pattern I eventually defined traces back to this single mismatch.
The Framework
Four properties that separate AI interfaces from everything that came before
Before auditing any product, I needed to establish what made AI interfaces distinct enough to warrant their own pattern language. Four properties set them apart from conventional software.
Inherent uncertainty
Model output exists on a confidence spectrum the interface rarely communicates. Unlike a database query, there is no binary correct/incorrect — only degrees of reliability.
Generative output
AI doesn't retrieve — it generates. Responses can be partially correct, confidently wrong, or accurate in ways that are impossible to verify without domain expertise.
Silent failure risk
AI systems fail in ways that produce no visible signal. A hung generation looks like a slow one. A fabricated response looks like an accurate one.
Correction as a first-class interaction mode
With conventional software, correction is an edge case. With AI, iteration is the expected workflow. Most interfaces treat it as an afterthought.
These four properties defined the six pattern categories. The mapping isn't one-to-one — some patterns address multiple properties, which reflects the actual complexity of the problem space.
| Property | Patterns it drove |
|---|---|
| Inherent uncertainty | Uncertainty Communication, Source & Attribution |
| Generative output | Generation States, Source & Attribution |
| Silent failure risk | Generation States, Error States |
| Correction as a first-class mode | Correction & Refinement, Limitation Handling |
The Audit
Six products, 23 prompts, applied verbatim
I audited ChatGPT, Claude, Gemini, Perplexity, Notion AI, and GitHub Copilot using a standard set of 23 prompts written before any product was tested and applied verbatim across all six. Prompts were designed to surface behavior in each pattern category — real-time data requests to test limitation handling, ambiguous correction signals to test refinement flows, network interruption scenarios to test error states.
Two data sources were kept distinct throughout: observed product behavior and model self-assessment. Where divergences appeared between self-reported and observed behavior, they were flagged as findings rather than reconciled.
The Findings
What six products revealed about the state of AI interface design
The most consistent failure in the audit wasn't a product-specific bug. It was a category-wide pattern gap.
Claude
ChatGPT
Gemini
PerplexityAll four indicators loop indefinitely. None distinguish active generation from a frozen state.
No product differentiates between generating and frozen.
The hung generation state — where a spinner continues running with no visual distinction between "still working" and "stalled" — was observed across Claude, ChatGPT, Gemini, and Perplexity. Four of six products. The interface shows identical behavior whether the model is three seconds from completing or has been stuck for three minutes. This isn't a design oversight — the model itself has no awareness of its own generation state. A hung generation is typically an infrastructure failure between the API and the client, which means the interface is flying blind. GitHub Copilot is the only product in the audit that breaks from this: when generation is interrupted, it surfaces the message "Copilot was interrupted before it could finish this message." Simple, specific, honest. No other product does this.
No product uses a visual confidence indicator.
Every product in this audit communicates uncertainty exclusively through language. Not one uses color, iconography, or structural treatment to distinguish a reliable claim from an uncertain one (distinct from model confidence in the technical sense, which refers to token prediction probability — not factual accuracy). The closest exception is Gemini's Double-Check feature — a post-response source verification tool that color-highlights claims as verified or contradicted by external sources — but that's a verification mechanism, not a confidence indicator at the point of generation. The absence of visual confidence design across the entire field is the most striking finding in the audit.
Perplexity cites on nearly every response. Claude presents equivalent claims with no attribution. Inconsistency is a worse trust signal than silence.
Citation inconsistency is a worse trust signal than no citation.
Perplexity cites on nearly every factual response — inline footnotes, a persistent source panel, hover previews, links that resolve correctly. Claude cites on some responses and presents equivalent claims without attribution on others: health benefits of coffee got confident, uncited assertions; a startup failure rate claim appeared with no source. The problem isn't just the missing attribution — it's that users can't build a reliable mental model of when to verify. Inconsistency teaches either constant doubt or misplaced trust.
No product distinguishes "I don't know" from "I can't know."
When a model's training data doesn't include a recent event, and when a model is structurally prevented from knowing something — private communications, unpublished information — the interface response is identical. These are different epistemic states requiring different user responses: one invites a web search, the other doesn't. No product surfaces this distinction visually or structurally.
The clearest anti-pattern
Notion AI hit a usage limit at 20 responses — mid-task, without prior warning — discarded work in progress, and replaced the limitation explanation with a marketing upsell. No progressive disclosure. No graceful exit. This is what limitation handling looks like when it's treated as an edge case.
The positive findings were as instructive. Claude's handling of real-time data requests — searching proactively and disclosing the search — is the correct pattern for capability limitation handling. GitHub Copilot's interrupted state notification is the correct pattern for hung states. Perplexity's source panel is the closest existing implementation of consistent citation infrastructure. The patterns already exist in fragments. The work is naming and systematizing them.
The Principles
Five principles that emerged from 23 prompts across six products
These aren't prior convictions — they're what the data kept pointing to.
Status should be specific, not just present
Generic loading indicators tell users something is happening but not what. AI generation is not a download; it's a reasoning process. The interface should reflect that distinction. An indicator that escalates from "generating" to "something may be wrong" after a defined threshold is more honest than one that runs indefinitely.
Uncertainty should be visible before it's harmful
Every AI response carries some degree of uncertainty. The interface's job is not to eliminate it but to make it legible — and to surface it at the beginning of a response, not buried within it. Absence of uncertainty signaling is itself a design choice. In AI interfaces, it's the wrong one.
Inconsistent citation is more damaging than no citation
Citations exist to give users the information they need to verify claims independently. When a product sometimes cites and sometimes doesn't for equivalent claims, it creates the illusion of accountability without actually providing it. Every empirical claim should be attributed, or the interface should be honest that attribution isn't available.
Limitation handling is a first-class design problem
A good limitation response tells the user what the system cannot do, why, and what they can do instead. Commercial limitations deserve the same honest treatment as technical ones. Users should know constraints exist before they hit them, not at the moment they're blocked.
The most dangerous error is the one users don't notice
Silent failures erode trust in ways that explicit errors don't, because users can't respond to what they can't see. Every failure state should tell the user what happened, what they might have lost, and what they can do next. If the system doesn't know why it failed, it should say so rather than displaying the same animation it shows when it's working.
The Patterns
Six definitions grounded in what the audit actually found
Each pattern definition answers four questions: what problem does it solve, what does it prescribe, what design decisions does it involve, and what tradeoffs exist.
Generation States
Four distinct states minimum: thinking, streaming, complete, and hung. The hung state must escalate to an explicit error-adjacent state after a defined timeout — not continue showing the same animation it shows when working.
Uncertainty Communication
Epistemic banners appear before the response body, not within it. Claim-level uncertainty uses dotted underlines with hover explanations. Three distinct states: knowledge gap, principled limit, and probabilistic claims.
Source & Attribution
Citation must be consistent across comparable claims, inline rather than aggregated, and accessible without a click-through. Absent citation is marked explicitly — its absence should be a deliberate signal, not an interface gap.
Limitation Handling
Three limitation types require distinct handling: capability limits redirect proactively, knowledge limits trigger a web search before responding, commercial limits disclose progressively before the threshold is hit. The ARI structure — Acknowledge, Redirect, Invite — applies across all three.
Correction & Refinement
Vague corrections trigger a Clarification Interceptor rather than blind regeneration. The interceptor presents structured options including inline text selection for targeted rephrasing. All prior versions are preserved and navigable.
Error States
A four-error taxonomy: hung state, network failure, context length exceeded, and policy refusal. Each has distinct visual treatment, specific copy, and a recovery path. The user's prompt is never cleared during any error type.
The Build
Pattern definitions proved in React, documented in Storybook
The pattern library is implemented as a Next.js route within the portfolio repository. Each pattern has three tabs: Pattern Definition, Interactive Demo, and All States. The demos are behavioral rather than visual — they demonstrate state changes, timing, and conditional logic that static frames can't communicate. The Generation States demo runs a live streaming simulation with a watchdog timer that escalates to the hung state after five seconds without new tokens. The Correction & Refinement demo triggers the Clarification Interceptor on vague input and supports inline text selection.
The Outcomes
A research artifact that didn't exist before
What this work does not claim: these patterns are not exhaustive, not validated through large-scale user research, and not final. They are a structured starting point grounded in observed behavior — which is more than currently exists publicly.
A subset of these patterns is in live implementation in the portfolio chatbot at alikhandesign.com/chat. The Source & Attribution pattern drives the citation badge and Source Inspector. The Limitation Handling pattern drives how the chatbot handles questions outside its scope. The Generation States pattern informed the hung state watchdog timer. Sessions are instrumented — pattern triggers, citation events, session continuity, and rate limit hits are logged per conversation. Early signal from that instrumentation is informing the next revision of the pattern definitions. Findings are available on request.
The audit also produced three transferable artifacts: a 23-prompt standard set designed for cross-product comparability, an audit instrument covering six pattern categories with separate tracks for observed behavior and model self-assessment, and a synthesis framework that has already been used to correct one mid-audit finding before it made it into the final output. Each of these is reusable for the next phase of this work.
The next phase — agentic AI patterns — presents a categorically harder design problem. Agentic systems take multi-step actions, fail mid-task, and require trust at a different level than conversational AI. The audit instrument will need to be rebuilt from scratch for it.
The Reflection
Designing for intent, not output
The hardest part was resisting the temptation to solve for interfaces I'd want to build rather than problems I'd actually observed. Several early pattern prescriptions were too prescriptive — they described ideal systems rather than the minimum viable design decisions that address the documented failure. Anchoring every prescription to a specific audit finding kept the work honest.
The deeper shift this work points to is one of framing. Conventional interface design operates on deterministic assumptions — a defined input produces a defined output, and the designer's job is to make that transaction as clear as possible. AI doesn't work that way. Designing for that reality means shifting from prescribing outputs to understanding intent — what is the user actually trying to accomplish — and then building interfaces transparent enough to guide them toward it, even when the system's response is uncertain, incomplete, or wrong. That is a different kind of design problem, and this pattern library is one attempt to name what it requires.
Interested?





