Landing Page Handoff Checklist

A landing page is not ready for handoff when the desktop frame looks finished. It is ready when the team can explain the content order, component behavior, responsive transformations, interaction states, assets, and checks that define a correct implementation.

The phone-mockup composition on Refframe uses oversized type, a large directional arrow, bordered cells, and product imagery. A developer can reproduce the wide frame and still miss the design if the headline wraps badly, the phones cover the action on a narrow screen, or the arrow has no meaningful role. Handoff needs behavior, not only coordinates.

Content and conversion

• The page has one primary audience and one main action.
• The hero explains what is offered, for whom, and what happens after the action.
• Heading levels follow the content structure rather than visual size alone.
• Proof appears near the claim it supports.
• Repeated claims have been removed or given different evidence.
• Button labels describe the action instead of using vague text such as Learn more when a specific label is possible.
• Final copy is present, including legal, error, empty, and confirmation messages.
• English and Russian versions have been tested where localization is in scope.

Read the page without images. Then read only the headings and actions. Both passes should preserve the story and the route to conversion.

Components and states

• Every repeated control maps to an existing component or has a documented reason to become a new one.
• Component names in Figma match the handoff vocabulary and code mapping.
• Buttons include hover, focus, active, disabled, and loading states where relevant.
• Links remain identifiable without relying only on color.
• Forms include labels, hints, required indicators, validation, errors, success, and submission progress.
• Navigation includes open, closed, current, hover, and keyboard-focus behavior.
• Accordions, tabs, carousels, dialogs, and menus define keyboard behavior and focus movement.
• Missing images, long titles, short lists, and empty collections have a deliberate result.

Do not hide unresolved behavior behind a prototype transition. Add a short annotation where the implementation cannot be inferred from the component.

Responsive layout

• Containers, maximum widths, gutters, columns, and section spacing are named.
• The handoff explains where multi-column layouts wrap, stack, scroll, or change order.
• Text and controls are tested between desktop and mobile examples, not only at those endpoints.
• Images define aspect ratio, crop, focal point, and whether art direction changes by viewport.
• Decorative overflow is separated from content that must remain visible.
• Sticky elements do not cover focused controls or important content.
• The page works at a 320 CSS-pixel-wide viewport without losing information or requiring two-dimensional scrolling, except for content where two-dimensional layout is essential.
• Text can grow to 200 percent without clipping or removing functionality.

Figma auto layout can model padding, gaps, direction, wrapping, and size constraints. The browser remains the final test because content, fonts, and viewport behavior are live there.

Accessibility

• Normal text reaches a contrast ratio of at least 4.5:1; large-scale text reaches at least 3:1, subject to WCAG exceptions.
• Essential component boundaries and focus indicators have sufficient non-text contrast.
• Keyboard focus is visible and follows a meaningful order.
• Focus is not hidden behind sticky headers, cookie notices, or open panels.
• Pointer targets reach at least 24 by 24 CSS pixels or meet the spacing and exception rules in WCAG 2.2 Target Size Minimum.
• Color is not the only signal for status, selection, or error.
• Images have useful alt text or are marked decorative.
• Motion has a purpose and respects reduced-motion preferences.
• Video has the required captions, controls, and fallback content.

Accessibility annotations should name the expected behavior. A note that says accessible is not testable.

Assets and visual details

• Every image has a final source, usage approval, file format, dimensions, and compression expectation.
• SVG icons have consistent view boxes and are not exported with accidental backgrounds.
• Logos and illustrations include dark, light, and small-size variants where needed.
• Font families, weights, fallbacks, and licensing are confirmed.
• Gradients, shadows, borders, and radii use tokens or documented exceptions.
• The favicon, social image, page title, description, and sharing metadata are supplied.
• Decorative details do not become inaccessible images of essential text.

Implementation map

Give development or a coding agent a compact map:

• route and page file;
• shared components and import paths;
• token and theme source;
• content source or CMS fields;
• image assets and focal points;
• analytics events and form destinations;
• feature flags or launch constraints;
• tests, lint, type checks, build command, and screenshot viewports.

Mark decisions that are fixed and decisions where implementation may adapt. For example, the relative hierarchy and action order may be fixed while a decorative crop can shift to preserve composition.

Final visual review

Capture the implemented page at agreed viewport sizes and compare it with the approved design. Review the differences by cause:

• content mismatch;
• token or component mismatch;
• font rendering;
• responsive transformation;
• interaction state;
• deliberate browser adaptation.

Then test long copy, missing media, keyboard navigation, form errors, loading, and reduced motion. A screenshot of the ideal state cannot validate those conditions.

Create a Refframe board for the references used in the project and annotate what each one informed. Keep structure, typography, motion, and image treatment distinct. The handoff becomes stronger when the team can trace a decision without mistaking a reference for a specification.