Landing-page architecture

Use this reference when choosing the page argument, section set, proof, or ordering. It is a decision aid, not a template library.

Start from the decision

Map the visitor's path as a sequence of questions:

1. Is this for me and my current situation?
2. What changes if I use it?
3. Why should I believe the claim?
4. How does it work well enough to evaluate?
5. What risk, effort, or tradeoff remains?
6. What exactly happens if I act?

Remove a section when it repeats an answered question without stronger evidence.

Common page shapes

These shapes can combine, but the page should still have one dominant evaluation path.

Select proof by claim

Never strengthen a weak proof artifact by writing a stronger claim around it.

Order sections by uncertainty

Put the visitor's largest unresolved uncertainty immediately after the initial claim. For a new product that may be “does it actually exist?”; for an expensive service it may be “can these people be trusted?”; for a developer tool it may be “will this fit my stack?”

Use analytics, sales questions, support logs, search queries, interviews, and usability observations to rank uncertainty. When evidence is absent, label the proposed order as a hypothesis and make it easy to revise.

Action hierarchy

The primary action should name the result or next step when space allows. A secondary action is legitimate when it helps the same decision—for example, viewing a demo before starting a trial. It should not compete visually or send the visitor into an unrelated funnel.

Match commitment to evidence. A high-commitment action needs more risk reduction than a reversible trial, sample, or preview.

Evidence and standards

Use this reference before making standards, performance, reading-behavior, or conversion claims. Verify time-sensitive guidance live when it affects a release.

Maintained sources

• GOV.UK: identify user needs — content should support a real task, based on user evidence rather than a solution invented first.
• GOV.UK design principles — start with user needs, use data, do less, and remain consistent without forcing uniformity.
• Nielsen Norman Group: how users read on the web — foundational usability research on scanning, concise structure, and credibility cues. Treat the historical percentages as study findings, not universal current rates.
• MECLABS research catalog — archived controlled tests showing that page changes require experiments; do not generalize a reported lift to another product or audience.
• web.dev: optimize LCP — current LCP threshold and diagnostic subparts. The good threshold is 2.5 seconds or less at the 75th percentile, segmented by device; a single local run does not establish field performance.
• WCAG 2.2 — normative accessibility criteria for contrast, reflow, input, focus, motion, and other requirements.

How to use research

Separate four evidence classes:

1. Standard: a normative requirement such as a WCAG success criterion.
2. Observed product evidence: analytics, research, recordings, support questions, and controlled tests from this product.
3. External research: a transferable hypothesis whose population and method must be considered.
4. Heuristic: experienced judgment to test, not a guaranteed conversion law.

Never present a benchmark, historical experiment, or expert preference as a universal conversion rate or mandatory page pattern.

Provenance

This package was reconstructed from Tushar Mehta's earlier landing-page draft. Its strongest page-architecture, proof, assets, conversion, and review ideas remain, while fixed aesthetic defaults were removed. The earlier draft credited Emil Kowalski and Jakub Krehel's MIT-licensed skill collections and Rauno Freiberg's interaction-design writing; this version preserves that attribution without copying their reference text.

Landing-page review

Use this reference for audit mode or the final implementation review.

Inspect the rendered page

Review the live or locally rendered page at representative widths and states. When rendering is unavailable, label visual findings provisional.

Record for each finding:

• route, viewport, state, and evidence;
• the visitor question that remains unanswered;
• the source component or content owner when known;
• the likely consequence for comprehension, trust, action, accessibility, or performance;
• the smallest coherent repair and how to verify it.

Review lenses

Comprehension

• Can the intended visitor identify the product, consequence, and next step from the first viewport?
• Does terminology match the product and the visitor's language?
• Does each section add a new claim, mechanism, proof, objection answer, or action?

Trust

• Is every statistic, testimonial, comparison, badge, and availability claim traceable?
• Does product evidence show realistic content and limitations?
• Are pricing, privacy, compatibility, and operational constraints visible where they affect the decision?

Action

• Is there one clear primary action with an honest destination?
• Are form requirements, commitment, success, failure, and recovery states clear?
• Do secondary paths help the same decision rather than compete with it?

Interface

• Does the hierarchy follow the page argument rather than a stock section pattern?
• Does the page preserve the existing brand and component language?
• Do narrow layouts, keyboard use, zoom, contrast, focus, and reduced motion remain usable?

Performance and discovery

• Is the primary content server-rendered or otherwise reliably available to the intended audience?
• Is the likely LCP element identified and measured rather than guessed?
• Are title, description, canonical, share preview, structured data, and analytics accurate for this route?

Severity

• Blocker: prevents the primary action, makes a consequential claim unsafe, or causes a serious accessibility failure.
• High: obscures the proposition, proof, price, commitment, or conversion path.
• Medium: adds friction, weakens hierarchy, or creates avoidable uncertainty.
• Low: polish whose repair does not displace higher-value work.

Audit output

Lead with the verdict and the top three causes. Provide an evidence table, preserve strong existing decisions, and end with a sequenced repair plan. Do not rewrite or redesign unless the user requested changes.