Template

Collecting parts was settled early. Build a button and an input field once, put them in a component library, and the same shapes come out on every screen.

Yet screens kept diverging even with identical parts. Three list screens end up with left menus at 240, 260 and 280 pixels, and the gap between the menu and the content differs on each. At the level of parts nothing is wrong, so review doesn't catch it. Every new screen redecides the same layout questions from scratch, and two people deciding separately leave two answers in the product. A year of that produces a product that feels assembled rather than designed.

A template raises that layout to a reusable unit. Where the parts go and how wide each region is gets decided once, and a new screen picks the frame and fills in content rather than starting from an empty canvas.

Fix the regions and the arrangement with the content left out. Four things get decided.

1. Divide the regions and mark only what goes in each. Grey boxes stand in for real text, which makes it look like a wireframe, except that what sits here isn't an arbitrary box but a group of parts that exists in the system.
2. Place the organisms — groups of parts that form a meaningful region. The top bar, the left menu, the list area, the detail panel on the right, each dropped into position at the size it will actually occupy.
3. Pin widths, spacing and order to numbers. Left menu 260 pixels, content maximum 960, 24 pixels between regions.
4. Decide the rules for a narrower viewport and for empty regions. Whether the left menu collapses or moves below on a small screen, and what fills the list area when there are no items, are decisions that belong at this level.

Put real content in and it becomes a page. That's why atomic design keeps the last level separate: a frame is shared across many screens, and a page is one instance of that frame with particular content in it.

"This isn't a new template. It goes inside the existing list template."

The layout matches a frame that already exists, so there is no reason to build another one.

"Set the left menu width at the template level."

Decide it one level up so nobody has to redecide it per screen.

"Let's see in the template where a long title pushes things around."

Find the limits in the frame before real content arrives and exposes them.

Pagedeck has five templates. Before Noa consolidated them, four settings screens each had a different content width. Theo built the same frames as units in code, so a new screen pulls in a frame instead of writing widths of its own, which is what keeps the two sides from drifting apart again.