If you’re designing a custom landing page, chances are that you’re using a PSD to HTML chop shop, as my friends at PSD to HTML/CSS. The problem is that things you may obviously require won’t be obvious to the coders.
Here’s a checklist of things to specify in your PSD to HTML landing page order in your order to minimize revisions and save time.
1) Editable text.
If you have a button on the page, or fancy headers, you’ll probably want to test them.
If you don’t specify to the coders that the text must be editable, you may just get an image of text, instead of a button image with editable text positioned over it (the positioning is done using CSS). That will make testing harder, as you’ll need to get the graphic artist to design new buttons, headers, etc for each test.
2) CSS that enables flexible width page and buttons.
The corollary to having editable text is that you’ll need the page width to be flexible, and likewise your button width. Otherwise, you’ll find that the positioning of the page elements will overlap and look awful.
3) Flexible borders on images.
You don’t want your hero shot to get overlapped by a border, so ensure the border will adjust to the image size. Otherwise, you’ll constantly need to crop and get things pixel perfect.
4) Form submissions lead from the landing page to a thankyou page.
5) Easy to comment out sections of the HTML.
You won’t know whether an element’s presence helps or distracts until you test it. For that reason, you want arguably distracting elements to be coded in such a way that you can easily comment them out. The end result should still look good, and not have overlapping or ‘broken-looking’ elements.
6) The logo should not be wrapped in HTML tags reading “h1″.
This seems obvious, but sometimes things get coded this way. If you ever want to rank the page or use the template for another page you want to rank, this is something to check over.
7) Test the landing page ASAP.
Most providers provide a time-specific support guarantee, like 30 days of free support. If you buy a design but then delay launching the campaign for too long, you may find bugs after the guarantee period.
At that point, you’re at the mercy of the provider whether or not they’ll fix the bug.
Partly, it’s an accounting thing – they need to know when the revenue is fully “earned” for accrual accounting purposes.
Partly it’s also a memory thing. When the code is recent, the coder can edit and proofread more easily than if he has to re-read the whole thing from scratch.
So once you get your code, put in your various texts and images, etc and see how it performs.
Pay attention especially to longer vs shorter text, and functionality of buttons and forms. How are errors handled? Can users correct the mistake easily? Is the error message clear and not insulting ([You entered incorrect information [you idiot]” vs “We had trouble understanding your phone # because…”)?
If you liked this, add my RSS feed to your reader or get my latest posts by email.