DOM Studio
← Blog
1 Oct 2026chat bubbleschat UIconversational interfacesVueAI UX

Chat Bubbles: 5 Real UI Patterns for Better Product Conversations

Explore five real chat bubble UI patterns, from support threads to inline AI replies, with practical guidance for choosing and testing each in Vue apps.

Chat Bubbles: 5 Real UI Patterns for Better Product Conversations

TL;DR

Choose chat bubbles by the job they do, not by their corner radius. Use compact, clearly attributed messages for quick exchanges; grouped threads for sustained discussions; inline replies for work tied to a specific screen; richer response surfaces for AI output; and small notification previews only when they lead somewhere useful. The five examples below show where each pattern fits and what to check before building it in Vue.

A chat bubble can be a message in a conversation, a short progress cue, an assistant response beside a form, or a preview of a conversation elsewhere. Those surfaces may look related while asking the user to do very different things. In a dashboard, the best bubble might not be a bubble at all: a readable card or an inline response can give a long answer room to breathe.

We have selected actual product interfaces and documented working examples rather than imaginary mockups. This is a guide to choosing the interaction pattern. For the component contract, keyboard behavior, and streaming implementation, see our separate Vue chat bubble implementation guide.

Table of contents

What counts as a useful chat bubble example?

Each example below exposes a real, inspectable conversation surface or a documented interaction. Look for three things: what event creates the message, what the reader needs to understand next, and where the conversation goes when it grows. A rounded rectangle alone tells you little about any of them. The transferable lessons are our design interpretations, not claims that another product achieved a measured outcome.

Before sketching a variant, define its anatomy. A useful message may need an author or role, content, a timestamp or delivery state, an action, and an attachment or citation. Keep secondary details such as tool logs and reasoning summaries expandable when they would crowd the answer. In a multi-person thread, a visible name or avatar does more work than a different hue; in a one-to-one exchange, alignment and grouping can carry more of the rhythm. A notification preview needs a destination and a dismissal path, not the entire conversation embedded in a floating card.

Choose the surface before choosing the styling

Start with conversation length, content richness, response speed, and the surrounding task:

  • Short back-and-forth on a dedicated chat screen: use compact, aligned messages with obvious author and delivery states.
  • Many people or related subtopics: group replies into a thread and preserve the parent message as context.
  • A request about the current field, document, or table: put a small answer close to that object; offer a path into a larger conversation if needed.
  • A long AI answer with evidence, code, or tool output: give the response card more width, distinct content sections, and a recoverable progress state.
  • An answer arriving while the user is elsewhere: show a restrained preview, then open the full thread on demand.

Four chat bubble patterns compared: short exchange, rich answer, inline assistant, and notification preview

The illustration compares four possible placements, not four mandatory component types. A dashboard may combine an inline answer with a later notification; a dedicated chat screen may move between compact exchanges and wide, structured responses. Select the smallest surface that preserves context and lets the next action remain clear.

1. DOM Studio’s support copilot: messages within an operations workspace

Our support copilot workspace example places conversation alongside a support queue and a ticket-context panel. The live example shows a distinct customer request, an attributed specialist response, a composer, and evidence connected to the support task. Its message area is one part of an application workflow rather than the whole application.

Why it is useful: A support operator must answer which ticket, who responded, and what evidence informed the reply. A message bubble that hides those relationships behind a pleasant chat aesthetic would be less useful. We would keep a short operator request compact, then let a cited or action-heavy response use a roomier card. Keep routing, priority, and ticket status in the surrounding workspace where they remain available as the thread scrolls.

This is an implementation example, not proof that a particular arrangement improves support performance. The transferable move is to separate durable case context from transient message content. In your own dashboard, check whether an avatar, author label, and timestamp help distinguish a human teammate from an assistant; show a delivery or failure state near the specific message rather than in an unrelated banner. If the user moves to another ticket, preserve which conversation each action belongs to.

2. Slack threads: group the reply around its parent message

Slack’s documentation for threads describes replies attached to a particular message, with an option to send a reply back to the channel. On desktop, a thread can also open alongside another conversation. These are verified behaviors; the pattern lesson is ours: relationship matters more than repeating the same bubble treatment on every reply.

Imagine an engineer asks why a dashboard total changed and receives six replies with queries, decisions, and follow-up questions. Rendering every update as an equally prominent bubble in the main activity stream would make the primary timeline harder to scan. A thread keeps the initiating question visible as the anchor, while replies have room for their own authors, times, and attachments.

If you borrow the grouping idea for an app, decide whether the parent item remains visible while a reply panel opens, how unread replies are signaled, and whether sending a reply should also post to the main feed. Group consecutive messages from the same author only when that grouping does not obscure who said what or when. On a narrow screen, let the detail view replace a split pane rather than compressing both columns into unreadable slivers.

3. VS Code inline chat: answer beside the thing being edited

Visual Studio Code’s inline chat documentation distinguishes quick, targeted work in an editor from the fuller Chat view. An editor prompt can be scoped to selected code, and suggested edits appear as a diff with Keep and Undo actions. That is a concrete example of an assistant response positioned at the work site instead of added to a remote message history.

For a form builder, the analogous question might be, “Why did this validation rule reject this field?” For a dashboard, it could be, “Explain this spike.” An inline assistant response is a better starting point when the answer is short and only makes sense beside the selected field or chart. The reply can feel conversational without pretending the entire form is a messaging app.

The boundary is important. Do not make a tiny anchored bubble carry a lengthy report, several code blocks, or an audit trail. Provide a deliberate route to an expanded panel or full thread and keep the object being discussed identifiable after that transition. If the response suggests changing data, separate explanation from Apply, Undo, or Review actions. The VS Code example demonstrates that distinction with an explicit diff and decision controls; whether your app needs the same controls depends on what its assistant can change.

4. DOM Studio’s agent workspace: one response can contain several parts

Our agent chat component example describes a conversation that can render text, audio, handoffs, reasoning summaries, tool calls, and tool results as ordered parts of an assistant message while a stream is active. Its shell separates the conversation from a sidebar and an optional contextual pane. The example also documents a stop action for a streaming response and a generic card when a tool has no custom renderer.

Assistant conversation concept showing waiting, partial response with tool activity, and a recoverable stopped response

The image sketches a waiting response, a partial answer with tool activity, and a stopped answer that can be recovered. It is an illustrative UX model, not a screenshot of the agent workspace. The product design lesson is to keep a single response recognizable through waiting, partial output, completion, interruption, and failure rather than adding a new visually identical bubble for every state change.

Consider a report assistant asked to summarize revenue by region. A quiet progress cue may be enough while it retrieves data. When an answer arrives, the summary should lead; a source reference, query detail, or tool result can follow as inspectable supporting material. If the operation fails, an explanation and a specific Retry action should be attached to the affected response. An interrupt control should communicate what will stop and what, if anything, has already been saved. Avoid presenting an unreviewed private model trace as though it were ordinary product-facing reasoning.

For your Vue implementation, decide which parts need their own component and which belong to the message’s status model. Preserve a readable order if tool cards, citations, and text wrap onto a phone screen. A full-width answer card often serves rich content better than a narrow speech tail.

5. Intercom notifications: preview the conversation, do not duplicate it

Intercom’s in-app notification documentation describes stacked web notifications, dismissal controls, image previews, ticket-status updates, and, for some messages, buttons that can be used without opening the full Messenger. It also notes that those interactive buttons are handled differently on mobile. This is an example of a notification-style bubble, not a substitute for the underlying conversation.

For a product engineer, the decision is whether the interruption changes what someone should do now. A new support reply might warrant a short preview linked to its thread. A routine background step may need only a quiet status change. Do not float the full transcript over a form, and do not use the same visual urgency for “working,” “needs approval,” and “failed.” Make the sender, subject, and next destination understandable even when the preview truncates.

We also need to keep preview controls honest: an action offered inside the notification should be available and operable there, not merely shaped like a button. Give people a way to dismiss it without losing the underlying message. Intercom’s documented behavior offers one concrete reference; copy the principle of a clear handoff, not its exact timing or notification rules.

For a short companion lesson on the difference between a concise notification and the fuller information behind it, watch Nielsen Norman Group’s educational video below. It covers transactional notifications broadly rather than prescribing how a chat bubble must look.

Make these patterns feel like one application

Different placements do not require five unrelated visual systems. Choose a few shared rules: spacing within a message, spacing between messages, maximum readable width, author treatment, and semantic colors for pending, success, warning, and error. DOM Studio’s theming reference documents paired background and foreground tokens, including status pairs and focus-ring tokens. We can use those relationships to keep an assistant card, a support reply, and a notification preview visually related without assigning color as the only indication of role or state.

Long URLs and filenames must wrap; code and genuinely two-dimensional material need their own scroll region instead of forcing the whole screen sideways. WCAG’s reflow guidance calls for ordinary content to remain usable at a width equivalent to 320 CSS pixels, with exceptions for content that requires two dimensions. On mobile, put actions where they remain discoverable without hover and test them with touch and keyboard input. Try enlarged text before deciding that a desktop message width works everywhere.

Contrast needs measuring, not eyeballing. WCAG’s minimum-contrast criterion specifies at least 4.5:1 for ordinary text and 3:1 for large text, subject to its stated exceptions. Test your actual foreground and background pairs in both themes. Check the smaller timestamp and status text too, especially when they sit on tinted bubbles.

A chat’s visual order must match the reading order. W3C’s small role="log" demo shows a dynamically updated conversation region, but explicitly does not claim to be a complete chat application. MDN’s live-region guidance explains why polite updates can communicate nonurgent changes without interrupting someone who is reading. We would announce meaningful transitions such as “response ready” or “response failed,” rather than every streamed fragment. Keep focus where the user is working unless an explicit action changes the task; also test a reduced-motion setting and the flow with a screen reader.

A Vue pre-implementation checklist

Before turning the chosen pattern into components, we ask:

  1. Can a reader identify the author, role, and state without color alone?
  2. Is each bubble, card, or preview attached to the correct thread, field, ticket, or notification destination?
  3. Do compact and rich replies have distinct width, wrapping, and action rules?
  4. What does the user see during waiting, streaming, tool activity, interruption, failure, and retry?
  5. Do source links, attachments, code, and long unbroken strings survive a narrow viewport?
  6. Can every action be found and used by keyboard and touch, without relying on hover?
  7. Are status announcements concise, and does focus stay predictable while new content arrives?

Answer those in a design review with real short messages, long responses, a failed request, and an older thread. Then build the variants your application actually needs. A conversation component should make those decisions visible rather than hiding them in a pile of conditional styling.

FAQ

Are chat bubbles always aligned left and right?

No. Opposing alignment can make a short one-to-one exchange easy to scan, but a group discussion needs stronger author identification, while a rich assistant answer may be clearer as a full-width card. Keep the reading order logical regardless of visual alignment.

Should a thinking indicator be a separate message?

Usually treat it as a state of the pending assistant response. That keeps status attached to the request and avoids filling the history with fleeting pseudo-messages. If a tool action or handoff becomes meaningful history, preserve that detail inside the response or its expandable activity area.

When does a small preview need to open a full conversation?

When the user must read context, respond at length, inspect evidence, or revisit earlier messages. A preview should answer who or what needs attention and provide a clear route to the durable thread.

Choose the pattern, then build the message

Start from the job on the screen: a support ticket, a threaded decision, an inline edit, a complex AI answer, or a notification that points back to a conversation. We use our support copilot example to explore a real workspace, then move to the accessible Vue chat bubble guide when it is time to implement message behavior. Build the smallest appropriate surface and test its least convenient state before polishing its shape.

Sources

Recommended Reads