Chapter 6: Templates & Pages

Core Idea

Templates place organisms into a full-page layout to reveal an interface's underlying content structure with placeholder content; pages take a template and substitute real, representative content — the two final, most concrete stages of Atomic Design.

Key Concepts

• Templates = structure: a template is content-agnostic in the sense that it demonstrates where things go (this is where the header organism sits, this is where the product grid organism sits) using placeholder/lorem-ipsum-style content.
• Pages = structure + real content: a page is a specific instance of a template with actual production content and data dropped in — this is where edge cases surface (a long product title, an empty state, a user with no avatar).
• Pages are where systems get pressure-tested: real content is messier than placeholder content, so the page stage is where a template's assumptions get validated or broken.

Mental Models

Templates answer "where does this go"; pages answer "what happens when real content arrives." Treat them as two separate review passes — a template can look perfect and still fall apart once real content (a very long name, an empty list, an error state) is substituted in.

Design and review multiple pages per template. One page instance hides edge cases; testing a template against several realistic content variations (long/short, populated/empty, success/error) is what actually validates the system.

Anti-patterns

• Designing and approving only "happy path" pages: real products have empty states, error states, and long-content states — a system only validated against ideal content will break in production.
• Treating templates as throwaway: templates are reusable system artifacts (the layout skeleton), not one-off deliverables — they belong in the pattern library alongside atoms/molecules/organisms.

Key Takeaways

1. Templates define layout structure with placeholder content; pages substitute real content into that structure.
2. The page stage is where content reality (long strings, empty states, edge cases) tests whether the system's components actually hold up.
3. Review multiple content variations per template — not just one polished, ideal-content page — to catch structural fragility early.

Connects To

• Ch 5 (Organisms): the components templates arrange into layout.
• Ch 7: why building this way (atoms → pages) pays off in practice.