A developer opens your Figma file on Monday. Desktop is there, mobile is there, tablet is maybe there. Every button has one state. The header has no mobile menu. By Tuesday afternoon there’s a pile of questions in Slack and the build hasn’t really started.
That’s how most WordPress builds stall, and it’s rarely anyone’s fault. The file is finished the way a design review needs it finished, not the way a browser needs it.
Here’s the test we’d use: a file is ready when a developer can build every screen and every state without asking a design question. The checks below are the ones that go missing most often. If you want the build side of this, we wrote up our Figma to WordPress workflow separately. This one is for whoever owns the file.
What “ready” means, and what the Ready for dev badge doesn’t tell you
Figma lets you mark sections, frames and components as Ready for dev, and it’s worth doing. Developers can filter the file down to what’s marked, and Figma can flag a design as changed if someone edits it afterwards. What you get depends on your plan and the seat type your developer has, so check what your team actually has before you build a process around it.
The badge only tells people the designer thinks it’s done. It doesn’t check anything. Treat it as the last step, after the rest of this list.
Breakpoints: find out which widths the build will use
Most files show a desktop frame, a mobile frame, and sometimes a tablet frame at 768. Those widths usually come from habit, not from the builder.
Builders have their own. Beaver Builder’s docs describe a desktop-first setup. By default, anything wider than 1200px counts as extra large, medium devices top out at 992px, and small devices are 768px and below. Read that with a 768px tablet frame in mind. Out of the box, your tablet design lands in the small-device bucket, which is where phone layouts normally live. The values can be changed, and developers often change them, but somebody has to know it needs doing.
Elementor’s defaults are different again: 1024px for tablet and 767px for mobile. Breakdance gives you a breakpoint dropdown plus custom breakpoints, so the widths on a project are whatever your developer set up. Its docs also point out that not every setting can be changed per breakpoint, which matters if your tablet design asks for something unusual. For a wider look at how the builders differ, there’s our roundup of the main WordPress builders.
So before you draw tablet, ask. Then design at those widths, or just inside them.
And show what happens between breakpoints. The stretch from roughly 800 to 1100px is where layouts tend to fall apart, because nobody designed it. You don’t need another frame. A note is enough: cards go from three columns to two here, nav collapses there, hero image stays on the right until this width. Same at the top end. If content should stop growing at 1200px while the background runs full width, write that down. It saves guessing on big monitors.
Figma variables with modes can model breakpoints, but how many modes you get per collection depends on your plan, so don’t assume it’ll cover every setup.
States: the screens nobody draws
Figma shows the default version of everything. A browser doesn’t. You can’t tab through a canvas, so focus states go missing first, then hover, then everything that happens after a click.
Scan the file for these:
- Buttons and links: hover and focus, plus disabled if a form uses one
- Navigation: mobile menu open, any dropdown or mega menu open, and the header after scroll if it’s sticky or shrinks
- Forms: field focus, validation errors, the success message, and the thank-you page
- Accordions, tabs and sliders: anything other than the first item open
- Cards with no image, or a title that runs to three lines
If you don’t draw it, the developer picks something. Sometimes that’s fine. Sometimes it’s a hover colour the client first sees on launch day, and now it’s a revision round. Adding a variant to the component is less work than that conversation.
Components that are really components
Open the Assets panel, then click around the pages. How many of those cards are instances, and how many are copies somebody detached a few weeks ago and nudged?
Developers rebuild a repeating pattern once and reuse it, as a global block, a saved row or a class, depending on the builder. That only works if the pattern is one pattern. When three “identical” cards differ by a few pixels of padding, the developer has to guess which one is right, or ask you. Usually they ask.
Keep states on the component as variants, avoid detaching unless you have to, and name things for what they are. “Card / Service” helps. “Frame 2041” doesn’t.
Spacing, type and colour, written down
You don’t need a full token system. You need a short list a developer can copy: the spacing steps you actually use, the size of each heading and body style at each breakpoint, and your colours with names.
Two builder-specific notes. Breakdance’s global typography works from a base size and a ratio, with settings that can vary by breakpoint. If your type scale isn’t a clean ratio, say so, and the developer will set the headings individually. Breakdance also starts with five default global colours: brand, text, headings, links and background. Tell the developer which of your colours is the brand colour and which is an accent you use once. That decision drives how the button styles get built.
For fonts, list the families and weights that are really in use, and check they’re licensed for web use. Better to find that out now than in launch week.
The pages that aren’t in the mockup
This one is specific to WordPress, and it catches people out. A site isn’t only the pages in the sitemap. It’s also the templates behind them: the blog index and category archives, the single post layout, search results and the no-results version, the 404, header and footer variants, a cookie notice, any popups. For a WooCommerce store, add product, cart, checkout and account pages.
In Breakdance these are built as templates, headers, footers and popups, each with its own rules for where it shows up. In Beaver Builder it’s usually Themer doing that job. Either way it’s real build work, and if it’s not in the file it turns into a scope conversation halfway through. Ask on day one: is the blog designed, what does the 404 look like?
For anything that repeats from content, like team members, case studies or events, list the fields each item has. The developer needs that to set up the post type and fields before the template makes any sense.
Real content, real images
Placeholder copy flatters a layout. A heading that’s one tidy line in Figma is two lines in the client’s actual text, and suddenly the card heights don’t match. Use real copy where you have it. Where you don’t, give a realistically long version and a realistically short one for each text block.
Images need a note too. Do they crop to fill the frame or sit inside it? What ratio do they keep on mobile? Which icons are SVG exports? And if someone has to write alt text, who?
Mark it ready, and leave a trail
Put a plain page at the front of the file called “Dev notes”. Breakpoint widths, max content width, interaction notes, anything that’ll need a plugin or custom code (a filterable grid, a multi-step form, an interactive pricing table), and where the final copy lives. One page.
Then mark one section per page or template as Ready for dev. If something changes after that, say what and why. Figma’s changed status helps if your team uses it. A line in the project channel does the same job if they don’t.
Honestly, a short walkthrough call before dev starts finds more than any document does. Designer and developer scroll the file together, and you hear the questions before they turn into messages.
The quick version
- Breakpoint widths confirmed with the developer, in-between behaviour noted
- Max content width stated
- Hover, focus, open, error and success states drawn
- Components are real components, with sensible names
- Spacing, type and colours listed
- Fonts licensed, weights listed
- Blog, single post, search, 404, header and footer variants and popups designed, or clearly marked out of scope
- Real or realistic copy, plus image rules
- Dev notes page written, sections marked Ready for dev
In the agency projects we support, a file that clears most of this tends to start the build as a build rather than a Q&A thread. If your designers are producing files faster than your team can build them, a white-label WordPress development team is one way to close the gap, and we’ve explained how that model works for agencies.
FAQ
How many breakpoints should a Figma file show for a WordPress build?
It depends on the builder and how the developer sets it up. Beaver Builder defaults to extra large, medium and small, Elementor to desktop, tablet and mobile, and Breakdance lets you add custom ones. Ask the developer first, design to those widths, and note what happens in between.
Do designers really need to draw hover and focus states?
For buttons, links, nav items and form fields, yes. If they’re missing, the developer chooses them. Focus styles especially get forgotten, because you can’t tab through a Figma canvas.
Does marking something Ready for dev mean it’s been checked?
No. It’s a status label on sections, frames and components. It tells developers where to look, but it doesn’t verify breakpoints, states or components. Availability depends on your Figma plan and seat types.
Should the blog, 404 and search results be designed too?
If the site will have them, yes, or the file should say they’re out of scope. In WordPress they’re templates that need building, so leaving them out usually means a scope question mid-project.