Avatar
Concept
A small round image that stands in for one user account, so anyone can tell who did what without reading a name.
Why it exists
People show up constantly on the screens of a collaboration tool. Who edited this paragraph, who left this comment, who else has the document open right now — that information appears on line after line. Spell all of it out in written names and the screen fills up with names.
Pagedeck's early document view worked that way. Open a planning doc with twenty comments and the same handful of names printed down the left edge twenty times. Grouping three comments from one person meant reading each name and matching it against the last one, and by the time someone scrolled halfway down they had lost track of who they had just read. A name is information you have to read to use, which makes it weak for scanning.
An avatar moves that information out of text and into a picture. People separate blocks of color and faces far faster than they separate written names. When the same circle turns up in several places, a reader recognizes it as the person from a moment ago without reading anything. That is also why avatars sit in the display branch of the UI component family rather than the branch you click. An avatar is not something a user operates. It reports who is currently involved.
How it works
An avatar takes one picture attached to a user account and crops it into a circle at a fixed size. It looks like a single part, but four decisions run in order inside it.
- What to show. If the user uploaded a photo, use it. If not, show the first letter or two of their name. If there is no name either, fall back to a generic person shape. Skip this order and accounts without a photo leave an empty square where a face should be.
- What shape to crop to. A common split is circles for people and squares with rounded corners for teams or company accounts, which lets a reader tell the two apart at a glance. Within one product the rule stays fixed.
- What size to place. Most teams define three or four steps — something like 24, 32, 40 and 64 pixels — and pick a step per location. Leave the size open and avatar heights start varying from row to row inside the same comment list. Those values get names as design tokens, the unit that attaches a name to a value like a color or a spacing step so design files and code read the same number.
- What to announce. A user who does not see the screen needs the picture delivered as sound, so an avatar carries the person's name as its alt text — the written description that stands in for an image. Write "profile image" there instead and all twenty avatars on the screen read out identically, which erases the distinction the avatar was there to make.
When several people have to fit on one line, avatars overlap slightly and the remaining count follows as something like +5. A document with thirty participants would otherwise render a row of avatars wider than its own title. Most teams cut the overlap off somewhere between three and five.
Where it shows up
Avatars appear wherever a person is attached to something on screen. Inside Pagedeck there are four such places.
- Comments and activity history. Each row carries the person who did it at the front. This is where avatars are densest, so it also uses the smallest size step.
- The live editing view. Everyone currently in the document lines up along the top, and inside the text each cursor carries a smaller one beside it.
- The account menu in the top right corner. Clicking your own avatar opens settings and sign-out in a popover, a small layer anchored to the element that triggered it. This spot is close to an exception, since the avatar is both a display and a click target.
- Member lists. When workspace members are laid out in a table — rows and columns that make values easy to compare side by side — the avatar sits in front of the name column.
Anything an avatar cannot carry on its own gets layered on top of it. A green dot for online, or a count of unread items, rides in the corner as a badge, the small marker that reports a count or a state. If that state is carried by color alone, it says nothing to a reader who cannot separate the colors, so varying the position or shape of the dot as well is the safer choice for accessibility.
How it sounds at work
"Everyone without a photo renders as the same gray circle. Can we at least show initials?"
The default state fails to distinguish anyone, so the avatar is not doing its job.
"Let's standardize the comment list at 24 and use 32 only for the live participant row."
An agreement to fix which size step belongs in which location.
"With eight participants, overlap five and fold the rest into a +3."
A request to cap the count so the avatar row stops pushing against the width.
At Pagedeck this part was cleaned up by Noa. She noticed the activity view rendering avatars at 28 on some rows and 36 on others, cut the sizes down to four named steps, and wrote them down. Theo moved those values into code variables and settled the fallback order for accounts with no photo at the same time. Photo, then initials, then shape — once that order was in place, the empty squares that used to appear now and then stopped appearing.
Conversations about avatars got shorter afterward. With sizes and defaults already decided, the only open question on a new screen is where one goes.
What people get wrong
The most common mistake is treating an avatar as decoration — nice to have, harmless to drop. It is one small picture that accepts no input and runs no action, so the assumption is an easy one to make. But the job of an avatar is distinction, not decoration. It lets a reader group one person's remarks across twenty comment rows and see who has the document open without counting. Remove avatars, or render them all in the same gray, and users fall back to reading names to do that work, which slows down every pass over the screen.
The opposite belief also shows up: that an avatar only works if it holds a real face. Teams treat accounts without photos as a problem and start pushing upload prompts into the interface. What the component needs is not a face but a mark that differs per account. Initials over a color assigned consistently to each account separate people well enough without a single photo.
Where to go next
- UI component
see the family of parts an avatar belongs to before going deeper
- Badge
it rides in the corner of avatars often enough that the two get designed together
Last updated 2026-09-16