Chatbot Window UI Design: Widget Patterns for Websites

On this page12 sections

• The anatomy of a chat window
• The launcher
• The header
• The message area
• The composer
• How big should a chatbot window be?
• The three states: open, minimized, closed
• Persistence across pages
• Proactive messages: when to speak first
• Chatbot window UI examples from real websites
• What a different chat window looks like
• Making the widget look like your product

Chatbot window UI design is the design of the embedded chat widget on a website: the launcher that opens it, the window's size and position, and its open, minimized and closed states. The short answer for most sites: a quiet bottom-right launcher, a window 360 to 420px wide on desktop, full screen on phones, and a conversation that survives minimizing and page changes.

It is a different problem from full-page chat, because the window shares the screen with everything else the visitor came for.

Most teams treat the widget as a vendor default and ship whatever the chat provider renders. That is a mistake worth fixing early, because the widget is the most visible AI surface a company has. Every visitor sees the launcher, far more than ever open a full chat product. This guide covers the decisions that make a chat window feel like part of the product rather than an ad stapled to it.

The anatomy of a chat window

Every website chat window is built from the same small set of parts. Naming them helps, because each one fails in its own way.

The launcher

The button that opens the chat. Bottom-right is the convention on the web, and conventions exist so people do not have to look for things. Moving it to the left or into the header costs more in findability than it earns in novelty.

Keep it quiet: a 56 to 64px circle in the product's accent colour, with an icon that reads as conversation. A text label ("Ask about pricing") can outperform an icon alone when the assistant has a narrow job, because it states the scope before anyone clicks.

The header

The strip at the top of the open window. It carries the assistant's name, a one-line statement of what it handles, and the close and minimize controls. If a human can take over, say so here, with realistic hours. "Replies from the team within a few hours" is more trustworthy than a green dot that means nothing after 6pm.

The message area

Most of the window. It has to hold long answers, lists, links and sometimes tables without turning every reply into a scroll exercise. This is the main reason window width matters: below about 340px, structured answers wrap into columns of three words.

The composer

The input at the bottom, with an obvious send action and, when the assistant is generating, an obvious stop. On a website widget, keep attachments and voice out unless the job genuinely needs them. Every extra control in a 380px window competes with the one thing the visitor came to do, which is ask a question.

How big should a chatbot window be?

On desktop, the window works best between 360 and 420px wide and 60 to 70% of the viewport height, anchored to the launcher corner with a small gap from the edges. That width keeps sentences readable and leaves room for lists; the height shows several exchanges without covering the page the visitor is trying to read.

Two sizes to avoid:

• Small squares (around 300 by 400px) truncate every answer. Visitors spend the conversation scrolling inside a box.
• Full-height side panels feel heavier than most website questions justify. They make sense inside a product, where the assistant is a working tool, but on a marketing site they read as a takeover.

On phones, the window should go full screen, with the close control in the top corner and the composer pinned above the keyboard. A floating mini-window on a phone is unusable past the first exchange, because the keyboard covers half of it.

The three states: open, minimized, closed

This is the detail most widgets get wrong, and it quietly costs them their returning users.

• Open: the full window, with the conversation in view.
• Minimized: the window collapses back to the launcher, but the conversation is kept. If the assistant replies while minimized, the launcher shows an unread indicator.
• Closed: the visitor has finished. The conversation can be cleared, or kept for their next visit if they are signed in.

A visitor who minimizes the window to check something on the page and comes back to an empty thread has learned that the widget forgets. Very few of them open it a second time.

Persistence across pages

On a website, an open conversation should survive navigation. A visitor asks about pricing on the homepage, clicks through to the pricing page, and the widget re-mounts empty: the one thing chat promised, continuity, is gone. Keep the conversation in session storage at minimum, and restore the window in the state the visitor left it.

Proactive messages: when to speak first

Auto-opening the window, playing a sound, or popping a message the moment the page loads are the fastest ways to get a chat widget mentally filed as an advert. The default should be silence.

A proactive message can work when it is genuinely contextual and arrives late enough to be useful:

• The visitor has been on the pricing page for a couple of minutes: "Questions about which plan fits? I can compare them for your team size."
• They have opened the same documentation page twice: "Looking for the API limits? Here's the short version."

The test is whether the message would still make sense if a person had sent it. If it would feel pushy from a person, it is pushy from a widget.

Chatbot window UI examples from real websites

Most website chat windows are a vendor widget with settings changed, so the vendor's limits become your design. These are the three you will meet most often, with what each one lets you control (checked in each vendor's own documentation, October 2026):

Widget	Launcher position	Mobile	Worth copying or watching
Intercom Messenger	Left or right side only, padding of at least 20px (smaller values are ignored)	Always bottom right on mobile web; alignment and padding settings are ignored	It cannot be shown full screen on a website, and the conversation window size cannot be edited. If you need a bigger or full-page chat, that is a custom surface, not a setting
Zendesk Web Widget	Bottom right or bottom left; square or circle launcher, with optional text next to the button	Configured separately from desktop	The text label is the easiest way to state the assistant's scope. A custom launcher removes theirs, and you rebuild it with their open, close and unread APIs
HubSpot chat	Bottom of the page, with the welcome message able to pop open above the launcher as a prompt	Mobile chat is set up as its own channel	Outside working hours it can show a return time, show an away message, or hide the launcher. Pick the return time: it is honest and keeps the door open

The pattern across all three: position, colour and launcher shape are settings, while size, full-page modes and anything unusual need your own window. That matters if you are deciding between configuring a vendor widget and designing one.

What a different chat window looks like

Most "innovative" chat windows are not new layouts. They are ordinary windows with four decisions made deliberately, and each one is copyable:

• A scoped launcher: text on the button ("Ask about pricing", "Search the docs") instead of an icon alone, so the visitor knows what it handles before opening it.
• Page-aware starters: the suggested questions change with the page. On pricing they are about plans; on documentation they are about limits and setup.
• A real minimized state: the window collapses to the launcher with an unread badge and the thread kept, instead of resetting.
• An honest handoff: the header says when a person replies ("usually within a few hours") and the window shows a joining state when one does.

For the full-page chat products these patterns come from (ChatGPT, Claude, Perplexity, Intercom Fin), see our chatbot UI examples.

Making the widget look like your product

A chat window rendered in a vendor's default styles tells visitors that the assistant is bolted on. Four decisions fix most of it:

1. Use your type and colour tokens, not the vendor's. The window should look like it came from the same design system as the page behind it.
2. Match your corner radius and border style. A rounded, shadowed widget on a sharp, flat site reads as a third-party embed.
3. Write the copy in your product's voice. The greeting, the starters and the error messages are product copy, not configuration.
4. Design the error and handoff states. What the window says when the model fails, or when it hands off to a person, matters more for trust than the happy path.

We cover the message-level patterns (streaming, citations, uncertainty) in our AI chatbot UI design guide, and the first screen in detail in designing the first message in a chat interface. If you want the window designed as part of your product rather than configured on top of it, that is exactly what our AI chatbot UI design work covers.