Landing Page Design

Landing Page Design combines offer strategy, page structure, conversion copy, and an opinionated visual system for a requested landing-page plan, build, or review. It treats a landing page as a surface serving one intent: one offer, one audience, and one primary action. Strategy and content come before visual implementation.

Intake establishes the intended action, offer, conversion event, audience, problem, objections, traffic source, and visitor knowledge. It also gathers proof, screenshots or video, verified offer terms, brand voice, visual direction, and mobile priorities. Missing information is requested together. If the user cannot answer, the workflow states a reasonable assumption and continues rather than stalling.

The structure connects an outcome-and-audience headline to a clarifying subheadline, one primary CTA, a proof signal, and a hero visual. The middle develops the problem-to-solution argument, three to five outcome-led benefits, a three-step process, and social proof. The lower page addresses objections through six to twelve FAQ entries, confirmed risk-reduction terms, and a final CTA matching the first. A scroll-driven tagline reveal belongs in the middle argument.

Use this skill for a landing page that should follow this particular typography, spacing, proof-placement, and tagline approach. It covers planning from scratch and conversion or design review of the requested surface. Existing-site upgrades can use the companion redesign workflow for diagnosis while taking concrete values from this system.

These defaults do not override explicit user requirements, an existing brand system, scope, or accessibility. Apply the system only to the requested landing page or related surface. Do not extend a redesign to unrelated dashboards or components. There is no guaranteed conversion-rate, search-ranking, accessibility, or legal-compliance outcome.

Keep real claims tied to supplied or verified evidence. Prices, guarantees, customer logos, people, testimonials, and metrics must not be invented. Fictional demos need clear labels, and missing evidence uses marked placeholders. Actual product terms determine whether a trial, free plan, cancellation option, or guarantee can appear. Legal requirements and indexing choices need confirmation for the project.

The skill needs an existing project or agreed output format, product and offer facts, and approved brand assets. Before code, it produces an ordered page outline, hero headline and supporting copy, primary CTA and proof line, benefits, process, FAQ, indexing recommendation, and layout rationale. Indexed pages also receive a proposed title and meta description.

Layout selection has four options. A classic hero with sections fits products understandable from a screenshot. A long-form story helps educate skeptical visitors. A minimal conversion page fits high-intent traffic or a short download or waitlist offer. A comparison page fits search intent involving alternatives. The choice includes a reason rather than defaulting to the same arrangement.

Copy matches the traffic source: an ad's promise and visual tone carry into the hero. Benefits precede features, specific evidence replaces vague claims, and the CTA combines a verb with what the visitor receives. Competing actions stay out of the first screen. Proof sits beside the claim it supports, and high-friction offers can bring FAQ content earlier.

Implementation proceeds section by section: hero, benefits, process, proof, FAQ, then final CTA. This keeps iterations controlled instead of rebuilding the whole page each time. Ad-only campaigns and highly time-bound offers are candidates for exclusion from indexing. Evergreen offers matching search intent can be indexed, with internal links, plain question-and-answer FAQ content, and appropriate FAQ schema.

The visual checklist uses one approved typeface, named text styles, Tailwind scale steps, table-based spacing, and a nested-radius formula. It excludes italics, ultra-bold text, single-sided card borders, background gradients, orphaned words, and hyphens within copy. Hero heading and subheading widths are capped at 680px with deliberate line breaks. Icons come from Phosphor, Solar, or Iconamoon. Motion uses the prescribed base curve and IntersectionObserver for scroll reveals; the tagline has at least two lines with words activating individually.

Delivery checks cover 390px overflow, readable content without JavaScript, reduced motion, contrast, interaction and loading states, empty and error states, working links, current navigation, form validation, a 404 page, legal links, favicon, metadata, and alternative text. Browser and assistive-technology verification remain specific to the project.

The skill contains no scripts and makes no network calls itself. Browser preview, fonts, and icon libraries depend on the target project. Fetching packages, fonts, or assets can contact third parties and must remain authorized. Publishing, deployment, purchases, permissions changes, and sending private files to a new service require the corresponding permission.