# Interface pages

Source: /ux/product-and-ui/interface-pages.md

- Summary: Build every page as one actor's page, from a kind in the page kit, with one detail page per table.
- Status: Adopted, since 2026-10-02
- Principles: Fewest steps, Fewest scroll, One way
- Surfaces: Screen

## When to use

Use it whenever you design, build or review a page of an interface, whatever tool builds it.

## When not to use

Intake steps live in grid views on the table, covered in [intake views](/ux/product-and-ui/intake-views.md). A question about one record belongs in a group of its [record detail](/ux/product-and-ui/record-detail.md).

## How it works

### Give each page one actor

A page is one person's job. The operator's queue and the manager's overview are two pages, even on one table. The operator's pages come first in the sidebar.

Pass: every page names its 1 actor, and the first page in the sidebar is not an overview.

### Build every page from a kind in the page kit

Write the actor's question in their words and match it to a kind. The kind fixes the element, where the slices sit, how fields are ordered and what opens on a click.

| Kind | Question it answers | Element |
|---|---|---|
| `overview` | How are we doing, and what needs attention? | dashboard |
| `queue` | What do I do now? | list |
| `board` | Where does each one stand? | kanban |
| `register` | Show me all of them | grid |
| `log` | What happened? | list |
| `reference` | What can I use or pick? | list or gallery |
| `schedule` | What happens when? | calendar or timeline |
| `review` | Approve these, one by one | record review |
| `gallery` | Which one is it? (visual) | gallery |
| `custom` | A question no native kind answers within these rules | custom code |

Pass: every page names its kind, and the first page of each kind in an interface is the pattern the next one copies.

### Scope the rows, then slice them

The scope keeps the rows this actor can act on. Slices narrow them further. Rows nobody will touch leave the scope, or get a tab named for what they are, such as `Parked`.

Pass: every row in a queue's first tab has an action the actor can take today.

### Use one filter mechanism per page

A page uses tabs or dropdowns, never both. See [filters](/ux/product-and-ui/filters.md) for the order of each.

Pass: no page carries both tabs and dropdowns.

### Keep one detail page per table

Every page and every link pill opens the same detail for a table, and every element opens that detail on a click. A second detail for the same table is a break even when it looks better.

Pass: every table has exactly 1 detail page.

### Merge pages that show the same rows

Two pages with the same rows and the same fields are one page with slices.

Pass: no two pages of one actor share both their scope and their fields.

### Add slices when a question needs them

The first version of a page has its scope and one slice style. A dropdown, a second page or a dashboard section comes when a question appears that the page cannot answer. An actor with more than four pages is probably getting one page per wish.

Pass: every slice, dropdown and section names the question that required it.

## Research

The interface skill's page kit and process are the source of these rules, and both were built on the reviewer's feedback. No outside guide has been found for them.