The first step in a fruitful coder collaboration is always to make your needs known as specifically as possible in the first communication.
Ideally, your coder will be familiar with the basic principles of direct response site design, which keeps them on the same page as you throughout the process and which eliminates some of the initial effort of explaining yourself.
If your coder isn't familiar with the basics of direct response site design, make sure to communicate it to them as soon as possible in the collaboration process.
The same three rules we gave you earlier in this book will be perfectly fine for your coder as well--as long as you back it up with all the rest of the work you've been putting into your design ideas as well.
Of immense help in the collaboration process will be your basic site map.
This gives your coder the basic template in which he or she can start bringing your more complicated ideas to life, as well as a sense--a not very fleshed out sense, true, but a sense--of what the finished product will look like, as well as how it'll behave.
Don't think of it as condescending to give a site map to your coder, either--it isn't, and he or she is likely to thank you for it.
It makes your coder's job infinitely easier, speeds up the overall process of building and revising the site--and saves you from any unwanted additional charges down the line.
Once your designer has the basics of direct response design down, and once you've given him or her a copy of the all-important site map, it's time to start thinking more specifically in terms of overall style and feel.
Here's where the process of collaboration can start to resemble a true collaboration, rather than you simply telling your coder exactly what you want and expecting delivery.
There are two ways to play this--or rather, there are two extremes you can take when working with your coder on the overall look and feel of a page: The coder makes the page look exactly like you want it to look.
The coder, using his or her individual design skills and abilities, designs the look of your page for you from the ground up.
The best method of collaboration lies somewhere between those two extremes.
To some, the first extreme is the obvious choice.
You know the product, after all, you know the principles of direct response site design, you've built the site map, and you've put a great deal of work into designing the site in order to take full advantage of the basic principles while giving customers easy access to all portions of your website.
Any work the coder puts into your page design at this point can only serve to complicate things: it can make the site much more difficult for customers to use, for example, or it can put an undue amount of strain on your web server or overall bandwidth, or it simply won't look right to you.
After all, the coder is your employee: you're paying him or her to produce a website for you.
Since you're putting out the money, you should expect to get exactly what you've designed--exactly what you want.
To others, the second extreme is the obvious choice.
Yes, you know the product, and yes, you designed the site map, but you're not at all sure that you know how that site map should be fleshed out.
You have ideas, of course, but your coder is a professional in the field of web design, has plenty of experience designing other sites (if you followed our advice in the previous chapter about finding a coder), and brings his or her own distinct personality and visual style to the product.
The work the coder puts into your page design may solve some of the problems that your original design ideas didn't anticipate: that work might improve the efficiency of your site's load time, it might give customers additional unobtrusive methods for getting to all of the important content on your sight, or it might simply dazzle you and your customers with its innovative look and feel.
The coder is your employee, yes: but part of what you want when you pay that employee is their instinct and expertise, not merely their ability to follow your orders.
You expect to get the basic site you've designed, yes--but you also expect to get something that exceeds your expectations, something the could only come from your specific coder.
The best method for your particular site and your particular coder is probably somewhere in the middle.
Talk to the coder about your visual and other design ideas--give them any sketches, notes, or other work you've put into the site.
Explain to them some of your general concepts, and talk about what you absolutely don't want to see on the site for whatever reason.
Then--once you've communicated some of the specific things you want and don't want on your site--let your coder loose on the project.
The coder will feel better about the project: you're not leaving every decision up to them (which can paralyze a less-experienced coder, or which can result in a site that you as the client absolutely hate), but you're still giving them a good measure of autonomy in working on your site (which engages their creativity, encourages them to seek out and solve any design problems in their own personal style--and encourages them to work with you again on any future projects or site expansions that may be necessary in the future.
) Of course you shouldn't cut your coder completely loose once they have your basic instructions and design ideas.
The easiest way to guarantee success with a page design is to maintain a regular schedule of communications with your coder throughout the project in order to ensure that he or she isn't wasting time implementing features that you ultimately don't want to use in the site--and to ensure that your coder is staying on task throughout the project.
What's the right schedule to keep for regular communications with your coder? This depends on the overall size of the project.
Any direct response website is going to require less work than a sprawling site full of image galleries, articles, or content nodes.
For the average direct response site, expect to give your coder about a week to build a first draft of the site, and schedule another meeting either one week from the start of the project or a day or two after the first draft of the site is turned in.
(If you choose this latter option, make sure to schedule a meeting one week from the start of the project whether the first draft of the site is turned in or not--you don't want your coder to stall indefinitely on the site, costing you time and money, and a reasonable but firm deadline for a progress report guarantees that you won't be wasting that time or money.
) Keep up that regular schedule of contact until you and your coder both arrive at a version of the site that you can be happy with.
And above all: make sure your coder has access to all of the resources he or she needs in order to complete the site.
This means giving them any photos they need, any product specifications or testimonials you want to include on the site, details on the commerce system you'll be using, and of course the all-important sales letter (which we'll talk about in great detail in the next chapter.
) Ideally you should get this to your coder immediately upon hiring them and holding your first design meeting with them.
If that simply isn't an option for whatever reason, set a specific date when you'll provide the information and hold to it.
Under no circumstances should you expect the coder to design your entire page without having access to these crucial resources, even if you know enough HTML to plug them in yourself once they're available.
Minor differences in the size of an image, the length of a sales letter, or even the commerce system you intend to use can result in hours of work on the part of your coder as he or she tries to adjust the site design to accommodate your photos and resources--hours of work that you'll end up paying for.
So either get your resources to your coder as soon as possible, or simply delay hiring your coder until you have all of your resources available.
There's no point in asking someone to build a website for you if you can't give them all of the tools they need to build it.