A useful Figma-to-WordPress handoff gives the developer an approved design reference, a list of unique templates, responsive rules, interaction states, usable assets and an editing plan. The aim is to make the decisions visible before estimating or building. A desktop screenshot alone leaves too much to guess.

Use this checklist alongside your WordPress project brief. It covers the design-to-development stage; our website handover checklist covers ownership and responsibilities at release. This is a planning resource, not a completed client build or a Figma-to-live demonstration.

1. Identify the approved design and open decisions

Share the actual design file and the specific pages or frames included in the proposal. Confirm that the developer can inspect the needed layers and obtain the permitted assets. Keep work in progress separate from the approved reference, and name the person who can resolve design questions.

  • Record the file link, frame references and approval date or version.
  • List unfinished copy, missing mobile layouts and interactions still awaiting a decision.
  • Give every unresolved item an owner and a review point.
  • Agree how later design changes will be recorded and assessed against the scope.

Figma’s developer-handoff guidance explains file organisation, asset export settings and component documentation. Check the actual access available to your collaborators before relying on a particular inspection workflow.

2. Count templates and describe reusable components

Separate the number of website URLs from the number of layouts to build. Twelve service pages may use one template, while a homepage, service page, archive and article each need different structures. Identify meaningful variations rather than treating every frame as a separate build.

  • Template: purpose, example frame, expected page count and required content.
  • Component: where it appears, available variants and which parts may change.
  • Exception: any page that differs from the shared structure.
  • Content source: manual page fields, shared records, posts, products or an external system.

A design component and a WordPress content model are different decisions. A visually repeated card might be edited on one page or drawn from a shared service record. State the editor’s task before choosing the implementation.

3. Explain what happens between desktop and mobile

Provide the approved desktop and mobile examples, then describe how the layout adapts between them. Record stacking order, text wrapping, image crop, container limits and navigation behaviour. Test with representative content, including a longer title; do not depend on every editor preserving the designer’s sample text length.

Illustrative example: a three-card service row

Suppose the desktop design shows three service cards and the phone design shows one column. The handoff still needs answers: does a middle width use two columns or one? Does reading order stay the same? Can a title wrap to three lines? Does the image keep its shape? What should happen if only two services are supplied?

Write an agreed rule for each question, or mark it undecided. These are example decisions, not universal breakpoint values or results from a completed project. The staging review should compare the approved frames and widths between them.

4. Specify the states a static frame cannot show

For every menu, form, tab or other interactive element, record the trigger, expected result and recovery when something fails. A prototype can explain a flow, but the written brief should also cover the states that are absent from it.

  • Navigation: open and closed menus, current-page indication, keyboard focus and dismissal.
  • Forms: labels, required fields, errors, sending, success and failure messages, plus the intended recipient or system.
  • Content: empty optional fields, missing images, long text and unusually large item counts.
  • Motion: what moves, when it starts and the intended reduced-motion behaviour where animation is included.

Keep the visitor’s success message separate from proof that an enquiry reached its destination. Agree a labelled test and receipt check as part of the implementation review.

5. Map assets and everyday WordPress editing

Identify who supplies the final fonts, images, icons and text, along with permission to use them. Include the intended image crop and distinguish meaningful images from decoration. Supply files through the agreed project location; passwords, licence keys and confidential customer data do not belong in a design checklist.

Describe practical editing tasks: change a service paragraph, replace a card image, add a service, or reorder a section. For each task, identify the content owner, required fields and whether the change affects one page or several. Our Elementor versus ACF guide helps frame that choice around the team’s work.

Agree the WordPress approach and any paid-plugin or font dependencies before treating them as included. A Figma frame does not by itself specify a CMS, licence entitlement or integration.

6. Agree the review record before the build

Use the same acceptance record for design questions and staging checks. Include the reference frame, page or component, expected behaviour, actual result, evidence and approver. Separate a mismatch against the approved scope from a new design request.

  • Compare layout, typography, spacing and image treatment with the approved reference.
  • Check narrow, middle and wide layouts with representative content.
  • Run the agreed editing tasks and inspect the saved result.
  • Check keyboard navigation and the specified form states.
  • Record unresolved items and who must resolve them before launch.

Leave untested items marked not tested. A design approval is not evidence that the WordPress page, enquiry delivery or integration has passed its checks.

Copy the design-handoff worksheet

Download the Figma-to-WordPress handoff worksheet (plain text). It is available without an email signup. Save a copy and repeat the template, component and review records as needed.

  • Project, approved file, frame references and design approver.
  • Templates, page counts, reusable components and exceptions.
  • Responsive rules, representative content and unresolved states.
  • Asset source, usage permission and content owner.
  • WordPress editing tasks, shared content and implementation dependencies.
  • Acceptance checks, evidence, actual result and approval.
  • Open decisions, owner, next action and review point.

For each item, use confirmed, pending or not applicable. For a test result, use not tested until it has been checked. The worksheet is a scoping aid, not a quote, contract or proof of a completed build.

What to send for a Figma-to-WordPress quote

Send the viewable design link, unique template list, mobile status, required interactions and integrations, and the tasks your WordPress editor needs to perform. Flag missing inputs so they can be reviewed before price and timing are agreed.

Our Figma-to-WordPress development service explains the implementation scope. For agency delivery, include your review and client-communication arrangement. Share your design handoff and project requirements to discuss a scoped build.