Figma table components

Ask a design systems team which component took longest and the answer is almost always the table. It has more states than a form, more layout rules than a page, and it has to survive a column of email addresses sitting next to a column of avatars sitting next to a column of currency, all while staying scannable. Admin panels, billing history, CRM lists, file browsers, team member screens: they are all the same component wearing different data. The 4 components and 204 variants above are what it costs to cover 15 cell types across two densities and two states.

Columns are the hard part

Figma has no table primitive, so the structure you choose early decides how much pain you inherit later. A table built as a stack of rows looks correct until one column needs to be wider, at which point you are nudging cells in thirty rows by hand. Built as a row of columns, each column is an Auto Layout frame that resizes on its own and the rows stay aligned because they are cells in the same stack. Our walkthrough of building data tables in Figma makes the case for the column-based approach step by step, and it is worth reading before you commit a design system to the other one. The cell component carries 15 types: text, avatar, avatar group, file type icon, payment method, badge, multiple badges, positive and negative trend, select dropdown, progress bar, star ratings, action buttons, action icons, and an action dropdown. Between them they cover most of what a real column ever holds.

Row density is a product decision

Cells come in sm at 64px tall and md at 72px, with header cells at 40px and 44px to match. Pick one and stay there. A 64px table on one screen and a 72px table on the next is the kind of inconsistency users feel without being able to name it, and dense is not automatically better: 64px rows suit lists people scan for one record, 72px suits tables where each row carries an avatar and two lines of text. The Dividers property switches between a divider line and alternating fills. Alternating fills earn their place in wide tables where the eye has to travel across eight columns; in a four-column table they are stripes for the sake of stripes.

Sorting and selection are states, not decorations

The header label carries an Arrow property set to up, down, a chevron selector, or nothing, plus a hover state and an optional help icon for the column that always needs a definition. That matters because a sortable column has to look sortable before it is clicked and unambiguous after. In code the equivalent is aria-sort on the header cell, per the W3C table pattern. Selection is built in too: a lead action cell in checkbox, radio, or toggle form, and a hover or selected state on all 15 cell types, so a selected row genuinely changes rather than being implied by a ticked checkbox alone. Nielsen Norman Group's breakdown of the four tasks people bring to a data table is a good sanity check on whether your table supports all of them or only the first.

What happens at 375px

Four assembled examples cover team members, companies, sales, and files, each at 1,216px on desktop and 375px on mobile, so the awkward decision about which columns survive a phone has already been made rather than left to the developer. The same tables are shown wrapped in the furniture they need in production: a card header, a filters bar, pagination, and an empty state for when the filters return nothing. Every frame exists in light and dark. Drop the result into one of the dashboard examples and the type styles, spacing, and badge colors already line up.

When it is time to build, the same tables exist in code. Untitled UI React tables are open source, built with Tailwind CSS and React Aria, with sorting, row selection, and keyboard navigation handled for you.