Figma section footer components

Most of a screen's attention goes to the top of a section. The bottom gets whatever is left over, which is why so many tables end in a ragged row of buttons that arrived one at a time over six months.

A section footer is the designed version of that row: a closing bar for a section or a card, carrying the actions that apply to everything above it. There are 8 variants here across two types.

Card type or section type, twelve pixels apart

The Type property picks the context. A section footer closes a block sitting directly on the page and stands 57px tall on desktop at 1,216px wide.

A card footer sits inside a card, where the container's padding and edge take it to 69px. Twelve pixels of difference, which sounds trivial until someone rebuilds the row by hand for the third time and lands on a number nobody else used.

Both types have mobile versions, a few pixels shorter at 53px and 61px, so the row keeps its shape on a phone instead of restacking into a column. Form-heavy screens like the settings pages tend to use the card type, since the actions belong to the card they close, not the page.

Button group or plain buttons

The second property is the button group toggle. Switched on, the footer carries a segmented button group, which suits previous and next controls or a small set of related choices. Switched off, it is plain buttons.

Order matters more than either option: Nielsen Norman Group's piece on OK and Cancel argues that matching the platform convention beats optimising any single row, so pick one order for confirm and cancel and hold it across the product. Users stop reading button labels after a while and start reaching for positions.

Where pagination actually lives

The slot under a table is where page controls go, but pagination ships as its own component rather than a variant of this one, and the separation is deliberate. A table needs page numbers and a count; a settings card needs Save and Cancel. Merging both into one component makes both worse.

Pagination comes with page numbers, previous and next arrows, and the count line, and it drops into the same position as these footers. Worth knowing before you design it: NN/g's research on list paging found people ask for a view all option and complain when it is missing, so for a list of forty rows the kindest footer is the one that offers to show everything.

Bulk actions and the row that appears

The other thing that lands in this slot is the bulk action bar, the row that shows up once someone ticks a checkbox in a table. It behaves differently: it appears on selection, it names a count, and its actions apply to the selected rows rather than to the section.

Design it as a state of the footer area rather than a second bar stacked under the first, or the table carries a permanent row it does not need at rest. The same discipline as the top of the screen applies here, where the section header holds the controls and the footer holds the conclusions. Every frame in the file is drawn twice, light and dark, so the footer's border and fill both survive the theme swap.

The same footers exist in code when you get there. Untitled UI React section footers are open source, built with Tailwind CSS and React Aria, with the button layout and responsive behavior handled for you.