SaaS Avatar & User Presence UX Patterns: Real Screenshots (2026)
The moment a SaaS product becomes multiplayer, it has to answer a question the single-user version never asked: who else is here, and what are they doing right now? Avatars, avatar stacks, presence dots, live cursors, and typing indicators are how the interface answers it — the little circle with a face or initials that tells you who owns a task, the row of overlapping avatars with a "+4" that shows who is on a project, the green dot that means a teammate is online, the coloured cursor gliding across a shared document, the "Alex is typing…" line under a thread. Done well they make a product feel alive and collaborative, giving every user the reassuring sense that they are working alongside real people rather than editing into a void. Done badly they are a wall of indistinguishable grey circles, presence dots that say "online" for someone who closed the tab an hour ago, avatar stacks that overflow off the edge of the card, and live cursors that flicker and jump until they are more distracting than useful. This guide covers the decisions that make presence feel trustworthy and human rather than noisy or misleading: making avatars identifiable and accessible, keeping presence truthful and real-time, handling avatar stacks and overflow gracefully, attributing live collaboration cues clearly, and respecting the user’s privacy and attention — each shown with real SaaS screenshots from shipped products instead of mockups.
The first time a SaaS product adds a second seat, it inherits a problem the single-user version never had: the interface now has to represent people, not just data. A task has an owner, a document has editors, a project has a team, a thread has participants — and a user opening any of those screens instinctively wants to know who is involved and, increasingly, who is here right now. Avatars and presence are the patterns SaaS products use to answer that: the small circular avatar showing a photo or initials that identifies who owns or touched something, the stack of overlapping avatars with a "+4" that shows a project’s members at a glance, the coloured presence dot that signals online, away, or offline, the live cursor with a name label gliding across a shared canvas, the "two people are typing…" indicator under a conversation. Figma, Notion, Linear, Google Docs, Slack, and essentially every product with more than one seat ships some version of this, because the difference between a tool that feels collaborative and one that feels lonely often comes down to whether you can see the other people in it.
The job of avatars and presence is to make a shared workspace feel populated and legible — to let any user tell, at a glance, who is who, who is here, and who did what, without reading a single label twice. It is worth scoping precisely because it blurs into surfaces it is not: it is not the profile or account page (where a user manages their own identity and settings), and it is not the comments or collaboration thread (the discussion itself, which presence merely decorates). Avatar-and-presence UX is the identity-and-liveness layer that sits on top of everything — the avatar that stands in for a person, the stack that summarises a group, the dot that reports availability, the cursor and typing indicator that broadcast real-time activity. It is also distinct from notifications (which tell you what happened while you were away) and from the activity feed (the durable log of who did what); presence is specifically about who and what right now. The decisions below are what separate a presence layer that makes a product feel alive and trustworthy from one that is noise or, worse, a lie — each shown with real SaaS screenshots so you can see how mature products represent people well.
Make avatars identifiable — never a wall of grey circles
An avatar exists to answer one question instantly: who is this? The strong pattern makes every avatar identifiable even when there is no photo, because most users in most products never upload one. It falls back gracefully to initials on a stable, per-user colour so the same person is always the same colour across the app, giving the eye a reliable shorthand — "the purple JM avatar" becomes a recognisable identity in a stack. It keeps avatars legible at the tiny sizes they actually render (a 20px circle in a table row, a 24px one in a stack) by using high-contrast initials and avoiding photos that turn to mush when shrunk. It provides the name on hover or via a tooltip for any avatar small enough that identity is ambiguous, and it never relies on the image alone — an accessible name or alt text is always attached so screen-reader users and anyone who cannot resolve a face still know who they are looking at. The anti-patterns are a row of identical default grey silhouettes that make every teammate anonymous, initials on a randomly re-rolled colour that changes between screens, photos crushed illegibly small, and avatars with no name, tooltip, or alt text so identity is a guessing game. Give every avatar a stable identity — consistent colour, legible initials fallback, a name on hover, and a real accessible label.
Keep presence truthful and real-time — a stale dot is worse than none
A presence indicator makes a promise: this dot reflects reality right now. The strong pattern keeps that promise, because the entire value of presence collapses the moment users learn it lies. It reports availability accurately and updates in near real time — online when the person is actually active, away after genuine idleness, offline when they have truly disconnected — rather than showing a cheerful green dot for someone who closed their laptop an hour ago. It distinguishes states meaningfully (active, idle/away, offline, and where relevant "in a call" or "focus/do-not-disturb") and does not collapse them into a single ambiguous colour. It handles the edge cases honestly: connection drops flip presence to offline rather than freezing on "online", and it avoids the flicker of a dot that rapidly toggles as the network hiccups. Crucially, it never over-promises precision it does not have — if the signal is coarse, "last seen 2h ago" is more honest than a fake live dot. The anti-patterns are a presence dot stuck on "online" for a disconnected user, states so coarse that "away" and "offline" look identical, dots that flicker between states on every network blip, and presence that claims live accuracy the backend cannot actually deliver. A presence layer users can trust is worth ten times one that looks impressive but is quietly wrong.
Handle avatar stacks and overflow gracefully
When more than a few people are attached to something, a naive design either lists every avatar until it runs off the edge or silently hides most of them. The strong pattern summarises a group without losing information: it overlaps avatars into a compact stack, caps the visible count at a sensible number for the space, and shows the remainder as a clear "+N" chip rather than truncating people into oblivion. It makes the overflow actionable — hovering or clicking the "+N" reveals the full list of who else is there, so the summary never becomes a dead end. It orders the stack meaningfully (for example the current user, then most-recently-active, then the rest) instead of a random shuffle that reorders on every render. It keeps the stack readable by giving overlapping avatars a subtle ring or border so adjacent circles stay visually separable, and it reserves consistent space so a card does not jump in width as membership changes. The anti-patterns are a stack that overflows past the edge of its container, a "+N" that leads nowhere, avatars that reorder unpredictably between renders, overlapping circles with no separation so the stack reads as one blob, and layout that reflows every time someone joins or leaves. Summarise the group, cap and overflow into an actionable "+N", order it predictably, and keep the stack legible and stable.
Outplay — a real dashboard screen from the SaaSUI library.
Attribute live collaboration cues clearly — cursors, selections, typing
In real-time products the presence layer goes beyond a static dot to show what people are actively doing — and the whole point of that is attribution, so a cue with no clear owner is just noise. The strong pattern ties every live cue to a specific person: a moving cursor carries a name label and the user’s consistent colour, a live selection or highlight is tinted to match its owner, and a "typing…" indicator names who is typing (or how many) rather than an anonymous ellipsis. It uses the same colour for a given person across their cursor, selection, and avatar so the eye connects them without thinking. It keeps live motion calm: cursors interpolate smoothly rather than teleporting, indicators debounce so they do not flash on every keystroke, and cues fade politely when the person goes idle instead of littering the canvas with abandoned cursors. It scales down as the crowd grows — beyond a handful of simultaneous cursors it summarises ("6 people editing") rather than turning the document into a swarm. The anti-patterns are an unlabelled cursor you cannot attribute, a person whose cursor, selection, and avatar are three different colours, a typing indicator that strobes on every keypress, cursors that jump and jitter, and a canvas buried under a dozen overlapping live cursors. Attribute every cue to a named, consistently-coloured person, keep the motion smooth and debounced, and summarise the crowd before it becomes chaos.
PandaDoc — a real dashboard screen from the SaaSUI library.
Respect privacy and attention — presence should inform, not surveil
Presence is powerful precisely because it broadcasts what people are doing, which is exactly why it can tip from helpful into surveillance or distraction if handled carelessly. The strong pattern treats presence as a courtesy to collaborators, not a monitoring tool for managers: it gives users meaningful control over their own visibility (an "invisible" or "appear away" option, a do-not-disturb state that is respected), and it is careful about exposing granular activity like "viewing this exact page" where that would feel like being watched rather than being helped. It keeps the presence layer quiet by default — subtle dots and small avatars that inform peripheral vision without pulling focus, not pulsing animations and constant motion that compete with the actual work. It avoids weaponising presence data (no "last active" timestamps repurposed into productivity policing) and is transparent about what is shared and with whom. And it degrades gracefully for the solo or asynchronous user, who should never be nagged by an empty, lonely presence bar reminding them nobody else is around. The anti-patterns are presence with no way to go invisible or set do-not-disturb, granular "who is viewing what" exposure that feels like surveillance, a presence layer so animated it distracts from the work, and activity data quietly turned into monitoring. Let people control their own visibility, keep the layer calm and peripheral, and make presence a courtesy rather than a camera.
PhantomBuster — a real dashboard screen from the SaaSUI library.
The details that separate a presence layer users trust from one they ignore
Each decision above is modest on its own; a presence layer feels genuinely alive and trustworthy — a workspace that quietly shows you who is here and what they are doing without lying, cluttering, or surveilling — when they are handled together. These are the behaviours mature SaaS products share across their avatars, stacks, presence dots, and live cursors.
- Every avatar is identifiable even without a photo — a legible initials fallback on a stable per-user colour, the same person the same colour across every screen.
- Avatars carry a real accessible name (tooltip and alt text), never relying on the image or colour alone, and stay legible at the tiny sizes they actually render.
- Presence reports availability truthfully and in near real time — online, away, offline are meaningfully distinct, and a disconnected user flips to offline rather than sticking on a false "online".
- Presence never over-promises precision — a coarse "last seen 2h ago" is preferred over a fake live dot, and states do not flicker on network blips.
- Avatar stacks overlap, cap at a sensible count, and overflow into an actionable "+N" that reveals the full list, ordered predictably and kept visually separable.
- Live cues are attributed to a named, consistently-coloured person — cursor, selection, and avatar share the person’s colour so the eye connects them instantly.
- Live motion is calm: cursors interpolate smoothly, typing indicators debounce, idle cursors fade, and a large crowd is summarised ("6 editing") rather than swarming the canvas.
- Users control their own visibility (invisible / do-not-disturb is respected), the layer stays quiet and peripheral, and presence informs collaborators rather than surveilling them.
- Avatar-and-presence UX stays distinct from the profile/account page (managing your own identity), the comments thread (the discussion itself), notifications (what happened while away), and the activity feed (the durable who-did-what log).
Common SaaS avatar & presence mistakes
- A row of identical default grey silhouettes makes every teammate anonymous, and initials re-roll to a different colour on each screen.
- Avatars render with no name, tooltip, or alt text, so identity is a guessing game for sighted and screen-reader users alike.
- A presence dot stays "online" for someone who disconnected an hour ago, or "away" and "offline" look identical — presence users cannot trust.
- Presence dots flicker between states on every network hiccup, or claim live precision the backend cannot actually deliver.
- An avatar stack overflows past the edge of its card, or a "+N" chip leads nowhere and never reveals who else is there.
- Avatars in a stack reorder unpredictably between renders, and overlapping circles have no ring so the stack reads as one grey blob.
- A live cursor has no name label, or a person’s cursor, selection, and avatar are three different colours so nothing connects.
- A typing indicator strobes on every keystroke, idle cursors litter the canvas, and there is no way to go invisible or set do-not-disturb.
Frequently asked questions
What should an avatar show when a user has no profile photo?
Fall back to the user’s initials on a stable, per-user background colour rather than a generic grey silhouette. Most users in most SaaS products never upload a photo, so the fallback is not an edge case — it is the default state you should design first. The two things that make an initials avatar work are legibility and stability: high-contrast initials that stay readable at the 20–24px sizes avatars actually render, and a colour that is deterministically derived from the user (their id or name) so the same person is always the same colour on every screen. That stability is what turns an avatar into a recognisable identity — "the teal AM circle" becomes shorthand for a specific teammate the way a photo would. Avoid random colours that change between renders, and avoid a single shared grey default that makes everyone anonymous. Always attach the person’s name as a tooltip and an accessible label regardless of whether a photo or initials are shown, so identity never depends on resolving a tiny image. A good initials fallback makes a team of photo-less users just as legible as one full of headshots.
How accurate does a real-time presence indicator need to be?
Accurate enough that users never catch it lying, because the entire value of presence rests on trust. A green "online" dot for someone who closed their laptop an hour ago is worse than showing nothing, since once users learn the indicator is wrong they stop believing all of it. Aim for near-real-time updates driven by genuine activity signals, with meaningful states — active, idle/away after real inactivity, and offline on disconnect — that are visually distinct rather than collapsed into one ambiguous colour. Handle the unhappy paths honestly: a dropped connection should flip presence to offline rather than freezing on "online", and rapid network blips should be debounced so the dot does not strobe between states. Where your signal is genuinely coarse, prefer an honest relative timestamp ("last seen 2h ago") over a fake live dot — under-promising and being right beats over-promising and being caught out. The bar is not perfect millisecond precision; it is that whatever presence claims, a user who checks can trust it.
How should an avatar stack handle a large number of people?
Summarise rather than either listing everyone or silently hiding them. Overlap the avatars into a compact stack, cap the visible count at whatever fits the available space (often three to five), and represent the rest as a clear "+N" chip — so a project with twelve members reads as a tidy stack plus "+8" instead of a row that runs off the card or shows only a random three. The critical detail is that the overflow must be actionable: hovering or clicking the "+N" should reveal the full list of who else is there, so the summary is a doorway, not a dead end. Order the stack predictably — for example the current user first, then most-recently-active — rather than reshuffling on every render, and give each overlapping avatar a subtle ring so adjacent circles stay separable instead of merging into one blob. Reserve consistent space for the stack so the surrounding card does not jump in width as people join or leave. Handled this way, a stack scales from two people to two hundred while staying compact, legible, and fully explorable.
Study real SaaS avatars, presence, and live cursors in the SaaSUI library
Every decision above is easier to apply when you can see how real products solved it. Browse real avatar and initials-fallback treatments, overlapping avatar stacks with "+N" overflow, online/away/offline presence dots, live multiplayer cursors with name labels, and typing indicators from shipped SaaS applications like Figma, Notion, Linear, Google Docs, Slack and other polished products in the SaaSUI.Design library, with real screenshots instead of mockups, to study how mature products make avatars identifiable and accessible, keep presence truthful and real-time, handle stacks and overflow gracefully, attribute live cues clearly, and respect the user’s privacy and attention.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →