Figma informational page examples

Dashboards get designed first and screenshotted for the pitch deck. The pages people actually spend their working day on are duller: a list of invoices with a filter bar, a candidate profile, a message thread, a booking calendar, an API reference.

Those are what this set calls informational pages, the screens inside an app whose job is to show a record or a list of records clearly enough that someone can find the one thing they came for and act on it.

What the set actually covers

The range is wider than the name suggests. There are record tables with a filters bar and pagination, tabbed table views with a row of metrics above them, calendar views, message threads and inbox layouts, an activity feed, API documentation pages with code snippets and tabbed examples, a search results page with listings beside a map and date and location filters, job listing pages built from job cards, and a profile page with reviews, star ratings, a text editor, and file upload.

Each opens with a page header carrying the title and the page's primary actions, which is the anchor everything else hangs off.

The table is usually the page

Most of these screens are a table with framing around it, so the table decides whether the page works. NN/g's breakdown of the four major tasks people bring to data tables is the right checklist: finding a specific record, comparing records, viewing or editing a single row, and acting on one or several rows.

Every one of those needs different affordances, which is why the examples pair the table with a filters bar and pagination rather than leaving it bare. Filtering and sorting cover finding. A row action menu covers acting.

If a page supports all four tasks well it will feel unremarkable, which is the goal.

Then there is mobile, where a wide table has nowhere to go. NN/g's guidance on tables on small screens is worth following before you invent something: lock the headers, signal that the table scrolls sideways, and let people choose which columns they need instead of shrinking all of them.

The 375px versions here make those decisions rather than scaling the desktop layout down.

Two shells around the same page

Each example is drawn twice: once inside a sidebar navigation shell and once with an application header navigation across the top. That answers the argument teams have early and expensively, because you can put the same real screen in front of stakeholders both ways rather than describing the difference.

Every version exists at 1,440px desktop and 375px mobile, in light and dark.

Tabs turn up on a lot of these pages, usually directly under the page header, splitting a record into overview, activity, and settings.

Worth designing with the W3C tabs pattern in mind: arrow keys move between tabs, and panels should switch as focus lands unless the content is slow to load. It is the sort of thing that costs nothing to note in the design file and is expensive to retrofit.

The build side is already covered. Untitled UI React informational pages are open source, built with Tailwind CSS and React Aria, with table semantics, tab behavior, and keyboard navigation already handled.