|
|
The XYZ Corporation of Anytown has asked you to meet with them. They've decided that they need to create a presence on the Internet and believe that you may be the person for the job. Your meeting is next week.
If you are working in a company where you have been called upon to head Web design, the issues discussed here may very well help you in communicating with your higher-ups. Just replace the word "client" with "boss," and you'll have
a good starting point for progress meetings.
Your first step in preparing to meet a client is to assess the situation. You'll want to get as much information on the company as you can. Check the Web, of course, to see what they are doing there (if anything). Then check with any contacts you might
have. The more thorough your search, the better you will be able to assess the situation.
Your next step will be to talk with the client (though this may come first, if the client has called you out of the blue to set up a meeting). Having some good questions for the client will often put you in a good light, as it will make you appear more
professional. Some key information that can help you prepare for your first meeting will often be necessary, and you really shouldn't be afraid to ask.
Some companies are pretty open when it comes to answering your questions. They usually understand the position you are in, and that any help they can offer will aid in streamlining the whole sales process. Other companies are downright paranoid, and
may say things like "we'll discuss that when the time comes." This is often the case with small- to medium-sized businesses that are unaccustomed to hiring contractors.
Should you run into this tight-lipped situation, your first step may be to offer to sign a non-disclosure agreement (NDA). This agreement usually states that you may not divulge or in any way make use of information provided by the company, unless and
until you are under contract to do so. If the agreement is worded in such a way as to be unclear to you, or is obviously going to limit your future, consult an attorney. Usually, however, these are pretty straightforward.
Should this fail to pry open the "box of secrets," you may need to make a tough decision. We live by an old adage that says that people who are always suspicious deserve suspicion. In business, people who are always thinking of ways in which
they might get cheated are usually also thinking of ways to cheat others. Sad but true.
We've worked with some very, very large companies, and have never had any problem getting information (once we've signed an NDA). On the other hand, we've been called out to meet with small companies who have refused to even tell us what they do. You
will almost never make any money from this second type of company.
If you are just sitting in your office, watching the paint peel, and you have an opportunity to meet with a secretive client, it will probably be worth it just for the experience. If, on the other hand, you would be taking time away from even
marginally profitable efforts, it may be best to just tell the client you're booked. We generally explain to them that we are busy professionals, and that we'd be happy to sign an NDA, but that they'll have to give us some more information before we can
arrange a productive meeting.
More often than not, we're able to pry some information out of a company after doing this. Many times, however, these companies are trying to pull a fast one (either trying to get you to work on spec, or just trying to get free information from you so
they can assign the task in-house); this happens all the time with multi-level (pyramid) marketing companies. You're better off spending an hour watching TV than wasting it with these bozos.
So, what kind of information will you want? What questions should you ask? Here are a few we find useful:
Even if you already know what a company does, it's often a good idea to ask them. The way in which they explain it will help you understand how they think of themselves. You might even go so far as to ask for a sales pitch on their products/services.
Most marcom professionals will anticipate this, and will give you a good overall feeling for their company's position.
If your contact acts like you should know what they do, you might just say: "I'm familiar with your organization, but hearing it in your words would really help me out."
Obviously, knowing precisely what a company does is the first step in assessing their needs. What the client sees as their needs, however, will help you position yourself. They may be looking to you to assess their needs, in which case, they'll
probably say something like, "We just feel like it's time we got on the Web," or "Clients have been asking[el]"
In other cases, you might get a detailed description of what exactly the company hopes to accomplish. Either way, this gives you a starting point.
This will be the audience for your work. Knowing what your intended market is will, of course, help you define the project goals. Even the broadest descriptions ("large corporations") are going to narrow down your presentation. If your
question is answered with starry-eyed hype like "Everyone needs our product," you may need to rephrase the question: "Who are your current clients?"
This will not only give you an idea of how well-structured the company is, but of what the budget might be. If they say, "Right now we've got a classified ad, and we're thinking about a brochure," you can be fairly confident that this is a
small-time business. If, however, they start talking about direct mail, print, radio, and so on, you may have a pretty savvy prospect.
Beware of companies who want to pour all of their budgets into the WWW. If they think that a Web site will be the miracle cure for slumping sales, they may come back at you when the cure fails to make them millions over night. Be honest with them, give
them the facts—not a pipe dream.
This is important in assessing the communications needs of your client, as well as their growth potential. This will obviously need to be addressed in great detail once you get going on the project, but it's never too early to hear it from the horse's
mouth.
This is, in many ways, a rephrasing of earlier questions.
Take note of how well the answer matches those of what they do, and who their clients are.
This is sort of a rephrasing of the needs and goals, but it may give you some insight into the organization. While the answer to the needs/goals question might be "We want to establish a presence," the answer to this might be "Our
competition is online, and the boss says we should be too."
This is to give you some insight into the company's motivation, and may give you some key points for your first meeting.
Obviously, this will have an effect on your own scheduling. It will also give you an idea of how well-organized and how desperate the client is. If the answer is ASAP, the project may be yours for the taking, but it might be a nightmare. If the answer
is "We'd like to have this completed by the end of next quarter," you might be bidding on a very large project.
What is the budget?
You'll almost never get a straight answer on this one, but it's worth asking. If they come back with "How much do you usually charge?" be prepared to respond. There is no way to accurately assess a project's cost without knowing every detail,
and giving a ballpark estimate is almost never in your best interest.
This also applies to people who call out of the blue, and ask what a Web site costs. A couple of our favorite answers are "How long is a rope?" and "How much does it cost to build a house?"—but you can also answer this by
saying that a Web site can cost as little as $100, or as much as $1,000,000.
This not only allows you to prepare mentally, but also with your supplies. How many handouts will you need? Should you bring a laptop, or a projector? Along with some of the other questions, it will also let you know whether the main players will be
in on the meeting, or whether you'll need several meetings to make the sale.
Whether there will be a team or a single contact will affect how you will need to work with the client. If every decision is going to go through committee, you can bet that the project will be late and over budget.
In many cases, the highest-ranking person you'll be meeting will only be able to make recommendations. Sometimes though, you'll be meeting with the decision-maker. For obvious reasons, you'll want to know.
Knowing your competition is very valuable when it comes to pricing, as well as preparation. Whether you're up against a Madison Avenue firm or Joe's Bait Shop and HTML design will dictate the form and content of your presentation. Unfortunately, many
companies will play this pretty close to their chest.
This not only gives you some idea of what they may expect, but will also give you insight on your own marketing efforts. Furthermore, it gives you an opportunity to close this little inquisition on a good note, by helping to reinforce whatever it was
that led them to the decision to call you:
"I got your name from Joe at World Wide Widgets."
"Oh yeah, Joe's a great guy. I really enjoyed working with him—he really knows his stuff."
Once you've bled all of the information you possibly can, you can begin to prepare for the first meeting.
The first time you meet with a client on a project is often called the discovery phase. This is where you and your client assess the possibility of working together, and find out more about each other. If you are responding to an RFP, you may be
submitting your proposal in your first meeting. Otherwise, this is the time where you will be getting all of the details necessary to draw up your proposal.
You'll want to be as prepared as possible. Decide on what equipment you'll need, prepare handouts, slides, examples, and so on. Plan for the worst-case scenario—that you'll be sitting in front of 20 people who have no idea what to ask you. Imagine
that you may be the only person talking for an hour.
Also try to anticipate any questions, concerns, or objections the client may have. And prepare to answer even the dumbest questions patiently. The CEO may be able to put together multi-million dollar deals in her sleep, but be dumbfounded by her VCR.
Making her feel stupid is not in the plan.
Also be prepared to have a pissing contest with at least one person in the room. Almost as a rule, you can expect that someone will try to stump you in some way. This is often the token geek, but can be anyone. It's usually someone who is in constant
fear of losing his or her place in the pecking order, and can only make himself/herself look good by making others look bad.
Be prepared to answer questions like "Isn't this whole WWW thing a scam?" and "How can you call yourself an expert when you've only got a year's experience?" as well as questions that contain only strings of acronyms.
Try to find this person as soon as possible and befriend him/her. Talk about what kind of systems the company is running, what he or she has at home, Star Trek, games, whatever. This person's recommendation may be the most important, and his/her help
may be invaluable in completing the project.
Don't hope that your portfolio will be the main focus of the meeting. It's usually better to show a few examples, going into detail about the scope of each project, the goals, and how those goals were met, than to show page after page of HTML design.
If you've never been in a sales meeting, you may have a hard time keeping focused. It's a natural tendency to either clam up or to blather away. Obviously, avoid either case. Be friendly, but not too familiar; reserved, but not snobbish. Respect your
prospect's time, but expect them to respect yours as well. If you're kept waiting for a half hour, don't let it pass without mention.
There will probably be a round of introductions; if not, instigate one. You should be introduced to everyone in attendance. Remember, you have something of value.
Next, there will usually be a brief synopsis of why you are there, and it will then be your turn to speak. After a few niceties ("nice day, nice office, blah blah"), go over a brief description of everything you've learned about the company,
and what you understand to be the project. Then ask if your facts are correct.
This sets the stage for two-way communication and forces the prospect to get involved in your presentation. It will also help to clarify who the key players are (usually the ones whom everyone turns to when you ask a question). You can always fall back
on a question or two if people seem to be losing focus, or if you're starting to feel like a bug under a microscope.
By the end of the meeting, you should be asked to submit a proposal. Make sure that you have a contact for any questions, that you have a firm understanding of the scope of the proposal, and that you know the exact date for when the proposal is
expected.
In most cases, the written proposal will reflect the size of the project. A quick "crash and burn" project may only deserve a one-page proposal, whereas a large project may require a lengthy write-up. You'll have to guess what your prospect
would like to see.
Regardless of its size, a proposal should not include any creative work on your part. You don't work for free, and most clients won't respect you if you do.
Most proposals will include the following:
Other items that might be included in a proposal are a glossary of terms, a historical look at the Internet, and other items that may help in your communication to an audience unfamiliar with the medium.
There is no set way to present a proposal, but if you can, present it in person to the main decision maker, and go over it with him or her. This will help you address any immediate issues, and may enable you to get some feedback on the spot.
It's generally not a good idea to present a mock-up of any kind until the deal is closed. This isn't in any way sneaky—you're not pulling a fast one. You get paid to make mock-ups; you get paid for your creativity—so giving either before
you've been hired is counter-productive.
Once you've been contracted, a mock-up may be the best way to communicate your ideas for approval. Now, there are several ways in which you can mock up the "look and feel" as well as the mechanics of your system, and which you choose will
depend upon your own skills and resources, as well as what you perceive as the client's needs.
A styleboard is basically a piece of foamboard or cardboard upon which you've laid photos, rough art, and text that give the overall impression of a page or system's look and feel. You can use photos, tissues (or layout paper), artwork, font
treatments, and the like to help define what the message will be, without actually going into the mechanics of how a page or system will look in HTML. The key elements of a styleboard can include
Using a styleboard can be difficult, in that it often takes more time to describe its contents and each feature than it's worth, especially if you're dealing with a company that has never worked with a design agency. All in all, we generally avoid
styleboards for two reasons:
Styleboards can, however, allow clients to see into your creative "engine", and can help them feel like they have some control over the way in which their system is being designed. For this reason, it may be best to think of styleboards (and
other proofing tools) as methods for client communication and involvement, rather than actual creative processes.
A structure diagram is somewhat like a flow chart, and somewhat like a site map. It is a tool with which you can describe the functionality of the site. Now, we've addressed the issue of actually trying to show every link within a page and
system—with a mass of lines running every which way—and this is definitely not the purpose of a structure diagram.
A structure diagram is meant to show the relation between the main pages of a system, and the main navigational structure as it pertains to the core message(s) of the site. In most cases, this will be achieved by a simple hierarchical diagram (as a
tree or as concentric circles) that will give you something to refer to as you describe a system.
Figure 27.1. A simple structure diagram.
A storyboard is a tool most often used in video production, but it can be adapted for use in presenting a WWW system's message. A storyboard is simply a series of rough sketches that depict the actions and flow of a presentation, and can be useful when
attempting to show a client the flow of a sales argument.
As a structure diagram shows the navigation and structure of a system from a "30,000-foot" view, and a styleboard shows the look and feel of a page or system, a storyboard can help you communicate how both the look and feel and navigation
will lead to the presentation of the message(s).
There's a lot to be said for just using your HTML work-in-progress for communicating with the client. First and foremost, it allows the client to see the limitations that you face throughout the process, rather than at the end. Secondly, it allows you
to stick to the project, and not waste time designing, explaining, and trying to follow mock-ups and diagrams. Thirdly, it helps to circumvent the possibility of a client getting vague or unreasonable expectations based on mock-ups.
Have we mentioned that HTML is still very limited? Well, be prepared to do the same yourself. Whether you are going to work as a commercial designer within a company, or on your own, a big part of your job will be explaining the limitations of the
medium.
As often happens in a sales meeting, a potential client will ask if you can put such-and-such on a Web site. Now, you can take at least two approaches on this. You can explain the limitations up front, as we do, or you can wait until after you've got a
contract.
Suppose someone asks if you can include a video on a Web site. You can answer "Absolutely," and then later explain why the client's system is always bogged down, or you can say "Yes, but there are some issues associated with doing
that," and then explain the issues, allowing your client the opportunity to make an informed choice.
There is no doubt that we have lost sales for doing this. Some designers will go into a sales meeting and tell a client everything they want to hear. In comparison, we sometimes go into a meeting with some hard news for clients unfamiliar with the WWW.
Sometimes, it can appear to the client that we just don't have the expertise necessary to pull it off.
On the other hand, by describing limitations up front, and by explaining issues like browser market share, bandwidth, audience, and the like, we are able to avoid frustrating our clients down the road. In our opinion, this is the more professional way
of doing business.
There have been more than a few occasions where we've lost sales to designers who painted a rosy world, and have later been called by a sheepish client to "fix" the Web site for them. The other designer pocketed some fast cash, but we gained
the client.
Just as inexpensive computers and ignorant clients made everyone with a laser printer and a clip-art collection a "desktop publisher," the media hype and onslaught of "point-and-click" HTML editing programs have caused thousands of
people to think they can call themselves Webmaster.
Half-baked ideas of virtual malls and unlimited income, and the would-be entrepreneurs pushing these ideas, are causing a lot of people and businesses to get burned. Carpetbaggers abound in this industry, and the dashed hopes and bad feelings resulting
from their unprofessional work reflect on all of us.
Don't enter this business with the idea that everyone needs a Web site, or that you are going to make a killing overnight. You are in a new industry, and you are a pioneer—be professional about it.
Overall, you should follow these simple business rules:
Don't give clients unreasonable expectations of what a Web site will accomplish for their business, don't lie about deadlines, and don't misrepresent the medium as a "limitless frontier." You're not a used-car salesman, you're a
professional—act like one.
Lying not only makes you a dirtbag, it makes the entire profession look bad. It's also fraud, and can have life-long ramifications. The corner donut shop probably has no place on the WWW, and trying to persuade them otherwise is in no one's best
interest.
Hmmmm, let's see: "dead" and "line"—this would seem to mean that if you cross that line, you're dead. This appears to be a fairly straightforward concept, so why is it that so many people misinterpret it as meaning
"approximate completion date" or some vague concept of an ideal goal?
Well, in fairness to many programmers-turned-designers, a deadline doesn't mean the same thing in programming as it does in advertising. In programming, a deadline is often as vague as having "something working by spring," whereas an
advertising deadline would be more like "have it printed and delivered by December 8.
If you work with businesses, you'd better meet your deadlines. Don't set unreasonable goals that you know you can't meet, and don't ever try to whine your way out of a deadline. If you make a commitment, you keep it.
If you are relying on a client to provide information, input, or approval, and that client is lax in getting back to you, then you have every right to extend the deadline. Make sure you include in any agreements that you are not responsible for the
delays caused by the client, and that you reiterate this when necessary.
Now, sometimes a client will make you work with one of their subcontractors (like a designer), and this person may put your needs at the bottom of a very large pile of priorities. If this is the case, document everything—you can't be expected to
control this person, and the client should know this up front. If it's your own sub that's dragging you down, however, it's your problem.
Again, it's often the geek-turned-designer who screws this up. Many geeks have poor social skills, which may be the reason why they were originally drawn to an industry where they don't need to interact much. Or maybe this type of left-brained
mentality lends itself well to working in a digital environment. Who knows?
The facts of the matter are that the moodiness, mutterings, and tirades of the "fragile genius" geek don't hold water in the boardroom. Nor does the pretentious practice of burying people in acronyms. You are an expert, and part of your job
is to explain what it is you are doing.
Now, there is certainly some wisdom from the way programmers interact that can be applied to specific situations. There may be a time when you will want to rely on acronyms to shut up an offensive yes-man. This is one of those people who feels that
they need to constantly keep a high profile to justify their job, and will read a magazine article just before a meeting so that they can throw questions at you to make themselves look better at your expense. This may also be a person who knows just enough
about HTML to think that he/she should be getting the project for his or herself. Feel free to squash this person like a bug, but make it appear as if you are honestly trying to answer his/her question.
Example:
Brown-nose: "Isn't the new SQRL going to completely replace the standard XYZ1?"
You: "Well, the SQRL is still in beta testing, and everyone seems to agree that both the TFP and RQQ will need to be beefed up before there is any commercial viability. For this project, the XYZ1 seems to be the lowest cost and best-tested option.
Is there some specific reason why you want to use the SQRL?"
Brown-nose: "[el]er, um, [el]yeah. I just wanted to bring it up—I heard something somewhere[el]"
You: "Oh."
Let the awkward silence rest on their shoulders. This shouldn't be your overall communication style, but it really can come in handy.
This should go without saying. Clients expect a service from you, and part of that service is communication. Communication is, after all, the whole point of the WWW. If a client wants to get in touch with you, don't lie, don't hide, and don't try to
shift blame. If you do, you won't have a client for very long.
For example, a certain software company was supposed to provide us with specific information in this book. We were given a contact (a project manager), and sent her an e-mail message requesting the information. A few weeks after it was due, we
called this "manager" to see what the delay was.
Well, first she wouldn't return our calls, then she claimed that she'd only just gotten the e-mail—though we knew the exact date and time that the e-mail was delivered. Next she told us that e-mail isn't really reliable—though one of her
company's focuses is on e-mail client software, and again, she had the e-mail. Finally, she said that it really wasn't her job, though we'd been referred to her by the company's top brass.
So, this person tried to lie her way out of just telling us that she hadn't done her job. It took us days to get the information from other, more reliable sources, and caused us to pull a few all-nighters to make our deadline. We made the deadline, and
have included the information, but we now honestly tell clients that we doubt the longevity of that company because of its poor managerial resources and business skills.
Don't fall into the bait and switch routines that have become commonplace in so many businesses. You've seen the magazine ads that say "$5 Web site" by companies that will nickel and dime every feature until that "$5" becomes
$5,000—for a site that isn't even worth the original $5.
A big part of your job is to anticipate expenses. Don't leave out features that you know will be necessary to an effective site, just so that you can give an apparently low bid: "Oh, you wanted graphics with that? Well that's gonna cost you!"
What, you want to get paid? Isn't staring at code and massaging graphics all day payment enough? Nah, us either.
For the most part, payment issues are legal issues, and you should consult an attorney to help you develop your contract. There are, however, some key issues you will want to keep in mind.
First, you'll want to split your payments up. You'll want to bill the client for at least a third of the projected cost before you start work. Clients who balk at this are generally either very small and unused to doing business, or are dishonest.
Secondly, you'll want to leave room for addenda that will affect both the cost and deadlines of a project. This way you can add new facets to the project without the need to rewrite the contract.
Third, you'll want to specify payment terms. If you want money up front, a net-30 payment schedule isn't going to cut it. Some companies assume net-30 on everything, and you'll need to make sure you both agree on the terms before you start work.
We've really stood upon the soapbox in this chapter and put ourselves in the position of presuming to tell you how to do business. Well, this is the last chapter, and it's about time we mouthed off.
Ethics and honesty are the marks of a true professional, and failure to live up to these standards derides the whole profession. Every profession has its black sheep, but in a technology as new as this, a few bad eggs can make us all stink.
We've parted with some hard-earned knowledge in writing this book, and we hope that it will inspire you to build upon your own skills and creativity. We hope that you will succeed, and that you will help push this industry in new directions. Above all,
it is our hope that you will help elevate this profession from the level of the get-rich-quick opportunists who are threatening to drag us all through their muck.
Now, go out there and make us proud—we'll see you on the Web.
