1. Use a grid system
Web development is governed by rules, usually the CSS Box Model. When a design does not follow a consistent spacing system, the developer has to interpret every distance independently, which multiplies the risk of micro-inconsistencies.
An 8pt grid, a clear column system and documented spacing rules eliminate ambiguity and speed up both implementation and QA.
- Stick to a consistent spacing system, such as an 8pt grid.
- Define container widths clearly, for example 1280px or 1440px.
- Avoid mixing arbitrary pixel values: 20px next to 22px creates uncertainty.
2. Assets: exportable vs CSS
Help me keep the site fast. Handoff includes the weight of the final page, not just the visual shapes. Every choice around assets affects performance, SEO and long-term maintainability.
SVGs for icons and logos, optimized photos and CSS gradients instead of heavy raster images. These details determine whether the agency's client loves the site or feels frustrated by it.
- Icons and logos should be SVGs, not PNGs.
- Prepare photos with standard aspect ratios such as 16:9 or 4:3.
- Shadows and gradients should remain editable styles when possible instead of flattened images.
- Trim duplicate assets and always supply the native size required by the layout.
3. Responsive states
Sending only a desktop view is like sending half a blueprint. Often 60-70% of traffic comes from mobile, and without clear guidance the developer has to guess on column stacking, menu behavior, padding and font sizes.
A full set of device-specific mockups is not necessary, but desktop, mobile and any truly different tablet behavior should be defined. Specifying how sections collapse avoids two or three unnecessary revision rounds.
- Desktop 1440px as the main view.
- Mobile 375px or 390px for menu behavior and stacking.
- Tablet only when the layout changes materially.
- If a section has four columns on desktop and two on mobile, make that explicit.
4. Hover and interaction states
Define what happens to buttons and inputs when state changes occur. Hover, focus, active, disabled: every undefined state gets implemented based on developer interpretation, which rarely matches the original intent.
A UI kit page in Figma with buttons, form inputs and typography works as a reliable source of truth. A well-built kit eliminates dozens of questions and ensures visual consistency across every page.
- Include hover, focus and active states for all interactive components.
- Define the style of inline text links, not only buttons.
- Provide a disabled state for form fields and submit buttons.
5. From design file to a working WordPress site
A Figma, PSD or XD file is a visual representation, not a working site — it doesn't say how the layout behaves at 768px, which field feeds a given heading, or whether a three-column grid is a custom post type loop or three repeatable fields. Turning that visual intent into technical structure is what the build phase is for.
The process runs through defined phases, each with a concrete output: design and component analysis, technical planning (template hierarchy, custom post types, ACF fields, responsive strategy), semantic HTML5 markup, CSS and responsive implementation, WordPress integration (functions.php, The Loop, taxonomies), then ACF or custom metaboxes so every content area is editable without touching code.
- How many page templates actually exist — home, landing, blog, inner page each need a separate template file.
- What content is editable and what stays static — this shapes the ACF field architecture.
- Whether images have fixed aspect ratios or need a crop strategy.
- Whether typography uses clamp() or fixed steps at each breakpoint, and how grid components collapse on mobile.
6. What gets checked before handoff
Before passing the project there is a three-level check. Visual: does the site match the design — fonts, colors, spacing — in a direct side-by-side comparison. Functional: does everything editable actually work — update ACF fields, publish a post, upload an image, submit a form, and confirm it appears correctly on the frontend. Technical: does the site hold up on real devices, not just Chrome on a laptop — iOS Safari, Firefox, Edge, menu behavior on mobile, forms on small screens.
An agency-grade build also has to survive the handoff itself: commented and structured code so another developer can continue the project, theme documentation, a CMS configured for non-technical use, and no hidden dependency on non-standard plugins or libraries.
7. Supported design formats
I work with the formats most common in agency workflows.
- Figma — the most popular, easy to inspect and export assets from.
- PSD (Photoshop) — classic format, I extract layers and optimise.
- Adobe XD — similar workflow to Figma, fully supported.
- Sketch — Mac-native tool, supported without limitations.
8. What you receive on delivery
Every project includes a deliverable set designed for agencies that need to manage the result independently.
- Complete custom WordPress theme — production-ready PHP, CSS and JavaScript.
- Theme documentation — technical guide for developers.
- CMS setup — instructions for managing content with ACF.
- 30-day post-launch support — bug fixes and minor adjustments.
- Git repository — full version history and code access.
Frequently asked questions
How many revision rounds are typical on a design-to-build project?
It depends on file quality and the clarity of the initial brief. With a well-prepared file and careful upfront analysis, one or two feedback rounds are usually enough. The most common issues appear where the design does not specify responsive behavior or edge cases with real content.
Does the designer need to be available during development?
Not constantly. It makes sense to involve the designer on decisions that could not be resolved earlier: unspecified responsive behavior, content variants the design did not account for, components that behave differently with real data versus placeholder content.
How long does a design-to-WordPress conversion take?
It depends on complexity: simple sites (5–10 pages) take 3–4 weeks; medium sites (10–15 pages) 4–5 weeks; complex projects with custom features 6–8 weeks.
Do you work with designs that are not yet responsive?
Yes. If the design does not include mobile and tablet versions, I create them during development, adapting layout, typography and navigation for every viewport.
Does the theme work after handoff without your support?
Yes. The code is structured and documented so another developer or the agency's internal team can step in without depending on me.
Can I reuse the theme for multiple clients?
Each build is custom for the specific project. If reusable foundations are needed, we can agree on a white-label starter theme approach.
Next step
You have an approved design file and need someone to turn it into WordPress?
The Design-to-WordPress service page explains how I work on builds from approved design files for agency teams.
Open the Design-to-WordPress service