Streaming AI responses: UX for text that arrives as it’s written

The first second decides how the wait feels. Jakob Nielsen’s response time limits put about 1 second as the point where someone’s flow of thought stays unbroken, and about 10 seconds as the limit for keeping their attention. A 20-second answer is fine if its first words arrive quickly. An empty panel for five seconds is not.

Until the first words arrive, say what the assistant is doing, in plain words: “Searching your notes”, “Found 3 notes about the boiler”. The Cloudscape design system treats this as two stages, processing the request and generating the answer, and recommends streaming the answer whenever the model supports it.

Don’t show a progress bar with a percentage. The model doesn’t know how long its answer will be, so the number is made up.

Keeping the newest line in view is right while the reader is at the bottom, watching it arrive. It’s wrong once they scroll up, because pulling them down with every new word makes reading impossible. Nielsen Norman Group’s guidelines for AI chatbots say the same: don’t autoscroll people to the end of a response, because anyone who has started reading has to find their place again.

So follow new text only if the view is already at the bottom, within a line or so. If the reader has scrolled away, leave the view exactly where it is and show a small Jump to latest button that takes them to the newest text. Don’t pull them down when the answer finishes, either. A text selection, or a pointer held down in the conversation, is also a sign to stop following.

While the assistant writes, the Send button should become Stop, in the same place. Cloudscape’s guidance for generative AI describes exactly this, and adds that people should be able to stop straight away, with nothing in the way. Stopping also keeps the model from spending tokens on an answer nobody wants.

People stop because the first paragraph shows a misunderstanding, or because they already have what they need. So stopping should keep everything written so far, mark it as stopped, and offer to continue or try again. Never delete the partial answer, and never let it pass for a complete one.

Here is the whole sequence: the reply streams in, the reader scrolls up to check an earlier answer, the view stays put, and they stop the reply.

A streamed answer looks finished at every pause: a paragraph ends, a list has three items, the text rests while the model works. Without a clear signal, people copy, act on or forward an answer that is only half written.

Show the state in words beside the reply, such as “Writing…”, and a steady marker where new words will appear. When the answer is complete, make the change easy to see: the status goes, the actions become available and Stop turns back into Send.

Hold the actions that use the answer until it’s complete. Copy, Insert into note and Apply should be unavailable while it writes, with a short reason such as “Ready when finished”. If you do allow Copy early, label it plainly: “Copy what’s written so far”.

Here is the same reply, mid-stream, done both ways.

Lists, tables, headings and code blocks arrive a line at a time, and each can make the page jump. A table that streams in as raw markdown, rows of pipes and dashes that snap into a grid at the end, moves everything below it and shows people characters never meant for them.

Render structure as soon as it’s clear what it is. When a table’s header row arrives, draw the table and add rows beneath it. When a code block opens, draw its frame and fill it in. Chrome’s guide to rendering streamed LLM responses recommends a streaming markdown parser, which handles each chunk as it comes and holds output back until it can tell what it is. Cloudscape’s loading pattern shows a loading bar with tables and code blocks instead of streaming them as text.

Underneath all of this: never change what someone has already read, such as re-wrapping a finished paragraph or restyling the answer when it completes. Only the end should move.

Connections drop and models time out halfway through an answer. The worst response is to replace everything with “Something went wrong”, so the person loses the half that arrived, often the useful half.

Keep the text, mark where it stopped and say why: “The connection dropped here.” Offer Continue, which picks up from that point, and Retry, which starts again. Make a broken answer look different from a finished one, and make sure screen reader users hear about the error, not a cheerful “Reply ready”.

Don’t put the streaming answer in an ARIA live region. It sounds like the accessible choice, but it means fragments read out each time a few words arrive. It’s like listening to someone type.

Announce the events instead: one polite status message when the assistant starts, such as “Writing a reply”, and one when it finishes, stops or fails. WCAG success criterion 4.1.3, Status Messages, covers this kind of update, which assistive technology should be able to announce without focus moving. Leave the answer as ordinary text that people read at their own pace, and don’t move focus to it when it’s done.

You can mark the answer with aria-busy while it writes, to tell assistive technology it’s still changing. Support is uneven: Adrian Roselli’s 2026 tests of live regions found results differ by screen reader, version and browser, so test with the ones your users have. Don’t hide the streaming answer with aria-hidden, either.

Don’t end the text with a blinking cursor. It keeps blinking for as long as the answer takes. Blinking that starts on its own and lasts more than five seconds alongside other content is something WCAG success criterion 2.2.2, Pause, Stop, Hide, asks you to let people stop. It’s simpler not to blink. A steady marker does the same job.

Respect the setting for reduced motion. When someone’s device asks for less, which the prefers-reduced-motion media query reports on the web, drop word-by-word fades and smooth scrolling, and make Jump to latest jump rather than glide.

Some products pace the words like a person typing, so the answer feels considered. Don’t. Text that arrives faster than people read costs them nothing, because they read at their own pace. Text held back costs them time on every answer. In Nielsen Norman Group’s research on site chatbots, one participant who waited several seconds for each response found the answer faster by searching the site.

Smoothing is different. Text often arrives in uneven bursts, and releasing it at a steady pace can make it easier to follow, as long as it never falls more than a moment behind. If an answer is hard to follow as it streams, the fix is a shorter answer, not a slower one. NN/g found people felt overwhelmed when a site chatbot streamed a long, dense answer.