Assume the phone first
For most sites, more than half of chat happens on a phone held one-handed, on a patchy connection, by someone doing something else. If your chat experience was designed on a desktop, it is probably fighting the very visitors who use it most. Mobile is not a smaller version of the desktop chat — it is the primary case.
Mind the thumb zone
On a phone, the launcher and the composer live in the same corner your thumb already occupies — and the same corner where "back to top" buttons, cookie banners, and sticky bars pile up. A launcher that overlaps a checkout button or hides behind a banner is a launcher nobody taps. Test on a real device, at real sizes, with your actual page furniture in place.
Short messages win on small screens
A paragraph that reads fine on a laptop becomes an intimidating wall on a 5-inch screen. On mobile, agents should send shorter turns, break steps into separate messages, and lean on the visitor being able to scroll a conversation rather than a monologue. Canned responses written for desktop often need a tighter mobile variant.
Typing is expensive — reduce it
- Trim the pre-chat form. Every field is harder to complete with thumbs. Ask for the minimum, or none, and collect email inside the conversation.
- Offer quick replies where they fit. A tap beats typing for common branches.
- Respect autofill and keyboards. Use the right input types so the phone helps instead of fighting.
Design for interruption
Mobile conversations get interrupted — a call comes in, the app backgrounds, the signal drops. The experience must survive that: the conversation should still be there when they come back, and a message they missed should be waiting, not lost. Persistence across a dropped connection is the difference between "picked up where we left off" and "started over, annoyed."
Speed matters more on mobile
A mobile visitor's patience is shorter and their attention more contested. Fast first responses, an AI layer that answers immediately, and a widget that loads without janking the page all matter more here than on desktop. MyLiveChat's widget is built to be responsive on mobile out of the box — but the content choices above are what make it actually work under a thumb.
The failures that never appear in a desktop test
Most chat setups are tested on the machine they were configured on, which is why a specific set
of mobile problems survives to production. The on-screen keyboard is the biggest one: when it opens
it can cover the input, the send control, or the last few messages, and the visitor is left typing
blind or scrolling on every message.
Zoom is the second. If the input font is small enough, some mobile browsers zoom the whole page
when it is focused and do not zoom back out, leaving the visitor in a magnified layout they have to
fix manually. It looks like a broken site, and it is caused by a font size.
Then there is everything about attachments. On a phone, sending a screenshot usually means
switching apps, and sending a photo means the camera. If your upload path assumes a file picker and
a desktop file system, a meaningful share of visitors will simply describe the problem in words
instead, badly. Test the whole path on a real phone, including a slow connection, before deciding
mobile chat works.
Interruption is the normal case, not the edge case
A mobile conversation is not a shorter desktop conversation; it is a conversation that will be
interrupted. The visitor will switch apps to find an order number, take a call, lock the screen, or
walk into a lift. Designing for that changes what good behaviour looks like on your side.
It means not treating a two-minute silence as an abandoned chat, because on a phone it is often a
visitor doing exactly what you asked. It means keeping the thread readable when they come back:
short messages, one idea each, so that scrolling up re-establishes context quickly.
It also means being careful about anything that punishes a backgrounded tab. If your setup ends
conversations aggressively on inactivity, mobile visitors will bear most of that cost and you will
read it as mobile users being flaky. Give them a way to return to the conversation, and say the wait
is fine.
What to measure
Split every core number by device before drawing conclusions. Wait time, abandonment, satisfaction
and conversion all behave differently on phones, and a blended figure hides whichever one is worse.
Watch the share of mobile chats that end without a reply from the visitor. A high figure usually
points at an interface problem or a session timeout rather than at disinterest, and it is worth
reproducing on a real device before accepting it.
Track message length by device. If mobile visitors are writing dramatically shorter messages, you
are getting less information per exchange, which is a good argument for asking fewer and better
questions on small screens.