Figma to WordPress: a handoff checklist for a faster, cheaper build

Most delays in a Figma to WordPress project don’t come from the build. They come from questions: what happens on mobile, where this button goes, which font weight that heading uses. Every question costs a day of back and forth.

Here is the checklist I run through when a Figma file arrives. Work through it before you hand your design over, and you will get a more accurate quote and a faster build.

1. Share the file with view access

Share a link with “can view” access to the whole file, not screenshots or a PDF export. A developer needs to inspect spacing, colours and font sizes directly. Dev Mode is helpful but not required.

2. Mark which pages are final

Files often hold old versions, explorations and the final design side by side. Put the approved pages on one Figma page and name it clearly, for example “Final: ready for build”.

3. Include mobile, or say you don’t have it

If you only designed desktop, that’s fine, but say so. The developer then plans the tablet and mobile layouts rather than improvising them during the build. Ideally, design at least the homepage and one inner page at phone width.

4. Use styles for colours and text

Colour and text styles (or variables) tell the developer which values are part of your design system and which are one-offs. A design with six consistent text styles builds faster and stays more consistent than one with 30 slightly different sizes.

5. Build repeated parts as components

Buttons, cards, testimonials and section headers that repeat across pages should be components. Each component becomes one reusable, editable block in WordPress instead of many copies to maintain.

6. Show every state

• Hover and focus states for buttons and links
• The open mobile menu
• Form errors and the “message sent” state
• Empty states, such as a blog with no posts yet

Anything not shown has to be guessed, and guesses get revised.

7. Use real content, or close to it

Lorem ipsum hides problems. A real headline might be twice as long as the placeholder and break the layout. Use real copy for at least the homepage, and realistic lengths everywhere else.

8. Check font licences

Google Fonts are free for websites. Paid fonts need a web licence, and some desktop licences don’t cover websites. Sort this out before the build so the site doesn’t launch with a substitute font.

9. Export images at the right size

Hand over original, high-resolution photos rather than cropped screenshots. The developer will create optimised, responsive versions in modern formats like WebP, which keeps the site fast.

10. Decide who edits what after launch

Tell the developer which parts your team will update: blog posts, case studies, team members, prices. That decides how the site is built. Content you edit often should have simple, labelled fields so nobody can break the layout by accident.

The short version

A clean Figma file with final pages, mobile layouts, styles, components and real content can be built faster and more accurately, and it costs less. If you’re not sure your file is ready, send me the link and I’ll tell you what’s missing before you commit to anything. You can also read more about my Figma to WordPress service.