layout-paradigms-and-consistency

Files (1)

• SKILL.md

SKILL.md (first lines)

# 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 brand intent first → derive the paradigm that supports them → then apply consistency.** Part 1 is how you derive it; Part 2 is how you keep it.

---

## Part 1 — Choose the paradigm that fits the content

Start from the nature of the content and the primary task, not from a default grid. Ask: *what relationship between items matters most here?* The answer points to a paradigm.

| Content nature / primary task | Layout paradigm | Why it fits | When NOT to use it |
|---|---|---|---|
| A stream of recent, homogeneous items, consumed top-down | **Feed** | Recency and flow are the message; infinite, low-commitment scanning | When items must be compared field-by-field, or order is not temporal |
| Items moving through stages of a workflow | **Board / Kanban** | Columns make state visible and transitions physical (drag) | When there are no discrete stages, or items have many attributes to compare |
| Many records compared across the same fields | **Table** | Aligned columns make values directly comparable; sort/filter is natural | When records are visual or heterogeneous, or on small screens |
| Browsing visual, heterogeneous items | **Gallery / Grid** | The artifact itself is the content; thumbnails carry meaning | When precise values matter more than the visual |
| A list plus the detail of the selected item | **Master–detail / Split** | Keeps context while drilling in; fast scanning + deep reading. Detail starts where the list ends, not at the far edge — see [[gestalt-ui-organisation]] | On mobile where two panes don't fit (collapse to drill-down) |
| At-a-glance overview of many metrics | **Dashboard** | Spatial arrangement lets the eye triage what needs attention | When the user has one task, not monitoring — it becomes noise |
| Spatial relationships, free arrangement | **Canvas** | The user's spatial model *is* the data (diagrams, design, maps) | When content is inherently linear or ordered |
| Events ordered in time | **Timeline** | Time is the primary axis; gaps and density are meaningful | When time is just one of many equal attributes |
| Geographic data | **Map** | Location is the primary dimension | When location is incidental to the task |
| One object, one task, full attention | **Single-focus / Wizard** | Removes everything but the current decision | When the user needs surrounding context to decide → see [[user-flows-and-guided-paths]] |
| Persuading a stranger who has not bought in yet | **Narrative long-scroll** | Sequence *is* the argument — each section earns the next scroll | Inside the product, where the user has already committed and wants to work |

The paradigm interacts with other layout skills: it must group coherently ([[gestalt-ui-organisation]]), establish one clear emphasis ([[visual-emphasis-and-hierarchy]]), reflect the data model and naming ([[information-architecture]]), and adapt — not merely shrink — across breakpoints ([[responsive-paradigms]]). Where a real-world metaphor reinforces the paradigm (a board feels like cards on a wall), lean on it ([[real-world-metaphors]]).

**A view can offer more than one paradigm.** A collection of records is legitimately a table *and* a gallery *and* a board, chosen by the user per task — see [[data-display-and-selection]]. The point is that each option is a *deliberate* fit, not an accident.

### The narrative long-scroll — the product narrative framework

Marketing and landing pages are the one paradigm where **sequence is the argument.** Every other paradigm arranges content the user already wants; this one earns each scroll from someone who has committed to nothing. Judge a landing page by how it carries a stranger through these beats — not by whether the sections look good in isolation.

| # | Beat | The job | Typical treatment |
|---|---|---|---|
| 1 | **Hook** | Stop the *right* visitor and make them want to keep reading | Large headline, generous whitespace, supporting line, product shot / video / demo alongside |
| 2 | **Problem empathy** | Prove you understand the visitor's current situation | Named pains — slow, costly, manual, unreliable, scattered, hard to source |
| 3 | **USP** | What it is, who it's for, why it's different — in one sentence | One clear statement, given room |
| 4 | **Value propositions** | The 3–5 differentiated benefits | Benefit phrasing, not feature or spec nouns |
| 5 | **Proof points** | A reason to believe each claim | Whatever counts as evidence in the field — customers, figures, case studies, certifications, test data, materials, stock and delivery times, before/after |
| 6 | **How it works** | Remove uncertainty about mechanism and effort | Three steps, in the field's own terms — order/fit/measure, connect/process/result, browse/try/return |
| 7 | **Stakes** | What it costs to do nothing | Downtime continues, competitors move, time and money leak, the problem recurs |
| 8 | **Call to action** | The obvious next step | A verb the visitor can picture doing |

The beats are the same everywhere — B2B and B2C, software and physical goods, a global manufacturer and a local shop. What changes is their **weight and their evidence.** An industrial or spare-parts buyer wants proof, specification, fit and availability, and will read further to get it; a fashion or consumer page carries the hook in the imagery itself and reaches the CTA in far less scrolling; an internal tool's page can skip persuasion but still owes the visitor *what this is, why it exists, how to start*. Decide which beats carry the load for **this** audience before deciding what the page looks like.

**The hook is a question, not a summary.** A good hero states one value and leaves the visitor thinking *"I want to see how this works."* It gets that from size and air, not decoration ([[visual-emphasis-and-hierarchy]]). If the short headline is not explanatory enough alone, add a smaller supporting line under it rather than lengthening the headline. Pair it with the product actually running — screenshot, video, or live demo, never a mockup of behaviour the product does not have ([[authentic-product-representation]]).

**Value propositions are benefits, not features.** "AI dashboard" and "14 mm hardened steel" are nouns; "the numbers that matter at a glance" and "survives a season of gravel roads" are what the visitor gets. A line that could sit unchanged on a competitor's page is not a value proposition.

**Every claim carries proof.** The bolder the claim, the harder the evidence. What counts as hard evidence is set by the field, not by fashion — a test report and a fitment guarantee do the work a customer logo does elsewhere. Unproven superlatives cost credibility on the claims that *are* true.

**Stakes come from consequence, not pressure.** State what standing still costs. Manufactured scarcity — fake countdowns, invented "3 spots left" — spends the trust the rest of the page just built.

**The CTA names the action.** "Learn more" describes nothing. "Start free", "Check fitment", "Request a quote", "Find your size" tell the visitor what happens next, and hand off to a flow that delivers exactly that ([[user-flows-and-guided-paths]]).

#### The question chain

The narrative works because it answers the visitor's questions in the order they arise:

> What is this? → Is it for me? → Why is it better? → Can I trust it? → How does it work? → How much effort is this? → What do I do next?

This is the sharpest test here. Walk the page top to bottom and mark where each answer lands. If the visitor has to hunt or scroll back, the narrative is broken however good the sections look. Answering early is a defect too — pricing above the fold answers *"how much effort?"* to someone still asking *"what is this?"*.

#### What the strongest pages share

The best pages in every sector — a developer platform, a machine-tool supplier, a clothing label, a regional garage — converge on the same discipline:

- **One message per viewport** — each section answers exactly one question in the chain.
- **No more copy than the beat needs** — persuasion sections stay short and carried by whitespace, while specification and proof sections are allowed the detail a serious buyer came for.
- **Real product imagery and video** over abstract illustration or stock photography.
- **Benefit to proof, fast** — claims do not stack up unsupported.
- **The CTA repeats down the page**, so the visitor can act the moment they are convinced.
- **One visual rhythm** — section spacing, type scale, and imagery treatment repeat ([[modular-scale-typography]], [[brand-visual-language]]).
- **Restrained motion** that supports the sequence instead of competing with it ([[motion-and-storytelling]]).

Density here is the deliberate *opposite* of an expert tool ([[ui-density]]). A landing page serves someone who owes you no attention; a dashboard serves someone who has already committed. Do not import habits from one into the other.

---

## Part 2 — Reuse the paradigm consistently across the application

Once a paradigm is chosen for a kind of content, every screen of that kind uses the same paradigm and the same page skeleton. This is what lets a user learn the product once.

### Page skeletons should be templates, not one-offs

Define a small set of page templates and reuse them:

- **List / index page** — same position for title, filters, view-mode toggle, primary action, and the collection itself, on *every* list page.
- **Detail page** — same skeleton for every detail screen: header (name + status + primary actions) → key attributes → related content → activity. When a user learns one detail page, they have learned them all.
- **Editor / form page** — consistent placement of the form body, validation summary, and the save/cancel actions → see [[form-design]].
- **Settings page** — consistent section structure and control alignment.

From dembrandt/dembrandt-skills, MIT.

More from dembrandt/dembrandt-skills