Skip to main content
A Singapore Government Agency Website
LAY-3L2 · recommendedjudgmentLayout

A surface maps to a known page template (workspace view, form, flow step, dashboard, settings, empty state, onboarding) rather than an ad-hoc shell

Fails when: a surface invents a bespoke shell structure when an existing template applies · information hierarchy does not match the declared page type

Requirement

Build a surface as the page template its type implies, not as a fresh shell each time. The Phase 1 contract already declares the page type — workspace view, form, flow step, dashboard, settings, empty state, onboarding. Each carries a familiar shell (where the title sits, where the primary action lives, how the body is organised). Adopt it. Invent structure only when no template fits, and say so.

Rationale

People move between products all day; templates are what let them carry muscle memory across surfaces (HIG: Familiarity). A settings page that puts its save button somewhere new, or a form laid out like a dashboard, makes the person re-learn the surface before they can use it — the opposite of Kind Utility. The page type is decided in Phase 1; LAY-3 holds the build to it so the declared type is a promise, not a label.

Passes when

  • A settings surface uses the settings template — grouped sections, labels left, a consistent save affordance — like every other settings surface in the product.
  • An empty state uses the empty-state template (heading + subtext + single CTA), not a half-built list shell.
  • A form follows the form template: fields top to bottom, labels above, one primary submit (CMP-5), errors inline (CNT-1).
  • A genuinely novel surface with no matching template introduces structure deliberately, and the plan notes why no template applied.

Fails when

  • A dashboard-style grid used for what the contract calls a form.
  • A bespoke shell invented for a settings page when the settings template already exists in the product.
  • Information hierarchy that contradicts the declared page type — a flow step that reads like a dashboard, burying the one next action.

How to verify

Judgment. The evaluator reads the Phase 1 declared page type and checks the built surface against it: does the structure match the template that type implies, or did it re-invent the shell? There is no static check — IA-template matching is a judgment read of the screenshots plus the plan.

Evaluator guidance

Flag: a surface whose structure does not match its declared page type; a bespoke shell where a known template clearly applies; a hierarchy that fights the page type.

Do not flag:

  • A surface that legitimately has no matching template and says so in the plan — novelty with a stated reason is not a violation.
  • Per-product nuance within a template (two products' settings can differ in accent and tone; the template is shared, the skin is not).

Deconfliction. LAY-3 is the positive statement; SLP-10 is the specific anti-pattern (a multi-section task must be a page, not a modal). A11Y-7 is HTML-element semantics — a page can pass A11Y-7 (correct headings/lists) yet fail LAY-3 (wrong IA template). This is L2: a reasoned deviation takes an inline dx-waive LAY-3 reason="…".

Also available as Markdown · catalog.yaml