Figma activity feed components

Every product that lets more than one person touch the same object eventually grows a feed. Who changed the status, who uploaded the file, who left the comment, in order, with faces attached.

It is a dull component to draw and an easy one to get wrong, because one row is trivial while a hundred rows is a product decision. These 2 components and 22 variants cover the row and the column it lives in.

The grouping problem

A feed that reports every event faithfully becomes unreadable at exactly the moment it becomes useful. Twelve people edit a document over an afternoon and the honest version is forty rows of somebody editing something. Real feeds collapse that, folding the same actor doing the same action inside a short window into one line with a count, and putting the detail behind a click.

Choosing that collapse rule is the actual design work here, and it is a product decision rather than a styling one. Nielsen Norman Group's separation of indicators, validations, and notifications is useful nearby: a feed is a passive record people consult when they choose to, while an alert demands a response, and the moment you start pushing feed rows at people as notifications you owe them a way to turn the volume down.

Two feed types, and what the connector implies

The feed component comes as a notifications type and a messages type, each 360px wide, with the messages version running several hundred pixels taller because a quoted comment needs more room than a status change.

The divider property is where the character sits. A connector draws the vertical line between avatars that turns a list into a timeline, which is right when order and elapsed time carry meaning, like a deployment log or an approval chain, and misleading when the rows are simply recent and unrelated. A line or a plain divider separates without implying sequence. Setting it to none gives you the compact stacked version for narrow surfaces.

The file itself shows the feed inside a 440px drawer, which is where most activity feeds end up in an application, usually over a dashboard.

Item sizes and what hangs off them

The feed item base has two sizes, sm and md, and a supporting item property deciding what sits under the sentence: nothing, a file attachment, a row of labels, or a block of quoted text. The heights are the useful part. A bare item is 40px, or 72px once the connector adds its vertical run.

Attach a file and it becomes 92px, labels 94px, quoted text 136px, each gaining roughly 30px with the connector switched on. That spread is why a feed of mixed types looks ragged unless you decide early which supporting types you will actually allow, and two is usually enough. File rows pair with your file uploader styling, label rows with your tags.

Timestamps, live updates, and handoff

Two things get argued about in every review. Relative timestamps read faster and go stale the instant somebody screenshots them; absolute ones survive being pasted into a bug report. Show relative, put the exact time in a tooltip, and stop holding the meeting.

The second is whether the feed updates while a person is looking at it. If it does, it is a live region once built, and the W3C feed pattern sets out how to do that without the page fighting the screen reader, giving each item its position and set size so a keyboard user knows they are on item four of thirty rather than adrift in an infinite column.

Both feed types are drawn twice across the file, light and dark, and everything sits in Auto Layout, so a row grows with a long comment instead of clipping it.

When the events start arriving from a real backend, Untitled UI React activity feeds are open source, built with Tailwind CSS and React Aria, with the connector rendering and item composition already sorted.