Page Templates: The Floor Plan for UI

Why it exists

Design systems start with small pieces like buttons and inputs, but products are built as full pages. Without a layer that governs how those pieces assemble into complete screens, every team ends up reinventing the same grids, sidebars, and responsive breakpoints. Page templates exist to stop that repetition by codifying the recurring structural skeletons that show up again and again across a product.

The mental model

Think of a page template as a floor plan rather than the furniture inside. It specifies where rooms go, how wide the hallways are, and where the doors connect, but it does not dictate which couch sits in the living room. In the same way, a template defines regions or slots such as a top navigation area, a sidebar, and a main content zone, while remaining agnostic about the specific components that eventually fill those zones.

How it works

A template is documented as a layout pattern with named placeholders and rules about how they behave across breakpoints. In code, it often surfaces as a higher-order layout component or a page-level file that imports and arranges lower-level components. The design system maintains a library of these templates, each mapped to a recognizable page type, and documents which components are approved for each slot. This creates a contract between design and engineering: the template owns the page architecture, while the contents remain swappable.

When to use it

Reach for a page template whenever you see the same page architecture repeated across multiple features. Dashboard overviews, settings screens, search result listings, and documentation articles are all classic candidates. They are especially powerful in large organizations where several squads ship concurrently and need to keep the product feeling coherent without centralizing every minor decision.

When not to use it

Avoid forcing a one-off marketing campaign or an experimental flow into an existing template just because it exists. When the layout itself is the differentiator, a template becomes a straitjacket rather than a shortcut. Also resist the urge to template at too granular a level; if a pattern is really just a row of cards, it belongs in the component layer, not the page layer.

One canonical example

Consider a documentation site that uses an Article Page template. The template provides a sticky table-of-contents sidebar on the left, a fluid content area in the center, and a related-links sidebar on the right, all wrapped in a consistent top navigation bar. Writers and developers drop in content components without deciding where sidebars sit or how the grid collapses on mobile, yet every article page automatically shares the same responsive behavior and spacing.