Chatbot Window UI Design: Every Decision That Matters

A good chat window is legible at a glance, obviously interactive, and honest about what it can do. Almost every failure traces back to one of those three: text that is hard to read, an interface that hides what to do next, or an opening line that promises more than the bot delivers.

The window itself is a small surface - roughly 380x600 pixels on desktop, full screen on mobile - but it contains six distinct design decisions: the launcher, the header, the message area, the input, the mobile behaviour and the branding footer. Each has a wrong answer that quietly costs conversations.

Most people never open your chat. The launcher is therefore doing more work than the entire conversation behind it.

The decisions, in order of impact:

• Position. Bottom-right is the convention and conventions reduce hesitation. Bottom-left is legitimate if a cart, cookie bar or back-to-top button already occupies the right - competing for the same corner is worse than being unconventional.
• Offset. The single most common implementation bug is a launcher that overlaps a sticky footer or a mobile navigation bar. Check it against your own site, not against a blank demo page.
• Size. Large enough to be an obvious tap target - around 56-64px - and no larger. Oversized launchers read as advertising.
• Icon versus image. A chat glyph is instantly legible. A brand mark is not, unless you are already famous. If you use a custom image, it still has to say "this opens a conversation".
• Call-to-action label. A short label beside the icon - "Need help?" - reliably lifts opens over a bare circle, at the cost of screen real estate.

Resist animation that loops. A pulse on first load is a nudge; a permanent bounce is noise people learn to ignore, and on mobile it eats battery for nothing.

The header answers "who am I talking to" and "how do I leave". Both matter more than the space they occupy.

• Name the bot honestly. "Support Bot" sets accurate expectations. A human first name on an automated agent buys a moment of warmth and then a betrayal when it cannot help.
• Say whether a human is available. The single most useful piece of header copy is whether escalation exists. "We reply in minutes, 9-5 GMT" prevents the frustration of discovering at 11pm that nobody is there.
• Keep close obvious. A visible close control, not a gesture. Trapping people is the fastest way to lose them permanently.
• Contrast the header colour properly. Brand colour headers frequently fail contrast against white text. Check the actual ratio rather than trusting that it looks fine on your monitor.

A tagline is optional and usually earns its space only when it clarifies scope - "Order and delivery questions" is useful; "We are here for you!" is not.

This is where most of the reading happens, so it is where restraint pays.

If a message needs more than sixty words, it usually needs to become two messages or a link. Splitting also lets you show a typing indicator between them, which reads as considered rather than dumped.

The input area silently decides your completion rate.

Buttons and quick replies raise completion because they remove the burden of composing an answer, work far better on mobile, and constrain input to values your flow can actually handle. Their cost is that they cannot capture anything you did not anticipate.

Free text collects richer information and is essential for open questions, but every free-text field is a chance for the user to say something the bot cannot parse.

The reliable pattern is buttons with an escape hatch: offer three to five options, and leave the text box available for anyone whose situation is not on the list. Hiding the text input entirely is what makes a bot feel like a phone tree.

Three details that matter more than they look:

• Keep the input visible while the bot types. Disabling it mid-conversation makes the interface feel frozen.
• Show a typing indicator for anything over about half a second, and be honest with its duration - artificially slow typing to seem human is irritating once noticed.
• Support Enter to send on desktop and keep the send button large enough to tap on mobile.

Over half of chat traffic is mobile and the constraints are genuinely different.

• Full screen, not a floating panel. A miniature desktop window on a phone wastes the viewport and produces mis-taps.
• The keyboard eats half the screen. Test with it open - this is where fixed-position headers and footers collide and where the send button ends up under the thumb bar.
• Tap targets at 44px minimum, with real spacing between adjacent buttons. Quick-reply chips packed tightly are the most common mis-tap source.
• Never block page scroll behind an open chat unless the chat is genuinely full screen.
• Respect safe areas on notched devices, or your close button sits under the system UI.

Test on a real mid-range Android device, not only on a desktop browser's responsive mode. The gap between those two is where most launch-day bugs live.

Retrofitting accessibility into a chat window is painful; building it in costs almost nothing.

• Contrast. Aim for at least 4.5:1 on body text. Brand-coloured bubbles with white text are the usual failure.
• Keyboard. The whole conversation should be operable without a mouse - open, move between quick replies, send, close.
• Focus management. When the window opens, focus should move into it; when it closes, focus should return to the launcher.
• Announce new messages via a polite live region so screen-reader users know a reply arrived.
• Never rely on colour alone to distinguish speaker, state or error.
• Respect reduced-motion preferences for typing animations and window transitions.

These are also the changes that most improve the experience for everyone else - contrast helps in sunlight, keyboard support helps power users, focus management helps everybody.

1. Launcher does not overlap any sticky element, on your real site, on mobile.
2. Header states whether a human is reachable and when.
3. Body text is 15px or larger and passes contrast against its bubble.
4. No message in the first three exceeds sixty words.
5. Text input remains available alongside buttons.
6. Full-screen on mobile, tested with the keyboard open.
7. Whole flow operable by keyboard; focus enters and exits correctly.
8. Typing indicator reflects real latency.
9. A visible route to a human exists within two taps.

Most chat widgets expose these as configuration rather than code - position and offsets, header and bubble colours, radius, avatar, background type, launcher icon and label - so this is normally a settings pass rather than a development project.