Avatar

An avatar is a small image or set of initials standing for a person or an organisation. Its job is making ownership and presence scannable: who created this, who is assigned, who is in this workspace.

That job is only done if avatars are distinguishable. A column of identical grey silhouettes communicates that a person exists and nothing else, which is the most common way this component fails.

The fallback is the component

Most avatars in a B2B product have no photograph. Enterprise users do not upload one, so the fallback is not an edge case — it is the default rendering.

Initials on a deterministic colour. The colour derived from the user ID or the name, so the same person is the same colour everywhere, every time. Random colours per render make the list useless.

Handle names properly. First character of the given name and first of the family name where both exist; one character otherwise. Splitting naively on spaces breaks on mononyms, on names with particles like "van der", and on scripts that do not separate words. When in doubt, one initial is correct and two initials from the wrong places is not.

Contrast the text against the generated colour. A palette of pastel backgrounds with white initials fails legibility on half of them. Pick the foreground per background rather than fixing it.

Organisations are not people. A company avatar should be a logo or a rounded square, visually distinct from a circle, so a list mixing users and accounts stays readable.

Groups and overflow

Overlap three to five, then count. Four faces and a +12. More than five overlapping becomes a smear.

Stable order. Sorting by recency means the faces move between renders, which destroys the recognition the component exists for.

The overflow must open. A +12 nobody can expand is decoration. It should reveal the rest, ideally in a popover.

One accessible name for the group. "Assigned to Anna Petrenko, Marko Ilyin and 12 others" rather than fourteen separate images announced in sequence.

Sizes and placement

Two or three sizes tied to the type scale: one for a dense table row, one for a list item, one for a profile header. Arbitrary sizes per screen make rows sit unevenly.

In a table, the avatar belongs beside the name rather than in its own column. A column of faces with the names three columns away asks somebody to match them.

Accessibility

The accessible name is the person's name. Not "Avatar", not the filename.

Mark it decorative where the name is already adjacent in text, so a screen reader does not read it twice.

Status dots need to reach the accessible name. "Anna Petrenko, online" rather than a green pixel that exists only visually. And presence is worth showing only where it changes what somebody does — in a tool with no real-time collaboration it is noise with an accessibility cost.

In practice

A product shows avatars in its assignee column. Nobody uploads photos, so the column is ninety identical grey circles with a person icon.

The column occupies real width in a dense table and carries no information. Users scan the name column instead and ignore the avatars entirely, which is the rational response.

Switching to deterministic initials on deterministic colours changes it in one release. The same column now lets somebody pick out their own tickets by colour before reading a word, which is what an avatar column is for.

Nothing about the data changed. The fallback had simply been designed as an absence rather than as the normal case, which in this product it always was.

Where teams get it wrong

• A generic silhouette fallback. The default rendering, carrying no information.
• Random colours. Recognition destroyed between renders.
• Naive initial extraction. Wrong letters for a large share of real names.
• Unstable group order. Faces that move, so nobody learns them.
• A count that does not open. Decoration where a control was needed.
• Status by colour alone. Invisible to some users and to all screen readers.