Landing Page Design skill for Codex

A landing page works when a first-time visitor understands what it is, who it is for and what to do next within five seconds on a phone, every section answers the next question that visitor would ask, and the one primary action is visible at every decision point. Beauty is necessary but secondary; a gorgeous page with three competing goals converts worse than a plain one with one.

Inputs before designing

Write these down; ask only for what cannot be inferred from the repo or product:

• Goal: the single conversion (start trial, book demo, join waitlist, buy). Secondary actions (docs, contact) are allowed only as quieter links.
• Audience and traffic source: ad click, search, launch post, email, partner. Message match matters: the hero must echo what brought them here.
• Awareness stage: do they know the problem, the category, the product?
• Proof available: customer logos with permission, quotes with names, metrics, ratings, case studies, security certifications. Never invent any of these.
• Constraints: brand system, framework, CMS, analytics tool (check AGENTS.md).

Section order by awareness

Visitor knows	Lead with	Typical order
Nothing (cold ads, social)	The problem in their words	Problem hero, cost of the problem, how it works, proof, offer, FAQ, CTA
The problem, not solutions	The outcome	Outcome hero, how it works (3 steps), product in action, proof, objections, CTA
The category, comparing	Differentiation	Positioning hero, comparison, feature depth, proof, pricing, FAQ, CTA
Your product (retargeting, email)	The offer	Offer hero with CTA, what’s new, proof, pricing, CTA

Each section must answer one question: “What is it?”, “Will it work for me?”, “How does it work?”, “Who else uses it?”, “What does it cost?”, “What if…?”. If a section answers no question, cut it.

Hero anatomy

[Logo]                                         [Nav: 3-4 links]  [Primary CTA]
Eyebrow (optional): category or audience, 2-5 words
Headline: outcome or differentiator, 4-10 words, the page's only h1
Subhead: how it delivers that, for whom, 15-30 words
[Primary CTA: verb + object]  [Secondary: quieter link, e.g. "See how it works"]
Risk reducer: "Free for 14 days. No card required."
Proof strip: one concrete metric, rating, or recognizable customers
Visual: the product doing the thing (real UI, cropped to the moment of value)

Rules:

• On a 390 x 844 viewport, headline, subhead and primary CTA are visible without scrolling. Check with a screenshot, not imagination.
• The visual shows the product, not an abstract illustration, unless the product is invisible (infrastructure); then show the result or a diagram of the effect.
• One h1. Headline sizes: 36–48 px on mobile, 56–80 px desktop for short headlines.
• Navigation is minimal on paid-traffic pages; every extra link is an exit.

CTA design

• Label = verb + what they get: “Start free trial”, “Get the report”, “Book a 20-min demo”. Avoid “Submit”, “Learn more” as a primary.
• Same label and destination every time it appears; repeat after proof, after pricing and at the end. On long pages, a sticky header CTA after the hero scrolls away.
• Primary CTA is the most saturated element in its viewport; no other element uses the accent at the same weight.
• Minimum 44 px tall, full width on mobile when it is the main action of the section.
• Put the risk reducer (free tier, cancel anytime, time required) directly under it.

Proof placement

Proof type	Place it
Logos	Under the hero, only if recognizable to this audience; 5–8 max
Quote with name, role, photo	Next to the feature claim it supports
Metric (“cut close time from 9 to 3 days”)	In the hero proof strip or the outcome section
Case study	After “how it works”, with one number in the card
Ratings (G2, App Store)	Near the CTA and pricing
Security / compliance badges	Near forms and pricing for B2B

Specific beats generic: “Saved our finance team 11 hours a week” with a name and company beats “Amazing product!”.

Pricing and objections

• Show price on the page when it is public; hiding it raises doubt. Highlight one plan as recommended; annual/monthly toggle shows the saving.
• FAQ answers real objections (data security, migration, contract length, what happens after the trial), five to eight items, using <details> for native accessibility.
• Comparison tables: your column first or highlighted, rows phrased as outcomes.

Forms

• Ask for the minimum: email for a waitlist or trial; add fields only if sales qualification truly requires them. Each extra field costs completions.
• Inline validation on blur, clear error text, labels always visible (see form-ux).
• After submit: a confirmation state on the page that says what happens next.

Build notes

• Hero image: fetchpriority="high", explicit width/height, AVIF/WebP, no lazy loading. Target LCP ≤ 2.5 s and CLS ≤ 0.1 at p75 on mobile.
• Avoid carousels and autoplay video in the hero; if video is essential, use a poster image and play on click.
• Fire analytics events: cta_click (with location: hero, pricing, footer), form_start, form_submit, pricing_toggle. Check the project’s analytics wrapper and naming convention first.
• Respect cookie consent: no tracking before consent where required.

Workflow

- [ ] 1. Write goal, audience, awareness stage, proof inventory
- [ ] 2. Choose section order from the awareness table; write the outline
- [ ] 3. Wireframe the hero at 390 px and 1440 px
- [ ] 4. Draft section content (real copy or clearly marked drafts)
- [ ] 5. Build sections; apply the visual direction (frontend-design)
- [ ] 6. Add analytics events and form handling
- [ ] 7. Verify: 5-second test, fold screenshots, Lighthouse, events

Verification

• Five-second test: show the 390 px hero screenshot to yourself cold; can you state what it is, who it is for and the next step? If not, rewrite headline or subhead.
• Fold check: npx playwright screenshot --viewport-size "390,844" <url> .shots/fold.png; primary CTA visible.
• Squint test: the CTA is one of the two heaviest elements in the hero.
• Lighthouse mobile: LCP, CLS and accessibility pass budgets: npx lighthouse <url> --only-categories=performance,accessibility --output=html --output-path=.shots/lighthouse.html (mobile emulation is the default). It needs a local Chrome, and npx may need network approval to fetch the package.
• Events: click every CTA with the analytics debugger or network panel open; each fires once with the right location.

Gotchas

• Clever headlines that need the subhead to make sense. Clarity first, wit second.
• Feature lists without outcomes; each feature line should say what the user gets.
• Six equal CTAs across the page with different labels and destinations.
• Testimonials grouped in a carousel nobody advances; place quotes beside claims.
• Logo walls of companies whose permission you do not have. Ask the user.
• Sending users from a focused landing page to a generic homepage on CTA click.

Output contract

**Goal:** <conversion>  **Audience/source:** <who, from where>  **Awareness:** <stage>
**Outline:**
1. Hero: <headline draft> / CTA "<label>" / proof: <item>
2. <Section>: answers "<question>"
...
**CTA placements:** hero, after proof, pricing, footer (same label)
**Proof used:** <list with source/permission status>
**Events:** cta_click{location}, form_start, form_submit
**Checks:** 390 px fold ok, LCP <x> s, CLS <y>, a11y score <z>
**Draft copy to replace:** <sections>