What an Agency Should Include in a Figma-to-WordPress Handoff

Why the handoff decides the build

An approved design shows how a website should look in the states someone chose to design. A developer has to build every other state too. Each missing state becomes a decision: either the developer makes it, or the question waits until someone answers it. Both cost time, and the first often produces work that has to be changed after client review.

A good handoff doesn’t need to be long. It needs to answer the questions a developer will otherwise ask during the build.

Responsive states

Desktop layouts usually get the most attention. Make sure the handoff covers:

• Mobile layouts for every unique template, not only the homepage.
• Tablet behaviour, even if it’s a written rule rather than a full design, such as “two columns become one below this width”.
• Navigation at each size, including how the mobile menu opens, closes and handles sub-items.
• Images: how they crop or reflow on narrow screens, and which parts must stay visible.

Components and variants

Designs often contain several versions of the same element: cards with slightly different spacing, buttons in different sizes, headings that almost match. Some differences are intentional, many aren’t. Tell the developer which is which.

A short component list helps: each card, button, form element and section type, with its variants and where each is used. If your design file uses components and variables consistently, the developer can inspect them directly. Figma’s Dev Mode, for example, shows the styles and variables applied to a layer and lets designers mark sections as ready for development.

Interactions

Static frames can’t show behaviour. Describe it in a sentence or two per item:

• Hover, focus and active states for links, buttons and cards. Focus states matter for keyboard users and are often forgotten.
• Accordions, tabs, sliders and modals: what opens, what closes, and what happens on mobile.
• Animations: which elements move, roughly how, and whether they’re essential or decorative.

Assets

• Final images at a suitable resolution, with the right to use them on the website.
• Icons as SVG where possible.
• Fonts, including confirmation that the licence covers web use.
• Logo files for light and dark backgrounds, plus a favicon.

Content

Designs are often made with ideal-length placeholder text. Real content is longer, shorter or missing. Say whether final copy exists, which pages still need it, and how long headings and descriptions could realistically be. If the client will add content later, note which areas they need to edit.

Functionality

List what the website needs to do, not only how it looks:

• Forms: fields, required fields, validation messages, success message, where submissions go, and any CRM or email-marketing connection.
• Search, filtering, sorting or pagination.
• Integrations such as booking tools, maps, analytics or chat.
• Anything content editors need to manage themselves, such as team members, locations or case studies.

Acceptance criteria

Acceptance criteria describe what “done” means in terms both teams can check. They don’t need to be formal. Examples:

• “The contact form shows an error beneath each invalid field and a success message after sending.”
• “Service cards stack in one column on mobile, with the image above the heading.”
• “The client can add a new team member without help.”

Criteria keep review feedback focused. When a comment falls outside them, it’s easier to recognise as a new request rather than a defect.

Checklist

• Mobile layouts for every unique template
• Tablet behaviour described or designed
• Component list with intentional variants
• Hover, focus and active states
• Interaction notes for menus, accordions and animation
• Final images, icons, fonts and logos with usage rights
• Content status per page
• Form fields, messages and destinations
• Integrations and editable content types
• Acceptance criteria for key behaviour

Sources

• Figma Learn: Guide to Dev Mode (opens in a new tab)