My Figma-to-WordPress Theme Workflow

When I receive an approved Figma file for a WordPress project, I do not start by turning the first frame into markup.

A Figma file describes an intended experience. A WordPress site also needs templates, content fields, editor boundaries, responsive rules, and a plan for keeping the result maintainable.

This is the process I use to move from a Figma handoff to a working WordPress implementation. It is also how I decide whether a custom theme is the right answer in the first place. Not every Figma design needs one.

1. I review the handoff before writing code

I start by treating the design file as a handoff to investigate, not as a collection of screenshots to copy.

I look through the pages, shared styles, components, assets, and prototype interactions. I make a list of questions while the design context is still fresh:

• Which screens are approved, and which are explorations?
• Which pages are unique, and which follow a shared template?
• Which component variants and states are represented?
• Are mobile and desktop frames the only responsive references?
• Which copy and images are final, and which are placeholders?
• Are hover, focus, active, error, loading, or empty states defined?
• Which interactions are essential, and which are visual enhancements?
• Are the image, icon, font, and animation assets available for implementation?

This step often reveals that a frame is missing an important decision. A button may have a desktop appearance but no keyboard focus state. A card may look reusable but have no answer for a much longer title. A mobile layout may exist without showing what happens at widths between mobile and desktop.

I would rather resolve those questions before building a component around an assumption. The goal is not to make the Figma file more complicated. The goal is to understand what the finished site is expected to do.

2. I inventory layouts, components, and states

Next, I turn the handoff into a small implementation inventory. I usually group what I find into four layers:

Layer	What I record
Pages and templates	URLs, page types, and layouts that can share a template
Components	Navigation, hero, cards, forms, sections, and other repeated patterns
States	Hover, focus, open, closed, empty, error, loading, and disabled states
Content	Text, images, links, lists, relationships, and editor-managed values

I also separate a reusable component from a one-off visual grouping. Two sections may both contain a heading and an image, but that does not mean they need the same content model or template. Reuse should make the implementation clearer, not force unrelated content into one overly flexible component.

For each component, I want to know:

• What problem does it solve?
• Which values change from page to page?
• Which layout rules stay consistent?
• What happens when content is missing or unusually long?
• Which states need to be implemented even if they are not visible in the main frame?

This inventory gives me something more useful than a list of screenshots. It gives me a map from the visual language to the pieces I will need to build and test.

3. I define responsive behavior beyond fixed frames

Figma frames are useful reference points, but a real website is not viewed only at the exact widths supplied in a design file.

I make responsive decisions for the space between those frames. For each major component, I consider:

• container width and side gutters
• grid columns and the point at which they reflow
• type sizes, line lengths, and wrapping
• image aspect ratios and cropping
• navigation behavior on smaller screens
• long labels, long headings, and extra cards
• overflow, scrolling, and touch target sizes

A simple decision table helps when a behavior is not obvious:

Component	Wide layout	Narrow layout	Decision to confirm
Navigation	Full link list	Menu control	Does the menu open, close, and receive focus correctly?
Card grid	Multiple columns	Stacked or fewer columns	Do card heights and image crops remain useful?
Media and text	Side by side	Reordered stack	Which content should come first on small screens?

I do not want to encode a desktop screenshot and hope CSS will make it responsive later. I want the layout rules to be explicit before I get too far into the templates.

4. I decide whether a custom theme is justified

A Figma design alone is not a reason to build a custom theme. I first compare the design with the content and editing needs of the project.

An existing theme or the WordPress block editor may be the better choice when:

• the design is close to patterns the theme already supports
• the site needs mostly standard pages and content blocks
• the team benefits from composing pages directly in the editor
• reducing custom code and maintenance is the main constraint

A custom theme becomes more useful when the design has a distinct layout system, the templates need to map closely to structured content, or the editing experience needs deliberately limited choices. It can also be a sensible fit when bespoke interactions are part of the approved experience.

There are useful middle paths too. I can extend an existing theme, create a small set of custom block patterns, or keep a standard theme while customising only the templates that need it.

My decision usually comes down to four questions:

1. How far is the existing theme or block system from the intended interface?
2. How much control do editors need over page structure?
3. Which parts of the design are recurring systems rather than one-off pages?
4. What is the simplest foundation that can support the content and maintenance plan?

Custom should mean purposeful, not automatically better. When I do recommend it, I want to be able to explain which project constraint made it worthwhile. That distinction is also important when comparing options for custom WordPress development.

5. I choose a foundation for the custom theme

When a project does need a custom theme, my usual setup is UnderscoreTW (_tw), a WordPress starter theme integrated with Tailwind CSS, alongside ACF Pro for structured content.

I use that combination as a starting point, not as a rule. The value is in having a clear place to establish the theme structure and translate the design system into maintainable styles. Tailwind utilities can make spacing, typography, color, and responsive rules visible close to the component that uses them.

Before building every section, I establish the shared decisions:

• typography and heading hierarchy
• color roles and contrast expectations
• spacing and container rules
• breakpoints and responsive behavior
• borders, radii, and other repeated visual tokens
• asset handling and image proportions
• motion defaults and reduced-motion behavior

There are tradeoffs. A Tailwind-based foundation adds a build setup and requires discipline around shared patterns. A different starter theme or a smaller amount of custom CSS may be a better fit for a project with different constraints. I choose tools to support the project rather than treating a particular stack as part of the deliverable.

6. I model content before I finish the templates

A page can look simple in Figma and still need a thoughtful content model in WordPress. Before I lock in the template structure, I identify what editors should be able to change and what the component should control.

For a custom-theme project, I usually use ACF Pro to create structured fields and field groups. That might mean modelling a hero’s heading, text, links, and image separately from its layout rules, or giving a repeated card a defined title, summary, link, and media field.

I do not expose every visual option as an editor field. Too many controls can make the editing experience harder to understand and make the design inconsistent. I prefer to define a component’s shape in code, then expose the content that genuinely needs to change.

For each field, I ask:

• Who owns this value: an editor, a template, or a global setting?
• Is it required, optional, or conditionally shown?
• What is the fallback if it is empty?
• Can the content become much longer than the supplied example?
• Does the field need a validation rule or an editing instruction?
• Would a repeated field or relationship be clearer than duplicated text fields?

This boundary is important. Editors should be able to manage content without needing to understand the CSS behind a component. At the same time, the template should not pretend that every possible layout variation is supported if it has not been designed or tested.

7. I map WordPress templates to the inventory

Once the content model is clear, I map WordPress templates and components to the inventory from the handoff.

I usually work in this order:

1. Build the shared shell: header, navigation, footer, containers, and base typography.
2. Implement the page and post templates that define the site’s main content types.
3. Build repeated sections as focused components with clear inputs.
4. Connect those components to structured WordPress fields.
5. Add the less common states and content fallbacks.
6. Replace placeholder content with realistic content before calling a section finished.

I keep the template responsible for composition and the component responsible for its own markup and states. That makes it easier to inspect a mismatch: is the page putting sections in the wrong order, or is the component’s internal layout wrong?

I also use semantic HTML as part of the implementation rather than treating it as a final polish step. A visual heading should have an appropriate heading level. A link should behave like a link. A menu or dialog should have a real interaction model, not just a visual open state.

Integrx is a public implementation reference. I implemented approved Figma designs as a custom WordPress site using ACF, GSAP, and LottieFiles; the visual design came from supplied Figma files, not from me.

The screenshot is useful as a reference for the implementation side of this process. It should not be read as a claim that every project uses the same theme foundation or content setup.

8. I treat animation as part of the handoff

A prototype can show that something moves without answering how that motion should work in a real page. I clarify animation separately from static layout.

For each motion idea, I ask:

• What triggers it: page load, scroll, hover, focus, or an explicit action?
• Should it happen once, repeat, or respond every time?
• What happens if the element is already visible or the user skips past it?
• Is the motion needed to understand the interface, or is it an enhancement?
• Which asset is required, and who supplies or maintains it?
• What is the reduced-motion alternative?

I do not animate every section just because the prototype contains movement. Motion adds implementation and testing decisions, so I keep it tied to a clear purpose. A static or simplified state is often the right fallback.

When the approved implementation calls for it, I can use tools such as GSAP or LottieFiles. They are implementation choices for a particular interaction, not requirements for converting Figma to WordPress.

9. I run quality checks with real content

A page that matches one Figma frame can still fail as a website. My QA checklist includes the following.

Content checks

• Use realistic headings, paragraphs, links, lists, and image crops.
• Test long titles, missing optional fields, repeated items, and empty states.
• Confirm that editor instructions match what the template actually supports.
• Check that images have useful alternative text when they convey meaning.

Responsive and browser checks

• Test widths between the supplied desktop and mobile frames.
• Check navigation, grids, forms, tables, media, and overflow at narrow widths.
• Test the supported browsers and both pointer and touch interactions.
• Check landscape or unusually tall and short viewports where the layout may change.

Keyboard and accessibility checks

• Move through the page with a keyboard and verify a visible focus state.
• Confirm heading order, landmarks, labels, link purpose, and error messages.
• Test menus, dialogs, carousels, and other controls without a mouse.
• Check contrast and ensure that color or motion is not the only way to understand a state.

Performance-conscious asset checks

• Use appropriately sized image files and suitable formats.
• Avoid loading animation assets when the component does not need them.
• Reserve space for media so loading does not unexpectedly move the layout.
• Inspect the page’s asset requests rather than assuming a decorative asset is free.

Reduced-motion checks

• Test the site with the operating system’s reduced-motion preference enabled.
• Remove or simplify nonessential transitions and scroll effects.
• Make sure essential content and controls remain usable without animation.

I find these checks much more valuable than comparing only the widest page to a screenshot. They test the conditions the WordPress site will actually encounter after launch.

10. I prepare the launch and handoff

Before launch, I walk through the site as both a visitor and an editor. I check the final content, links, forms, media, metadata, and the states that were easy to overlook during implementation.

I also document the decisions that someone else will need later:

• which fields control each section
• how to add or replace images and animation assets
• which components are reusable and which are template-specific
• what the responsive and reduced-motion behavior is
• which design choices are intentionally fixed in code
• what still needs attention after handoff

The handoff should not require an editor to reverse-engineer the Figma file. I explain the content model in WordPress terms and point out the boundaries of each field group. If a section has a fixed structure, I say so. If a repeated list can grow, I show how to test it with more items.

After deployment, I repeat the most important visitor checks on the live environment. A last-minute content change, font issue, asset path, or hosting difference can affect the result even when the staging version was correct.

My decision guide in brief

When I convert a Figma design to WordPress, I try to answer these questions in order:

1. What does the handoff specify, and what still needs a decision?
2. Which layouts, components, states, and content types are actually recurring?
3. How should each piece behave between the supplied responsive frames?
4. Would an existing theme or block editor meet the content and maintenance needs?
5. If a custom theme is justified, which foundation keeps the implementation understandable?
6. What should editors control, and what should the template protect?
7. Which motion is useful, and how does it behave with reduced motion enabled?
8. Has the implementation been tested with real content, real input methods, and realistic assets?

The best result is not a pixel copy of a Figma frame. It is a WordPress site that preserves the design intent while giving content, templates, responsive behavior, accessibility, and maintenance a clear place in the implementation.

If you are working from a Figma file and are unsure whether an existing theme, block editor, or custom theme is the right path, you can contact me with the design and the constraints you already know. I can start with the decision, not assume the answer.