Translate Figma to WordPress by mapping the design into editable content, shared templates and global styles before building the page. Preserve the intended behaviour when content changes, rather than copying a single screenshot. The handover should explain what an editor can change, where that change is saved and which pages it affects.
Begin with a representative page containing a heading, introduction, repeated content and a clear action. Ask the designer and the future editor to identify which parts should change regularly. Then ask the developer to name the WordPress mechanism that will own each part. Agreement here makes later visual review much more useful.
The approach below uses Figma auto-layout documentation and WordPress block-theme documentation. Its original editability contract gives each design decision an owner and a test. Use it to compare an implementation proposal or review a separate staging copy before changing the live website.
What should you extract from the Figma design?
Figma auto layout adjusts when content changes or objects are added, removed or resized. Read the auto-layout guide as a description of relationships in the source design. During handover, ask which relationships should survive in the website: a heading that grows, a group that stacks or a repeated item that keeps its spacing.
Figma defines padding as the space between a parent auto-layout frame edge and its objects. Figma defines gap as the distance between or distribution of objects in an auto-layout frame. Capture those as separate design decisions. Otherwise, a developer can reproduce the visible distance with the wrong mechanism and make the next content edit difficult to control.
Hug contents applies only to auto-layout frames in Figma. Fill container applies only to child objects of auto-layout frames in Figma. Record the intended relationship alongside the feature name. For example, “the button follows its label” tells the implementer more about the desired result than a width copied from one frame.
Inspect short and long text in the design before sign-off. Ask what should happen when a service heading needs another line or a repeated item is removed. If there is no agreed answer, add it to the handover. The browser implementation still needs its own layout choices and testing; the source frame describes intent.
Where should the editable WordPress structure live?
WordPress block theme templates consist of block markup. WordPress recommends the theme’s /templates folder for block templates. These points in the template documentation help distinguish a reusable site structure from an image of that structure. Ask the developer to show the actual template and the content it displays.
WordPress custom templates can be assigned to individual posts, pages or custom post type entries. Decide whether your designed service page needs a shared template or a special one. A special layout may be appropriate, but its purpose should be clear. Repeatedly creating unique templates can make routine design changes harder to review.
A custom template needs a Post Content block to display the post or page content. Include that relationship in the demonstration: edit the page’s content and inspect where it appears. This catches a common handover ambiguity in which the editor expects to change the page but the visible wording has been embedded in the template instead.
WordPress theme.json can configure colours and default typography settings. Use the global settings and styles documentation to discuss which design choices should be shared. A recurring heading style or colour choice deserves an explicit home, so an editor does not have to recreate the design independently on every new page.
Original editability contract for one service page
This hypothetical contract concerns a service page with a headline, introduction, benefits list and contact action. The page and content are fictional. Complete the matrix with the designer, developer and intended editor, using a separate test copy of the website.
| Design element | Intended owner | Proposed WordPress home | Content-change test |
|---|---|---|---|
| Service heading and introduction | Page editor | Page content shown by the template | Replace heading with a longer accurate alternative |
| Shared page frame | Theme maintainer | Block template | Apply one agreed structural change and inspect affected pages |
| Recurring text and colour choices | Design system owner | Appropriate theme.json settings and styles | Compare the same element on another page |
| Repeated benefits | Page editor within agreed limits | Editable blocks in the page content | Add one item, remove another and inspect spacing |
| Site-wide framing elements | Theme maintainer | Explicitly identified shared structure | Check whether an update reaches the intended pages |
| Contact label and destination | Named content owner | Agreed editable block or shared element | Change the label and verify its destination separately |
Treat the proposed home column as a design decision to confirm, not an automatic conversion recipe. The developer should explain the mechanism used in the actual build. If a requirement depends on a plugin, custom block or different theme architecture, record that dependency and its implications for editing and maintenance.
For each row, add an acceptance sentence in ordinary language. For the heading, use “the editor can change the wording without editing a template”. For the benefits, use “an additional item retains the intended relationship to the heading and action”. Those sentences give visual and content review a common target.
How do you test the result beyond a screenshot?
Run a controlled content-mutation review. First record the baseline page and the template assigned to it. Replace the heading with a longer version that still expresses a plausible service. Inspect the page at the agreed review widths and note wrapping, overlap and the relationship between the heading and the next element.
Next, add a benefits item with a longer label and remove a different item. Look for uneven spacing, unwanted empty areas and an action that becomes hard to find. Ask the editor to perform these changes themselves. A successful developer edit does not establish that the intended editor understands the controls they will receive.
Then test the shared style decision. Compare the corresponding heading or text element on a second page using the same system. Ask the developer to explain which setting owns the result and how a future change would be made. Record exceptions deliberately, rather than allowing unexplained one-off values to accumulate.
Review the action as both content and behaviour. Confirm its wording, destination and usable state in the test copy. Keep the visual question separate from any form processing or external integration requirement. A Figma interaction or a correctly positioned button does not itself answer what happens after a visitor activates it.
Why can a correct theme file differ from the edited site?
Templates saved through the WordPress editor are stored in the database and override theme templates. This documented precedence matters during handover. If a developer changes a file and the page looks unchanged, ask whether a saved editor version is taking precedence before repeating the same edit elsewhere.
Add a template-origin line to the contract: identify whether the reviewed version comes from a theme file, a saved editor template or another documented mechanism. Ask how the agreed version will be retained and reproduced. Keep that explanation with the delivered source and the content-change results so the next maintainer can follow the same ownership model.
Agree who may change shared structure after launch. A content editor may need freedom over wording while a designated maintainer owns layout changes that affect many pages. The right division depends on your team. Make it explicit in the handover rather than relying on the editor to infer it from whichever controls happen to be visible.
What should the final handover contain?
Retain the approved source design, the completed contract, the template and style locations, and the results of the content-mutation review. Record the product versions and any unresolved differences between design intent and the test copy. This is a more useful acceptance record than a gallery of matching screenshots alone.
For the implementation context, read WordPress services. Keep release preparation in the separate migration and rollback guide and backup restoration guide. To discuss the handoff, get started with the Figma link, editability contract and the content changes your team must be able to make.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.