Designing for LLM Behaviour | Interaction Design Studies

Designing for LLM Behaviour

Raphaël.D

Get In Touch

Get In Touch

UX EXPLORATION

ARTIFICIAL INTELLIGENCE

CONVERSATIONAL UX

Q1 2026

Designing around unpredictable behaviour

When designing conversational AI, I found that some of the hardest questions arise after the user presses Send.

A response can arrive piece by piece, take longer than expected, or sound convincing without enough evidence to support it. Each situation raises different questions about what the interface should communicate and how much control the user should have.

In this exploration, I revisit three of these challenges: Token Streaming, Model Latency and Grounding & Uncertainty.

I share the interaction decisions I arrived at, the compromises behind them and the questions I would still want to test.

The Conversational Composer

The composer is where every conversation begins. Yet typing a question, attaching documents, using voice input and stopping a response all require different interactions.

I explored how one component could accommodate these behaviours while remaining familiar, regardless of what the user is doing.

Welcome

Draft

Generating

Attachment

Upload Error

Voice Input

A minimal starting point, with suggested prompts to help users begin without overwhelming the input.

LABEL

How much should change when the task changes?

As little as possible. The composer should remain familiar whether someone is typing, speaking or working with documents. Only the controls relevant to the current interaction need to change.

LABEL

What needs to stay within reach?

Text input, attachments, voice and a single primary action. Additional file options sit behind the + control rather than competing for space. explicit technical choice when users need it.

LABEL

What needs to stay within reach?

Text input, attachments, voice and a single primary action. Additional file options sit behind the + control rather than competing for space. explicit technical choice when users need it.

LABEL

What happens after Send?

Stop takes the place of Send, in exactly the same position. The composer stays put, even as the conversation changes state.

LABEL

What happens after Send?

Stop takes the place of Send, in exactly the same position. The composer stays put, even as the conversation changes state.

LABEL

What does this simplicity cost?

Disabling other inputs during generation keeps the interaction focused, but prevents users from preparing their next message. I would want to test whether that restriction is worth keeping.

Token Streaming

LLMs generate answers progressively, often displaying text before the response is complete. This lets people start reading sooner, but also introduces uncertainty about what is still being generated.

I explored how to keep the experience readable and predictable, whether the response finishes, gets interrupted or encounters an error.

Waiting

Generating

Stopped

Error

Complete

A subtle activity indicator confirms the request is being processed, with contextual feedback when available.

LABEL

How do you design a response that isn't finished yet?

I treated streaming as one continuous response, rather than a series of separate states. Text stays in the same position as it grows, and completing the response doesn't change its layout.

The challenge was to communicate that generation is still happening without adding status indicators that simply repeat what the interface already shows.

LABEL

Where should the user stop generation?

In the composer, exactly where Send was. Keeping both actions in the same position avoids introducing another control beneath the response.

LABEL

Where should the user stop generation?

In the composer, exactly where Send was. Keeping both actions in the same position avoids introducing another control beneath the response.

LABEL

What happens to an unfinished answer?

The content stays visible. Stopping is a deliberate action, so it needs no warning. An unexpected failure, however, needs a clear explanation and a way to retry.

LABEL

What happens to an unfinished answer?

The content stays visible. Stopping is a deliberate action, so it needs no warning. An unexpected failure, however, needs a clear explanation and a way to retry.

LABEL

Can a partial answer be misleading?

Absolutely. People can start reading sooner, but an incomplete answer may sound definitive before the model has finished. I'd want to test whether users recognise that distinction, particularly when the response contains recommendations or factual claims.

Model Latency

Unlike traditional interfaces, conversational AI cannot always predict how long a request will take. Some responses arrive almost instantly, while others require extended processing or never complete.

I explored how to communicate these delays without creating false expectations, while giving users a clear way to recover when something goes wrong.

Waiting

Extended wait

Timeout

Recovery

A subtle activity indicator acknowledges the request, with contextual information about the processing task.

LABEL

How do you show progress when you cannot predict the wait?

I chose to communicate what the system is doing rather than how close it might be to finishing.

A message such as "Still reviewing the attached agreement" gives users some context without inventing a percentage, a countdown or an estimated completion time.

LABEL

When should the interface acknowledge a delay?

Waiting is expected, but prolonged silence can leave users wondering whether anything is happening. I introduced a distinct extended waiting state that acknowledges the delay without interrupting the request.

LABEL

What happens when waiting turns into failure?

A timeout ends the current attempt. The original request stays visible, and Retry starts a new one. Users should not have to rebuild their input because the system failed to respond.

LABEL

What happens when waiting turns into failure?

A timeout ends the current attempt. The original request stays visible, and Retry starts a new one. Users should not have to rebuild their input because the system failed to respond.

LABEL

How much can the interface honestly tell us?

Specific feedback can make waiting easier to understand, but only when it reflects actual system activity. Otherwise, a simpler message is more useful than a convincing but inaccurate one.

LABEL

How much can the interface honestly tell us?

Specific feedback can make waiting easier to understand, but only when it reflects actual system activity. Otherwise, a simpler message is more useful than a convincing but inaccurate one.

Grounding & Uncertainty

AI can produce convincing answers even when the available evidence is incomplete, ambiguous or contradictory. A citation might make an answer appear reliable, but it doesn't guarantee that the information has been interpreted correctly.

I explored how conversational interfaces could help people examine supporting evidence, recognise missing information and understand when a definitive answer isn't possible.

Grounded Answer

Insufficient Evidence

Conflicting Evidences

Evidence Preview

Claims are linked to supporting passages. Selecting a reference opens the original document alongside the conversation, with the relevant clause highlighted.

LABEL

Does citing a source make an answer trustworthy?

Not necessarily. A reference tells us where information came from, but not whether the model has understood it correctly.

I focused on making claims traceable to their original sources. Users can open a document, inspect the relevant passage and judge whether the generated interpretation holds up.

LABEL

How much evidence should be visible?

I kept the relevant passages in the conversation, with direct access to the original documents. People can assess the evidence without constantly switching between the answer and its sources.

LABEL

How much evidence should be visible?

I kept the relevant passages in the conversation, with direct access to the original documents. People can assess the evidence without constantly switching between the answer and its sources.

LABEL

What if the evidence isn't enough?

An honest limitation is more useful than a confident guess. The assistant explains what it cannot establish, why the information is insufficient and what would help resolve the question.

LABEL

What if the evidence isn't enough?

An honest limitation is more useful than a confident guess. The assistant explains what it cannot establish, why the information is insufficient and what would help resolve the question.

LABEL

Can the interface prevent hallucinations?

No. Citations and document previews can make unsupported claims easier to investigate, but they cannot guarantee factual accuracy. I would want to test whether users actually examine the sources or simply interpret their presence as proof.

LABEL

Can the interface prevent hallucinations?

What I Learnt

Designing for uncertainty, not hiding it

Working through these scenarios reinforced something I kept coming back to: the challenge isn't always deciding what to show, but knowing what to leave out.

An interrupted response doesn't necessarily need an explanation. A long wait needs honest feedback, not invented progress. And a citation should help someone question an answer, not simply trust it.

Across these explorations, I focused on making system behaviour understandable without pretending the technology is more predictable or reliable than it really is.

What would I test next?

These are design hypotheses, not validated solutions. Three questions I'd want to investigate with users:

Partial responses: Do people recognise when an answer is still being generated, or do they treat unfinished content as final?

Waiting: Does contextual feedback make longer processing times easier to tolerate, even without a reliable time estimate?

Evidence: Do people actually inspect cited documents, or does the presence of a citation create a false sense of confidence?

Where these questions began

Many of these questions first came up while I was designing the conversational experience for OODA, a confidential AI platform.

That project introduced real product constraints around unpredictable system behaviour, user control and complex workflows. This independent exploration gave me the opportunity to revisit those questions in greater depth.

case study

interaction design

2026

Designing the experience of confidential AI

OODA brought together conversational AI, distributed computing and hardware enforced privacy. I worked across five interconnected product experiences, designing the interaction architecture, complex workflows and a shared design system alongside Product and Engineering.

Explore case study