PSD to WordPress: How our WordPress web developers get it right

March 26, 2018

PSCA-wordpress-custom-design-theme-02PSD to WordPress projects are a vital service for any WordPress web development agency, Barn2 Media included.

I have seen WordPress web developers get PSD to WordPress projects right and others get it very, very wrong. Here's how we have perfected our processes to develop the perfect PSD to WordPress custom theme.

What is PSD to WordPress?

PSD to WordPress is the process of converting a web design from Adobe Photoshop into a fully functional custom WordPress theme.

Typically, the client will provide the PSD's - for example, after designing their new website themselves; or commissioning another designer who doesn't work with WordPress. Either way, they then provide PSD's containing the complete design of the website. The WordPress web developer's job is to develop a custom WordPress theme that matches these PSD designs as closely as possible. Usually, this also involves adding any extra features shown in the designs. This might be social media integration, a mailing list signup form, etc.

A PSD to WordPress theme project may or may not include building the actual WordPress website. WordPress web developers may provide the custom WordPress theme as a zip file for the client to install and use as they wish. Or they may be required to install the theme and add content to create a complete WordPress website.

Standards for WordPress web developers to follow

At Barn2 Media, we pride ourselves on converting PSD designs into custom WordPress themes that are "standards-compliant" and meet the latest web standards and WordPress best practices. What exactly does this mean?

Every WordPress web development company should have their own quality guidelines. Barn2 Media's company standards include the following:

  • WordPress themes should adhere to the Theme Review guidelines where possible. Of particular note are the following sections:
    • Code Quality - avoid deprecated WordPress calls, JavaScript errors, etc. Useful plugin:
    • Template Tags and Hooks – e.g. use get_template_part or locate_template to load theme files, use wp_enqueue_style/wp_enqueue_script to load theme CSS and JS files
    • Theme Template Files – see recommended template files and naming conventions
    • Theme Settings and Data Security – see naming conventions and data validation. See also
    • Some sections of the Theme Review are designed for themes submitted for review which would then be sold as commercial products or published for free on This wouldn’t apply for our WordPress web development projects (in most cases) and therefore these sections can be ignored:
      • Credit Links – not normally applicable in our case
      • Theme Documentation
      • Theme Unit Tests
  • Custom WordPress themes should take the WordPress Coding Standards into account. We don't require strict adherence to these as they largely apply to other types of project. However as a minimum, our WordPress web developers are required to:
    • Build custom WordPress themes with accessibility in mind, creating semantic, well-structured HTML. They should add features such as ARIA roles, skip links, font size and contrast tools where appropriate.
    • Avoid use of inline styles if possible. CSS files should be divided into logical sections and commented where appropriate. Our WordPress web developers are welcome to use CSS frameworks as they see fit, e.g. LESS, grid frameworks, resets, etc. IE-specific CSS should be in a separate file and loaded using conditional comments.
    • PHP code should be well-structured, well commented, easy to maintain and follow usual best practice. Code formatting should be consistent across files and projects. Code should not produce any errors or warnings.
    • Use jQuery in preference to plain JavaScript where practical. Where possible, jQuery code should be placed in separate file(s) and queued appropriately. The code should not generate any JavaScript errors.
  • Themes should be tested using the WordPress Theme Check plugin.

In choosing a developer for a PSD to WordPress theme build, it's important to ensure that they're up to date with the latest web standards. They should be able to produce custom WordPress themes of this quality.

No company's guidelines can cover everything. WordPress web developers need to be up to date on the latest standards and best practices and implement these in their PSD to WordPress theme builds without having to be asked. For example, they should know the best way to develop custom WordPress themes that are optimised for performance and SEO. They should know to implement buttons using CSS rather than embedded images, to use icon fonts rather than image-based icons, etc.

Note: Some PSD to WordPress theme projects may require adherence to additional standards, for example W3C validation, DDA compliance or DOCTYPE requirements. Most WordPress web developers don't build WordPress themes to these standards unless it's part of the brief, due to the extra expense this will incur for the client. When planning a PSD to WordPress project, it's therefore important to clearly specify which standards will be met.

Starter themes and frameworks

These days, hardly any WordPress web developers build a custom theme from scratch. This would take far too long and make the cost of PSD to WordPress projects prohibitive.

Instead, most WordPress web developers build custom WordPress themes based on an existing starter theme or framework. There are several options here, nicely described in an article by codeinwp.

At Barn2 Media, we have a flexible approach to PSD to WordPress projects. We let our WordPress web developers choose the tool that best works for them. With PSD to WordPress, there are different ways to achieve the same outcome.

While the exact tool doesn't matter, the important thing is that the PSD to WordPress build is done in a structured way that meets our quality standards (as described above).

Less skills WordPress web developers will approach a PSD to WordPress project by modifying one of the default WordPress themes. I believe this is a sign of inexperience as this is a popular starting point for new developers. Rather than modifying an existing theme, a WordPress website will be better structured and more streamlined behind the scenes if you use a proper starter theme or framework.

Even worse are WordPress web developers who choose a paid-for WordPress theme (e.g. from ThemeForest or similar) that resembles the PSD's for the website, and modify it to match the designs. This is a terrible way to do PSD to WordPress because most existing themes are hugely complex and not designed for this level of customisation. They're bloated and monolithic with tons of features (and unnecessary code) that most clients don't need, so they weigh down your WordPress for no reason. This inevitable affects speed and performance which can damage SEO as well as user-experience. It's fine to use an existing WordPress theme if you don't have a specific design for the website - however if you have a PSD then it's completely inappropriate to develop a WordPress website in this way.

If a PSD to WordPress web developer tells me that they build themes by taking an existing theme and modifying it then I steer well clear.

Honouring the design in PSD to WordPress projects

Sadly, I have seen PSD to WordPress projects where the WordPress website is a pale comparison of the PSD it was based on. This is generally caused by WordPress web developers without the required attention to detail.

One of the most important elements of a PSD to WordPress project is ensuring the finished website matches the PSD design as closely as possible. Less skilled WordPress developers use the PSD as a guide or approximation. I think this is disrespectful to the original designer. The web designer put a huge amount of time into creating PSD's that show exactly how the website should look. WordPress web developers should create a custom WordPress theme that honours and respects these designs, right down to the smallest detail.

Common mistakes that PSD to WordPress web developers make include:

  • Incorrect fonts or font weight
  • Incorrect line spacing
  • Elements not lined up correctly
  • Missing details such as image borders or hover effects
  • Overlooking specific layers in the PSD and therefore missing parts of the design
  • Incorrect colours that don't match the PSD

The above may sound like small details. However, the effectiveness of a web design often depend on these details. If WordPress web developers don't match the design exactly then the design will often start to fall apart. The WordPress website will look less professional as a result.

There's no excuse for any of these mistakes in a PSD to WordPress theme build. If the WordPress web developer has the right eye for detail then they will respect the PSD's and develop a WordPress theme that matches them exactly.

The one exception to this is PSD to WordPress projects where the client has created rough PSD's that clearly don't represent how the finished website should look. Some WordPress web developers will take PSD's like this and use their iniative to complete the designs and add the missing detail, finalising the spacing etc. as they build the theme. I think this is a flawed way to approach a PSD to WordPress project as it leaves too much room for misunderstanding and is impossible to quote for.

We only take on PSD to WordPress projects where the PSD's represent the final design for the website. If they are just a guide then a designer needs to produce the complete design before handing them to a WordPress web developer. This is much safer for everyone as the client knows exactly what their finished WordPress website will look like. The WordPress web developer's brief is to create a custom WordPress theme to match the designs - NOT to make design tweaks after they have built the theme (never a good idea...).

This brings me onto the topic of revisions...

Do PSD to WordPress projects need a contingency budget?

In theory, a PSD to WordPress theme build shouldn't require many revisions. If the WordPress web developer has created a WordPress theme that matches the designs and has tested their work properly then the client should request very few changes. They have received the service they expected, so there's not much to feed back on. If they request changes to the design after the WordPress theme has been developed then these should go back to the original designer; the PSD amended; the changes quoted for as a new task; and then implemented on the website. This may sound convoluted, however I have seen many PSD to WordPress projects where WordPress web developers have agreed to make minor design changes and the whole look of the website has been compromised. When you start to hack around with a design in an ad hoc way, things start to gall apart and the website loses its effectiveness. Designing a website is a skilled process and with PSD to WordPress projects, the designer should retain control over their design.

For complex PSD to WordPress theme builds, I find that it's a good idea to include a contingency budget as part of the original quote. Although the website should match the PSD's exactly and design changes should only be accepted as part of a planned change process, realistically the requirement do often change or evolve in a PSD to WordPress project. For example:

  • The client can often only visualise the full website then they see the working WordPress website for the first time. This crystallises their idea of what they want, so - quite understandably - they request changes at this point.
  • There's often ambiguity in PSD to WordPress projects as the PSD's can be open to interpretation. For example teh designer may think it's obvious how a particular element should behave when clicked on, but WordPress web developers have interpreted it differently and quoted accordingly. Good PSD's should minimise/eliminate this, but it can still happen.
  • As with any WordPress web development project, the client's requirements may change over the project. Their business needs may change or they may request new features not in the original brief.

All of the above changes are scope creep and can be quoted for and approved as they happen. However this isn't ideal as it interrupts the flow of the PSD to WordPress project, focussing on the finances rather than the WordPress website. Requoting every time the client asks for something new also damages the working relationship as although it's perfectly appropriate and reasonable, it makes everything feel as if it's about money which isn't the intention. The focus should be on developing a fantastic WordPress website, and budget should be a side issue.

Where possible, I recommend allocating a contingency budget for this sort of change. This allows everyone to work together more positively as the WordPress web developer doesn't have to keep referring back to the original budget. They have more free rein to meet the client's requests without having to renegotiate.

It's hard to set a contingency budget as you can't predict the changes that will be requested. Too low, and it's pointless as the WordPress web developer ends up having to requote once the contingency is used. Too high, and the client won't proceed with the PSD to WordPress project in the first place.

I'd generally recommend a contingency of 25%-35% for a PSD to WordPress project. This allows for some design changes and new features without eating up too much extra budget.

Agreeing a contingency for a PSD to WordPress project can be a joint decision with the client. Have the conversation and come to a mutual agreement on what level of additional changes they'd be happy to pre-approve without having to requote each time.

How many PSD's should WordPress web developers request?

Designers often ask how many PSD's or designs they need to provide for a PSD to WordPress project. I have been sent PSD's that only show the homepage, and PSD's fo every single page on the website.

The WordPress web developer will require a PSD/design for each template that is required for the WordPress website - not each page. A template is basically a layout. This fits with how WordPress works - WordPress web developers create templates which are re-used across the website.

Examples of the templates that WordPress web developers will often create in a PSD to WordPress project include:

  • Home (this page often has a unique layout whuich is more complex than the other pages)
  • Default page (usually with right sidebar)
  • Page with left sidebar
  • 3-column page with left and right sidebars
  • Full-width page
  • Portfolio templates - category, single portfolio item
  • Gallery
  • Blog - main blog page, archives, single post (note: a WordPress blog has category archives, author archives, date archives, tag pages etc. These can use the same template or the WordPress web developer can create a different template for each type of archive)
  • Search results page
  • Contact

While WordPress web developers don't need a design for every page, the PSD's should include all the styles and features that will be needed in the various pages. This will help the WordPress web developer to create all the styles that will be used to add the website content.

The PSD's should always include all the standard WordPress formatting options such as Headings 1-6, links, bold text, bullet and numbered lists, image borders etc. It should also include the default WordPress widget which will be used on the site, for example recent posts, text widget and search.

The designs should also include any additional styles that are specific to this project, for example custom widgets, toggles, tables etc.

Responsive PSD to WordPress websites

Most PSD to WordPress theme builds nowadays are responsive - they resize to fit mobiles, tablets etc.

If the WordPress developer uses a responsive framework or starter theme then the website will be made responsive automatically.

This is great, but it's important to remember that some work will still be needed to make a PSD to WordPress theme build fully responsive. I have seen WordPress web developers quote something crazy like 1 hour's work for the responsive design elements - forgetting that they need to fully test the responsive layouts and will probably have to make various tweaks to maximise user experience on small screens. You may want more control over the responsive layouts, for example to show/hide/replace different elements on mobiles. None of this will happen automatically, so responsive design is an important element of any PSD to WordPress project.

Should the designer provide the responsive layouts?

Ideally, the designer will provide PSD's for each screen size, showing exactly how the WordPress website should work responsively. I would always recommend this as it gives the designer more control and the client knows what to expect.

However I accept that this isn't realistic for all PSD to WordPress projects. This approach does increase the cost of the website as the designer has to design more layouts. Also, the WordPress web developer is likely to have to code more complex responsively layouts than if they let the framework create these automatically.

Where the budget isn't available for PSD's for each screen size, the WordPress web developer is normally requires to make these decisions. This isn't ideal as they are a developer rather than a designer. They may not be up to date with the latest guidance on designing for mobiles. Where this happens, it's important to set a limit on the level of revisions that the original quote includes for the responsive design. The client has requested a responsive WordPress website for a reduced cost - i.e. they didn't want to pay for PSD's for each screen size. They should understand that this means they will have less control over exactly how the WordPress website will look on mobiles and tablets. The quote should include time for tweaking and fixing any actual problems with the responsive layouts. However if you include unlimited revisions then it becomes more cost-effective for the designer to provide PSD's for the responsive layouts in the first place!

PSD to WordPress and additional features

PSD to WordPress projects often come with an inconsistent brief: "We need you to build the WordPress theme so we can install it ourselves, and we also need you to add all the features shown in the PSD's". This sounds sensible as the client is asking the WordPress developer to do the technical tasks they can't do themselves, allowing them to focus on the basic content management tasks in WordPress such as installing the theme and adding content. The problem is that it's not good practice to bundle functionality into a theme.

A WordPress theme is for the design and styling of a website. Functionality should be added via separate plugins.

If a PSD to WordPress project includes adding features shown in the PSD's - for example a mailling list signup form or Twitter feed - then the WordPress web developer will need to provide separate plugins as well as the theme. Some of these may be off-the-shelf plugins while others may be bespoke. The custom WordPress theme will contain styling for these features but not the functionality itself.

This obviously makes it harder for the client to install - it's not just about installing the theme. For this sort of PSD to WordPress project, I usually recommend that the WordPress web developer sets up the overall website and installs the theme and any additional functionality. They can either add all the pages and content, or hand the basic site to the client at that point.

PSD to WordPress: How WordPress web developers can get it right

To the uninitiated, PSD to WordPress sounds like the most basic and predictable type of WordPress development project. I do believe this is largely true. However like all WordPress services, it's important to think through each element of the project and develop an effective process. This will keep everyone happy - the client gets their PSD's converted into a fantastic WordPress website that will last for years; and the WordPress web developer has a successful and stress-free project.


  1. Outsource WordPress Theme Customization
    November 16, 2017 Reply

    This article is very simple and easy to understand. Thanks for sharing this with us, it is very helpful for everyone whether he is technical or not.

Please share your thoughts...

Your email address will not be published.