Beyond the Chatbot: 5 Generative UI Patterns That Get AI Features Actually Used
Most teams shipping AI right now have a version of the same problem. The feature works. The model is good enough. Almost nobody uses it.
Banyan Software's State of AI for VMS Operators, published in June 2026 from responses by more than 260 software founders and operators, put a number on it: 51% said fewer than one in four of their customers use the AI features their company built.
There are many reasons a feature can miss, but one shows up often enough to be worth naming. The chat box was the surface that was cheapest to build. A model emits text, a text field accepts text, and the wiring takes an afternoon. That's an excellent reason to prototype in chat and a weak reason to ship in it.
The cost is easy to overlook because it lands on the user rather than the team. A chat box asks people to type in context the application already holds: which record they're looking at, what they did last Tuesday, what "the usual format" means for their team. The product knows all of this. The blinking cursor asks anyway.
The prompt is a tax the user pays on every visit
Jakob Nielsen describes AI as the third UI paradigm in computing history, after batch processing and command-based interaction. He calls it intent-based outcome specification: the user states the outcome they want, and the machine figures out the steps. He also named the catch: the articulation barrier. Reading across literacy research, his estimate is that roughly half the population in wealthy countries can't produce prose precise enough to get good results from a prompt.
Writing skill is only part of it. A CHI 2024 paper, Bridging the Gulf of Envisioning, breaks the difficulty into three gaps: a capability gap (can this thing even do what I want?), an instruction gap (how do I phrase it?), and an intentionality gap (what should I expect back?). It's a framework built from analysis of twelve systems rather than a user study, but the three-way split is useful in a design review. A user staring at an empty input is usually stuck on the first gap, where prompt-writing advice does nothing for them.
Then there's what happens after a prompt lands. In a small qualitative study, NN/g named two behaviors: accordion editing and apple picking. People expanded and shrank a response over and over to reach the length they wanted, and when they liked part of an answer they had no way to point at it, so they described that part again in prose. Eight participants is a small sample, and the pattern rings true to anyone who has watched a user work.
Every one of those turns is work the interface could have absorbed.
Five patterns worth stealing
The two best public catalogs (Shape of AI and AI UX Patterns) list dozens between them. These five carry the most weight for a product that already knows something about its user.
1. Put the action on the object
Shape of AI calls this an Inline Action: ask or direct the AI based on something already visible on the page. CopilotKit's generative UI guide describes the same idea as a surface it calls chatless: the agent communicates with the application through APIs, and the app renders the result as part of its own interface. Its examples include Microsoft 365 Copilot's inline editing, Superhuman's AI triage, and Linear's Insights.
The design work is choosing verbs. For the object under the cursor, which two or three AI actions make sense? Summarize this thread. Draft a reply in our tone. Flag anything that contradicts the contract. The selection carries the context; the click carries the intent; nobody types.
This also solves discovery, which chat handles badly. People find inline actions the way they find every other button: by looking at the thing they were already looking at.
2. Let the app write the first draft of the prompt
AI UX Patterns sorts prompt handling into four levels of abstraction: a direct prompt, a supplemented prompt embedded in a template, prompt variables driven by user selections, and variable composition where whole sections are included or dropped. Most products ship the first one, then discover that output quality varies enormously by user.
Moving one step up costs very little. Patterns like Structured Prompt, Cloze Passage and Prompt Placeholder Values replace the empty field with a sentence containing slots: Write a [follow-up email] to [Acme Corp] about [the Q3 renewal] in [our standard tone]. Those values come pre-filled from whatever is on screen. Shape of AI's Auto-fill and Templates do the same job from the other direction.
Two honest caveats. Structure constrains expression, so keep a route to raw text for people who know exactly what they want. And the slots are a product decision rather than a UI one: they encode which variables actually change the answer, which you learn from real outputs rather than from a workshop.
3. Generate interface, not only prose
CopilotKit's guide splits generative UI by how much visual freedom the model gets. Static means the model chooses among components your team hand-built. Declarative means the model emits a structured specification: cards, lists, forms, widgets, that your frontend renders. Open-ended means the model returns arbitrary HTML and the frontend is mostly a container.
For most product teams, static is the right starting point: predictable, on-brand, testable. The tradeoff the guide is candid about is that the frontend codebase grows in proportion to the number of things the agent can do. When that growth starts to hurt, declarative is the next step, and several specs are competing to define it: MCP-UI, Open JSON UI, A2UI, AG-UI. None has won, so keep the rendering layer thin and the choice reversible.
A second question from that guide belongs in your spec: who decides what appears, the model or your code? Both answers are defensible. They fail in different ways, and teams that never decide get the worst of each.
4. Let people point instead of re-describe
This is the direct answer to apple picking. Shape of AI calls it Inpainting; AI UX Patterns calls it Partial Regeneration. The user selects the two sentences that are wrong, regenerates only those, and keeps everything else.
It's a modest amount of engineering and it changes how the second attempt feels. Full regeneration makes every iteration a gamble on work that was already good. Partial regeneration turns the output into something the user edits rather than something they re-request.
5. Design the wrong answer
A probabilistic feature will be wrong some percentage of the time, and that percentage is measurable. The screen the user sees when it happens deserves as much attention as the one they see when it works.
The catalogs offer a decent toolkit: Citations for anything factual, Caveat for known model limitations, Action plan so an agent shows its intended steps before it takes them, and Verification (AI UX Patterns calls it Agent Action Review & Confirm) for anything that writes to a system of record. Undo matters more than all of them.
The version that costs you the second visit is a confident wrong answer with no way to check it and no way to reverse it.
Running discovery when the output isn't deterministic
Standard discovery produces a happy path and a handful of error states. A probabilistic flow needs something closer to a distribution. Four adjustments do most of the work.
Collect real outputs before you wireframe. Run thirty to fifty realistic inputs through the model and read what comes back. Placeholder copy in a Figma frame is always the right length and always correct, which hides exactly the problems you're designing around.
Write the failure modes into the spec. For each one, two lines: what the screen shows, and what the user can do next. This is where most AI features are actually won or lost.
Settle freedom and control on paper. Which components can the model reach for, and who decides when they appear. Ten minutes of argument early replaces a month of inconsistency later.
Instrument acceptance, not usage. Track accepted, edited, regenerated, discarded, undone. "Regenerated three times, then discarded" is a different problem from "never opened," and a usage dashboard reports them identically.
The chat box still has a job
None of this argues for removing chat. It's the right surface for open-ended exploration, for first-run experiences, and for the genuinely unpredictable requests that no menu can anticipate. The argument is narrower: chat is a poor default for a job your application already understands.
Worth returning to the Banyan numbers, with appropriate caution. Among operators the report classes as furthest along with AI, 37% said AI had improved customer retention, against 2% of everyone else. That's self-reported, and it's correlation: being ahead on AI covers a lot of ground beyond interface design. Still, a gap that wide suggests the distance between an AI feature people return to and one they try once has less to do with the model than teams assume.
It tends to show up in how much work the interface does before the user has to type anything at all.
