RIP, Chat Box: A Guide to Designing AI Interfaces That Are Intuitive and Adaptive

It's very difficult to talk to an LLM, and you probably don't even realize you're doing it wrong.

Let me explain.

You can instruct an LLM to solve a problem in a certain way, but how good its output is depends on how well you articulate it. Are you just stating the problem and asking ChatGPT for a solution?

Or are you clearly explaining the boundaries and the data you have, asking it to research step by step, and binding its answers with a iharnessThe scaffolding around a model: the instructions, tools, checks and constraints that keep its output on track.?

Obviously not. Or at least, not every time.

My last question to ChatGPT was something like this:

"Hey! What are the best South Asian scuba diving destinations for the month of February?"

Point proven! It's not always possible to give an LLM a complete briefing before asking a question, and that's exactly why these chatbots are dying.

Text-based conversational chatbots are slower, need constant human intervention, and can't run on their own.

They're slowly giving way to autonomous, goal-oriented agents. Think Meta Muse, Grok bots and Dots.

There's an increased focus on running background agents in parallel, without constantly asking humans for permission.

To break this constant back-and-forth, new design patterns are emerging (and old anti-patterns are being called out) that make the move to a more intuitive agentic experience easier.

The text-box anti-pattern

Building opaque, simple text boxes for a conversational LLM is now considered a design anti-pattern. Here's why:

• It shifts the burden onto prompt engineering. A plain text box tells you nothing about what the model can do, and forces the user to guess its capabilities.
• It breaks the user's flow, because the user has to keep switching between reading and writing.

Jakob Nielsen calls it the articulation barrier: roughly half the population in rich countries are low-literacy users, so writing a precise prompt is genuinely hard for them.

A CHI 2023 study, Why Johnny Can't Prompt, found that people without AI expertise tried prompts at random instead of systematically, and struggled because they instructed the model the way they'd instruct a human.

These issues are sharply laid out in this piece by Adi Leviim:

Leviim notes that before LLMs, frontend design relied on robust patterns like direct manipulation, structured forms and progressive disclosure. Instead of building on them, we collapsed all of those paradigms into a single, lazy text container.

Then in 2024, every major lab quietly bolted the GUI back on: Canvas, Artifacts, Deep Research.

Cheap wins that make the chat box smarter

The way around this lack of context about the model's capabilities is design that makes the chat box itself more powerful.

Passive, intent-based micro-interaction loops

This is another approach to the text-box anti-pattern, and more broadly to the single dimension of a one-way conversational interface.

In simpler terms: map the user's behavioral patterns and feed that data into the UI, so the interactions feel more natural.

But how do we do this? Here's my take, as a frontend engineer.

Step 1: Study what the user's tasks normally look like

• The creator. Does the user mostly use the LLM as a generative tool?
• The problem solver. Do most of their interactions involve deep research, data collection and analysis?
• The specifier. How much does the user spell out? Do they explicitly state boundaries and conditions for the task?

Step 2: Collect the signals (without using AI)

What data can tell us about the user's interaction patterns, without using AI? We can track itelemetryUsage data the client measures as the user works, such as timings and interaction events, rather than the content they type. like typing speed, clipboard payloads, cursor dwell and text-selection patterns.

Step 3: Close the loop

By feeding this real-time behavioral data into the UI, we can build passive micro-interaction loops that adapt the canvas. Instead of a static text box:

• a generative user is met with rapid formatting presets;
• a researcher sees source-mapping overlays and data-extraction toggles right away.

By translating silent habits into UI affordances, we make the interface respond not just to what the user types, but to how they work.

Human-computer interaction (HCI) research is now heavily focused on how people interact with the interfaces that connect them to AI. Zijian Ding's 2024 paper maps intent-AI interactions across three task types: content curation, atomic creative tasks and complex interdependent tasks. These line up neatly with the user types above.

When to use native rendering (A2UI) vs. the iframe

We've talked enough about how we communicate with the models. But often the reverse is needed: the agent needs data from us. Asking for it through a long, often laggy, textual question feels like a low-effort attempt.

Until now, the go-to answer was rendering custom HTML (forms, text boxes, checkboxes) inside a sandboxed iframe. That approach isn't dead. It's standardized today as iMCP AppsThe MCP extension that lets a tool return an interactive HTML app, which the host renders in a sandboxed iframe..

But Google's A2UI takes the opposite bet: send a description of the UI, not the code.

Here's what that looks like on the wire (simplified):

{"surfaceUpdate": {"surfaceId": "dive", "components": [
  {"id": "root",  "component": {"Column": {"children": {"explicitList": ["q", "dates"]}}}},
  {"id": "q",     "component": {"Text": {"text": {"literalString": "When are you diving?"}}}},
  {"id": "dates", "component": {"DateTimeInput": {"value": {"path": "/trip/dates"}}}}
]}}
{"beginRendering": {"surfaceId": "dive", "root": "root"}}

What are the risks of an adaptive UI?

• Predictability vs. accuracy. A classic CHI study found that users wanted both. Surprisingly, the accuracy of the adaptation mattered more for performance than its predictability. Wrong guesses hurt more than surprising ones.
• Spatial memory breaks. If a button moves, users lose muscle memory. The fix from the same research is the split interface: adaptive suggestions live in their own zone, and the original controls never move. It's a neat design that works with human habits instead of against them.
• Accessibility becomes probabilistic. When the model picks the layout, screen-reader semantics and focus order are no longer guaranteed. A2UI's catalog helps here, because every component is pre-built and pre-audited.
• You can't A/B test a moving target. Traditional usability metrics assume a fixed design.