/layout-paradigms-and-consistency

name: layout-paradigms-and-consistency
description: A layout is not a neutral container — choosing the right layout paradigm (feed, board, table, canvas, master-detail, dashboard, gallery, timeline, map, single-focus, narrative long-scroll) is a design decision that shapes how content is understood. Landing and marketing pages get a product narrative framework — hook, problem, USP, value props, proof points, how it works, stakes, CTA — used to review whether the page carries a visitor to a decision. Once chosen, the same paradigm and page skeleton must be reused consistently across the application so users build one mental model. This is consistency at the macro scale, above component and token consistency. Use when deciding the overall structure of a screen, designing page templates, or reviewing whether screens across a product feel like one coherent application.
metadata:
  priority: 8
  pathPatterns:
    - "app/**"
    - "pages/**"
    - "src/pages/**"
    - "src/app/**"
    - "**/layouts/**"
    - "**/templates/**"
    - "**/*.tsx"
    - "**/*.jsx"
    - "**/*.vue"
    - "**/*.svelte"
    - "design-system/**"
  promptSignals:
    phrases:
      - "layout"
      - "page layout"
      - "screen layout"
      - "layout paradigm"
      - "page template"
      - "app structure"
      - "dashboard layout"
      - "feed vs"
      - "master-detail"
      - "kanban"
      - "consistent layout"
      - "page structure"
      - "landing page"
      - "marketing page"
      - "hero section"
      - "product narrative"
      - "value proposition"
      - "proof points"
      - "call to action"
      - "saas landing"
  retrieval:
    aliases:
      - layout paradigm
      - layout archetype
      - page template
      - screen structure
      - layout consistency
      - cross-page consistency
      - app-wide layout
      - macro consistency
      - landing page structure
      - product narrative framework
      - marketing page review
    intents:
      - choose the right layout for this content
      - decide the overall structure of a screen
      - design reusable page templates
      - keep layouts consistent across the app
      - review whether screens feel like one product
      - structure a landing page so it converts
      - review whether a marketing page tells a coherent story
    examples:
      - should this be a feed, a table, or a board
      - what layout fits this kind of content
      - my detail pages are all structured differently
      - the app feels like several different products stitched together
      - design a consistent page template for these screens
      - review my landing page
      - our hero section is not converting
      - does this marketing page tell the right story

Layout Paradigms and Consistency

A layout is not a neutral container you pour content into. The layout paradigm you choose is part of the argument about how the content should be read, compared, and acted on. Two products showing the same data can communicate completely different things depending on whether that data is a feed, a table, or a board.

This skill operates at the **macro scale** of consistency. It sits above [[component-family-consistency]] (the *meso* scale — buttons and inputs sharing one DNA) and above token-level consistency like [[button-states]], [[status-colors-and-errors]], and [[modular-scale-typography]] (the *micro* scale). Consistency is not one rule — it is the same discipline applied at three altitudes.

Consistency operates at three scales

| Scale | What stays consistent | Where it lives | |---|---|---| | **Estate** | Brand chassis and shared shell across *separate applications* | *this skill, Part 3* + [[app-shell]] | | **Macro** | Layout paradigm and page skeleton across screens | *this skill* | | **Meso** | Component family — shared radius, height, colour logic | [[component-family-consistency]], [[brand-visual-language]] | | **Micro** | States, tokens, type scale, semantic colours | [[button-states]], [[status-colors-and-errors]], [[modular-scale-typography]], [[algorithmic-color-palette]] |

A product can have perfect tokens and a coherent component family and still feel broken — because every screen is laid out differently and the user re-orients on every navigation. Macro consistency is what makes a product feel like *one* application.

---

Layout is downstream — it serves something upstream

A layout paradigm is never the starting point. It is a *consequence* of decisions made earlier, and a *means* to ends defined elsewhere. Choosing a layout in isolation — "let's use a dashboard because dashboards look impressive" — is the most common way layouts go wrong.

**It flows down from information architecture.** The data model and structure ([[information-architecture]]) largely *determine* the candidate paradigms. Entities that move through states want a board; records compared on shared fields want a table; a hierarchy of containers and items wants master–detail. If the IA says "tasks belong to projects and have a status," the layout has already half-decided itself. Get the IA right first, then read the paradigm off it.

**It serves the brand and the story.** The same content can be laid out to feel calm or urgent, premium or utilitarian, editorial or operational. Layout is one of the loudest carriers of brand tone ([[brand-visual-language]]) and of the narrative you want the user to experience ([[motion-and-storytelling]]). A spacious single-focus layout tells a different story than a dense dashboard of the same data. Ask: *what should the user feel here, and what are we trying to say?* — then pick the paradigm that says it.

**It serves the user experience.** Ultimately the test is the user's task and context: what are they trying to do, how often, on what device, under what pressure ([[ui-density]], [[responsive-paradigms]]). The paradigm that best serves the task wins, even when a flashier one is available.

So the order is: **IA and b