Chatbot Window UI Design: Widget Patterns for Websites

On this page10 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
• Making the widget look like your product

Chatbot window UI design is the design of the embedded chat widget that sits on a website or inside a web product: the launcher that opens it, the window's size and position, its open, minimized and closed states, and how it behaves across pages and on mobile. 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.

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.