B O T T O M 
L I N E
Web Lessons Learned
Creating a Web site requires assembling a team with four unique talents and settling design and management issues up front.
by Joel Snyder
If you've ever looked at my company's home page . . . well, don't bother. Trust me on this one. You'd figure out pretty quickly that I'm not in the World Wide Web development business. Sure, I can slap together some HTML and write a program to go behind it, but that's the easy part of designing a Web site.
To remedy this obvious shortcoming ("Have you seen Snyder's home page? Looks like a tornado hit. . ."), Opus One has been searching for a designer to enhance our Web presence, and I'm going to share the lessons we're learning along the way.
Lesson 1
Designing a Web site is a team effort. If someone insists that he can do the entire job alone, pass him up. Every Web site requires at least four team members. First, you need the overall architect and designer, the team leader. This is the person who has the grand vision for the site. He should be drawing out big storyboards, making expansive motions with his hands, and asking lots of questions. What's the message? How is it going to work? How is it going to fit together? What's the purpose?
(Hint: Save some time and start answering these questions now, before you start interviewing designers.)
Next, your team will need a programming member. This is the person who understands HTML and whatever programming interface (CGI, Java, APIs, etc.) is used to give life to your site. The programmer is responsible for implementing the broad vision of the architect. After all, no self-respecting site has only pure HTML documents anymore. Everyone is adding forms, search
engines, and other data-driven pages to make each site as useful and informative as possible.
(Important hint: If your potential designer isn't talking about back-end scripts, you're talking to someone who's a year behind in site design. Keep looking.)
Every site needs graphics, and the third member of your team is a graphic designer. Whether they're your corporate logo or navigation buttons, some custom graphics are always going to be part of the big picture. You need someone who not only has artistic talent, but also knows the tools that computer-based designers now use.
Be careful here. Many graphic designers are being pulled into Web development before acquiring a real understanding of the medium. What works with 3,000-dpi screens and high-quality printers or presses is not going to work on a 640x480 screen with 8-bit color.
The fourth team member is you. A designer can lay out the storyboard, a programmer can build your HTML, and a graphic designer can create eye-catching logos, but without the content and guidance you provide, the site is just someone else's idea of your business. No one knows what you do and what you need as well as you do, and that insight is crucial to guiding the team you hire.
You also have to provide the content. Remember that your site should revolve around its content, not the other way around. A Web site is a way of packaging information, and if you're building the site before you have the information, you're doing it backwards. Plan ahead.
The design team you work with should start by asking you questions and gathering content. If someone comes in the door and wants to sell you his one-size-fits-all site outline, remember your last experience with one-size-fits-all clothing.
Your potential designer may not come to the door with all three team members in tow. Often, small companies have a series of stringers they hire to handle the graphics and programming parts of each site. Be wary if it's the programmer or graphic artist who's knocking on your door, though. Sure, there are multitalented people out there who can do all three jobs. But they're the rare exception.
You don't want to end up with a graphic artist architecting your Web site. Similarly, knowing how to program in HTML doesn't make you a site designer, just as knowing how to fix an engine doesn't mean you can design a car.
Lesson 2
Understand the costs and fees up front. This includes any costs for hosting your Web site (see my third lesson below). Designers should provide a quote for your whole site that is based largely on the number of hours it will take to create it.
Be cautious of anyone offering "price per page" quotes. A Web site is an integrated representation of some aspect of your business, not a bunch of pages stuck together. Page-based pricing may be sufficient if all you want to say is, "Hey, we've got a page on the Web!" It isn't going to work for the design of an integrated complex site.
Also be wary of a price too good to be true. A good Web site takes time to create, and time is money. If you're paying between $50 and $75 an hour, you're offering a good wage for expert work. Prices per page will vary wildly, but you can estimate that it's going to cost from $100 to $500 for each Web page. If you've got several dozen pages on which you can reuse graphics, the cost will be lower.
If every page requires meticulous design, $500 may be just a starting point. For major sites where each page is really a script generating a new page on the fly, be prepared to go even higher.
I prefer to buy services like this by the hour. That lets me know how much brain power I'm getting for my buck. Obviously, you want to put "not to exceed" limits into your contract, but the idea of scaling the cost of the site by the effort it took to build it makes a lot of sense to me.
Some designers will want to package the site as a fixed-price deal. That's OK, too--if the designer also can immediately tell you approximately how many hours that price represents. If someone gives you a fixed-price quote quickly but has to come back later to translate that into hours, you're not dealing with a business that knows what it's doing.
Every site requires maintenance. Information has to be updated and the site has to have a fresh face to entice users to revisit it. Make sure maintenance responsibility and costs are agreed upon at the beginning. Maintenance costs may even exceed the cost of the original site within the first year. Budget for it and build it into the contract.
If your designer is out of this world, he'll be so busy he won't have any interest in going back to do the unexciting work of keeping your site up to date. Protect yourself by signing a contract that guarantees you'll get a piece of his time to keep things current.
Lesson 3
Separate out the designing and hosting fees. A Web site has to be hosted someplace. You can put it on your company's own computers or pay an outside service to host it (see "Site Construction," April IW). Some hosting services will design your pages as well. However, you should insist on designers or services breaking out the pricing and allocations of the two components. You may be getting a good deal, but you need to know what you're paying for.
This is not to say that a designer's advice about where to place your site is irrelevant. Many designers have lots of experience and know who offers the best service for a fair price. But some designers are swayed more by profit sharing and kickbacks than by what's best for you. If your designer pushes you to one company or another, ask point blank whether there is a conflict of interest.
Your designer's advice may be in your best interest because of any relationships with hosting services the designer has developed. Just make sure you know why you're being steered in any particular direction. Be especially wary of folks who promise you low development costs but also lock you into using their preferred outsourcing vendor.
Lesson 4
Settle the intellectual property issues early on. Who owns what aspects of your site? The HTML code itself is pretty easy. What about the graphics? And what about the scripts? If you and your designer part company, can you hand the site over to a new designer to maintain and expand? Or are you locked in?
Scripts are a special problem because there are so many different kinds of Web servers out there. If you're running on Windows NT this week, your script probably won't work without changing it on Unix next week. Be prepared to pay to have scripts rewritten should you have to switch Web servers.
Being locked in sounds bad, but it may not be. I know a designer who targets a particular market niche and has developed software that runs on her own Web server to service that niche. She makes a nice living, in part because of the competitive edge her software gives her over others trying to break into that niche. She doesn't have to keep reinventing the wheel, which means her clients get more service for fewer dollars. But if any of her clients wanted to jump ship, she's not about to hand her software over to anyone else. If your designer comes to you with this kind of proposal, balance the downside of being locked in with the benefits of building on someone else's investment.
Lesson 5
Keep your designer honest. Most designers will come to your door with the latest in Pentium laptops and a slew of beautiful graphics on their hard disks. Tell them no way. Make them show you any demos using a regular phone line through your own Internet connection. If they're running a caching browser (like Netscape), clear the disk cache before you get started.
I see lots of Web sites where it's obvious the business owner only saw the site demonstrated from a hard disk--250K worth of color artwork on every page. Beautiful, but no one in his right mind is going to wait that long for each page to load, especially when the graphics are only peripheral to the content of the site. When you look at designs for your site, always balance the impatient index finger of the browser against the visual appeal of the page. 
Joel Snyder is a senior partner at Opus One in Tucson, Ariz.
Reprinted from Internet World magazine Vol. 7 No. 6, (c) 1996 Mecklermedia Corporation. All rights reserved.
