5. FINDING A CODER
In the last chapter, we gave you a great deal of information about the basics of
HTML coding: browser theory, tag management, browser interoperability, and the
more advanced coding world of CSS. In fact, we gave you so much information
that some of you may have decided, on the strength of the last chapter alone, to
give up on coding and look for an outside coder instead. That's perfectly fine--
and even those of you who have substantial HTML/CSS experience might be
interested in finding a coder in order to save time, or to give a website a certain
look or feel of which you aren't yet technically capable. So, let's get started on
learning how to find the perfect coder for you.
WHAT TO LOOK FOR
The most important quality to look for in a coder is experience. This is true of
almost any job, yes, but it holds especially true for any job that involves
producing goods, rather than simply providing services--and websites are actual
goods. And as valuable as experience is for, say, a carpenter, the value of
experience is at least doubled for programmers--if a carpenter builds a bookcase
incorrectly, the potential damage is limited to your books falling over, while if
your website coder builds the website incorrectly, you stand to lose massive
business, compromise the security of your commerce system, or even exposure
your web server--and thousands of computers besides--to nasty viruses or
worse. If you look for a coder based on credentials alone--a degree from a
design institute, for example, or a certification course--then you ensure that you
have someone who at least knows about all the concepts that website design and
coding requires--but you can't be sure that your coder will know what to do in a
real-world situation, where things can and do go wrong as often as possible. So,
if at all possible, get someone who's done HTML work before and save yourself
some problems down the road.
It's also important to choose your coder based on the kind of experience they
have. You don't necessarily have to choose a coder who's done direct response
site work before--if you followed our instructions in chapter three, your site map
should be good enough to communicate to your coder exactly what your site
needs to maximize your conversion rate--but it can be helpful, especially if your
coder has resolved some direct response site problems before and can help your
site avoid similar problems. What you do need is a coder with substantial HTML
experience, especially experience with sites that involve integrated commerce
systems. Buyers will forgive a few lapses in the composition of your page but
lapses in your commerce system interfere with the simplicity of the buying
process, potentially compromise buyer security (and the security of your own
accounts), and give your site an extremely bad name--and thus a low conversion
rate.
Depending on how you've designed your site and site map, you may want to hire
a coder based on CSS, Flash, or Java experience as well. If your site design calls
for effects that only these types of coding can provide (see the previous chapter
for a quick discussion of what CSS can do that HTML can't), you'll certainly want
a coder who can bring those skills to your project. Even if your site doesn't
explicitly call for these skills, consider hiring a designer with experience in this
area anyway--you don't know how you might choose to revise your page in the
future, and if you do decide to incorporate some advanced styling or effects in a
later iteration of your page, you'll want to use the same coder in order to ensure
a greater familiarity with the material and an idea about the specific problems
that may arise from implementing more complicated layers of coding.
What's more, a good CSS/Flash/Java coder can suggest ideas for improving your
website that you may not yourself have thought of. For example, you might be
using a proprietary commerce system in order to handle your online orders--until
you meet a coder who can create a more secure, easier-to-use commerce system
with no service charges and that goes with your overall site design. A good CSS
coder can also overhaul the look of your page with comparatively little effort,
bringing in more paying customers and usually giving them a better experience of
your page.
Whatever qualifications your coder has, it's always a good idea to check out all of
the sites they've worked on, as well as any HTML examples they include in their
portfolio. Look at the kind of work your prospective coder does: are there any
special layout tricks that they tend to use over and over? Any stylistic choices
that you just don't like? Does the site work well, or is it confusing to navigate or
use?
Don't overthink this part of the hiring process: if you navigate your potential
coder's portfolio on instinct, you can get a closer approximation of how your
eventual customers will use sites designed by that coder. And unless the site is
simply a mess (either functionally, stylistically, or in terms of navigation), don't
necessarily take the coder out of consideration: what you might perceive to be a
personal lack of taste or foresight could easily be a result of bad decisions taken
on the part of this coder's former clients. As long as you're providing the basic
site map and stylistic ideas--and as long as the coder obviously knows what he or
she is doing on some level--you can avoid the pitfalls your competitors might
have made and ensure that your site will be successful and striking.
Although it's often overlooked, there's one factor you should take into account
when choosing a coder: his or her personality. This isn't as much of a
consideration for a short-term website project (like the average direct response
website) --but depending on your business plan, a coder with a good personality
can be an asset in the long run. As we'll talk about in a later chapter, you're
likely at some point to want to do some revision on your site--whether to add
new products, resolve some functionality issues, or just to give the site a nice
graphical overhaul. And it's far easier to make these kinds of changes if you
know and trust your coder already--easier on you, since you don't have to go to
the trouble of searching out and hiring a new coder, and easier on the coder,
since they already know your basic business plan, site needs, and preferences--
and they also know their own code well enough to start working on your revisions
immediately without having to spend a great deal of time familiarizing themselves
with someone else's work.
WHERE TO FIND CODERS
So now you know what to look for in a coder--but a much greater problem for
many people is the problem of where to find the perfect coder for your project. It
isn't simply a matter of posting an advertisement in a local classified section and
waiting for responses--that might get you some potential candidates, but it
removes one of your best tools for assessing the suitability of a coder: the
portfolio.
One useful method is to post your project on freelancing programming sites, one
of the most prominent of which is rentacoder.com. Rentacoder.com allows
software buyers--such as yourself--to post details of your project on their
directory of projects, along with some idea as to the rate you're willing to offer.
Coders can then bid on your project, giving you portfolio examples, any
certifications they may have, and their ideal rate for the work. Once you've
checked out what they can do, you can approve their bid, place your payment in
escrow, and just wait for the coding work to be done. As soon as the coder sends
you the work (and as soon as you approve it), the money is released to the
coder, and you can both go on your ways--your coder with his cash and
experience, and you with your functioning direct response website.
There are a number of advantages to this method. Most importantly, there's the
wide talent pool from which to choose--just as putting your business on the
Internet gives your product a much wider potential audience than you could
achieve through traditional channels, looking for contract employees (like coders)
over the Internet gives you a much wider selection and a much greater chance of
finding someone with the perfect skills for your job. Additionally, services like
rentacoder.com greatly simplify the process of interviewing potential coders and
determining prices: most of the things that you need to know about a coder
(namely, their skills and their price) is available at the rental site, just waiting for
you to sort through the options and make your decision.
But it's important to keep in mind some of the disadvantages to services like
rentacoder.com as well. For one, it's very difficult to get a good sense about a
potential coder's personality from their rentacoder.com profile or even their skills
set. Again, this isn't a problem for short-term work, but as we've discussed, the
ideal relationship with a coder is a long-term relationship. Not only does
rentacoder.com make it more difficult to create such a relationship by masking
coder personalities, but it also makes it more complicated to hire a coder on an
ongoing basis. Rentacoder.com only allows you to bid on a coder for a single
project--e.g. a single website--with no simple provision for providing ongoing
work.
Fortunately, these obstacles aren't insurmountable--it just requires more work on
your part in order to build and nurture a relationship with your coder.
Rentacoder.com automatically releases personal details like phone number and
email address for all projects above $500, allowing you to contact your coder
directly--once the project is in motion, unfortunately. Before the hiring process--
or if your design work costs less than $500, which it shouldn't (see below)-you
can post messages to your coder on the rentacoder.com message boards or chat
rooms, which is the ideal way to contact them--and there's nothing that says you
can't ask for a phone number or email address in such communications to help
you make the informed decision before renting a coder.
Are there other options? Of course--there's always classified advertising (on or
offline), there are personal references from other business contacts, there's the
possibility of emailing the designers of high-profile sites that you've seen and
liked, and there's the ubiquitous Craigslist posting. But if you're willing to put in
the effort to build a personal relationship with your coder (and to assess their
personality and skills before hiring), sites like rentacoder.com simply offer too
much variety and too much talent to ignore altogether.
WHAT TO SPEND
Web design isn't a cheap proposition. Although it's certainly possible to find
someone to design your entire site for around $150, the adage in this case holds
true--you get what you pay for-and you're unlikely to get a high level of
commitment or talent for those rates. Alternatively, it's certainly possible to find
someone to design your entire site for around $3,000--but again, although you're
nearly assured a high-quality site, it's difficult for many start-up businesses--or
even established businesses--to drop that kind of money on a single project.
Expect to pay anywhere from $1,000 to $2,000 for a good direct response site--
the more features you want on your site, the higher the price. If you want a
good commerce system programmed to order, expect to pay at least $2,000 or
higher--one strong argument for using a proprietary system. This may seem
high but consider what you're getting for the money. Web designers with enough
experience to be valuable to you make their entire living from their designs, as a
rule. If you underpay them, then they're forced to take on other work in order to
make a basic living--which means time taken away from your site and a lack of
willingness to work with you in the future. This undermines many of the basic
objectives of your business and can easily lead to your spending much more
money down the line to fix any problems that are created by underpaying your
programmers. So, do it right the first time and pay for the level of quality you
want to get (within reason, of course, and within your budget.)
Once you have a coder, you've made a huge step toward getting your site ready
to go live. In order to go the rest of the way, keep reading as we talk about the
next phase of the process--working with your coder in order to ensure the best
site possible.
6
CODER COLLABORATIONS
If you've followed our advice so far, you've got a good site map and site design in
your head, you've got an excellent coder at a reasonable price (for both your
coder and for you), and of course you've got an outstanding product to sell. At
this point, it's time to put all of these elements together to create a revenue-
generating site that'll turn a profit. But in order to do that, you'll have to master
one crucial skill--collaborating with your coder in order to create the perfect
website for your purposes.
THE BASICS OF COLLABORATION
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 if 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 they could
only come from your specific coder.
The best method for your 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 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 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.
Additional CHARGES: HOW TO HANDLE THEM
Don't be afraid of additional charges. (Don't be totally comfortable with them,
either--see the next section.) As good as your basic site map and strategy are,
they won't always be able to stand up against the various problems that occur
when translating a good idea into a reality. And when those problems occur, it'll
cost you and your coder both money and time in order to correct them.
Additional charges can crop up for any number of reasons, but always crop up
from only one of two sources: you or your coder. You might realize at some
point in the design process that there's a better way to organize your basic site
map, that there's a certain angle for selling your product that you'd like to
incorporate into your website, or that your original design ideas pale in
comparison to what you've just come up with. Your coder, on the other hand,
might build your site exactly to specifications, test it out, and find out that there's
a fundamental problem with your collective solution to the three basic design
problems of direct response site design. The interface might not be wholly
intuitive, for example, or your commerce system might not be integrating with
the page properly in order to give customers a seamless ordering experience.
You have two tasks when responding to additional charges:
• Are they necessary?
• How much are they worth?
The first task requires you to look at the website as it stands and determine
whether your customers' experience will be negatively impacted by whatever
problem you or your coder has come up with. This isn't just a matter of
determining whether the site works or doesn't work--it's also a creative problem
of figuring out if you can make the site work without requiring a great deal of
additional effort on the part of your coder. If your basic site map is too
complicated, is there a way to untangle it by moving around existing HTML files
and changing a few links, or is it necessary to rebuild the site from scratch? If
your user interface is complicated, is there a way to scale it back--from Flash to
HTML, say--without requiring a great deal of additional coding and testing? If
your commerce system is buggy, can you find another one to drop in without
requiring a total redesign? These kinds of issues will have to be dealt with on a
case-by-case basis according to your specific site and product.
Once you've determined that you have a legitimate reason to authorize additional
charges, you'll have to determine just what to charge. Listen to your coder's
advice, balance that against a list of standard design fees and the total cost of
your project and approve whatever your budget is capable of approving (with an
eye to any more unforeseen charges that may come up.)
Whatever you decide on, make sure that you don't simply allow your coder to act
like an auto mechanic--make the repairs first, bill you for it later. This is another
reason why it's essential to maintain regular contact with your coder while the
site is being built. Make it clear that if your coder encounters any potential
problems, he or she is to report it to you first before making any changes. This
limits the coder's autonomy to some extent--but it also saves you a great deal of
money, which is usually worth the slight time delay that approving each change
will take.
WHEN IS THE PROCESS COMPLETE?
The simple answer to the problem of when you can consider your site complete:
when it's done.
The more complicated answer depends on one of two things happening:
• You have the site you want.
• You can't afford to pay the coder for any more revisions.
Unless your site simply doesn't work--meaning that it actually crashes browsers
when it loads, or that the individual pages don't link together properly--don't be
afraid to accept the second outcome. Remember our TV analogy: the goal of a
direct response web site isn't to be beautiful, but to sell a product. Yes, making
your site beautiful, intuitive, and efficient can help with this ultimate goal--but it's
more helpful to have a website that works and does its basic job.
And remember that you're running a business, not an art museum. The basic
rule of business is not to let your costs exceed your profits--and until your site
has been up for a while and has plenty of referrer links and other promotion, your
profits aren't going to be massive, and certainly not high enough for you and
your coder to spend infinite time picking at the tiny flaws in your website. If you
exceed or come close to exceeding your design budget and you have a site that
functions, contact your coder, pay what you owe, and call an end to the process.
But make sure to leave the door open--once you're making some money from the
site, you may want to go back to that same coder in order to finally get your site
to the level of perfection that you want--or to expand your site into something
else altogether. Just because it doesn't make good business sense to refine your
website now doesn't mean that you won't want to refine it in the future-and
possibly a nearer future than you think, if your product and your overall strategy
are where they should be.
So far, we've covered the basic principles of direct response site design, we've
covered how to build your own basic site, and we've covered the process of hiring
and working with a coder to make your site all it should be. But there's one
crucial element of a good direct response site that we've left out: the sales letter.
In the next chapter, we'll discuss just that: the final piece of the direct response
puzzle.