Part 1: Developing, designing and costly assumptions

Is there a difference between a developer and a designer?
In my mind, yes, there is a difference between a developer and a designer. If you want your website to be artistic, organized, and properly formatted, you need a web designer. If you want your website to actually do something useful besides just look back at you from the screen, then you need a web developer.

A web designer is someone who is skilled in graphic arts, layout, and HTML. A web developer is someone who is skilled in programming: Perl, Java, Javascript. A good web development firm will have both of these types of people in the back room, waiting to pounce on your new website idea. A lot of times we'll use these terms interchangeably, I'm guilty of it myself, but they are really two entirely different disciplines.

You need both schools working TOGETHER to produce a website that can both look good and function well. Of course, this is where "project management" starts to come in to synchronize both schools.

Some people can do both of these tasks... a lot of smaller web development firms will employ these all-purpose people. But I think with the current pace of technology, the all-purpose "webmaster" of yesterday, that one person that can both design graphics and code in Perl, is long gone. This is a good thing, too.

From a client perspective, you want this separation to exist in the development firm you choose. First off, it speeds up development time. The designers design while the developers develop. Website development isn't a linear process, so you can have one team working on the slick home page graphic while another team works on the login programming for the home page. This is a lot faster than one person working on the design and then switching hats to work up the programming code.

Second, there is a specialization of skills that is critical to website development. If you were going to have open-heart surgery, would you prefer a heart surgeon to perform the procedure or would you prefer a more general health care professional that does some open-heart surgery as well as some dentistry?

The answer here is obvious, you would opt for the person that has devoted their professional career to the one thing you need. The skilled professional will know every nook and cranny of their subject. What does this mean for the website client? It means they can further avoid paying for time due to the learning curve.

What are the biggest problems for clients when contracting a developer to build their website?
There are a lot of problems for clients. The biggest problem is determining whether the developer can do the appropriate job and has done a similar job before.

I think a lot of times clients can wind up paying for the "learning curve" involved in a project as many developers take on jobs that are over their heads. That's unfair to the client.

I've had many disgruntled web clients come to me asking for completion of a project that their previous developer couldn't finish in time, on budget, or just plain couldn't finish. If your company needs a website with the functionality of then you had better go to a company that has built a site like that before.

Ask questions of the developer specific to the site that you require. Ask for references for the sites the developer has built that are similar in nature to your proposed website. This means you'll have to do a bit of technical research yourself so you can ask intelligent questions but it will surely pay off in the end.

The "learning curve" problem is a bit of a "catch-22" for the developer as well. For the developer, it's the problem of, "How do we get a job involving ABC technology without experience in ABC technology? How do we get experience in ABC technology without a job that requires it." The pace to keep up with the latest technology does indeed affect everyone involved in creating and maintaining a website.

What are the challenges for website developers when dealing with a client?
Assumptions. Either the developers make assumptions about what the client wants or needs or the client makes assumptions about the product/services they are getting for their money.

Here's an example of an assumption from the developer side:

Suppose my web development firm is doing some database work for company XYZ. We've created a database that has fields for all the important values involved in a transaction, like first name, last name, credit card #, etc. This online database has to interface with company XYZ's existing internal computer systems.

The database programmer at my firm has decided decent lengths for the 'first' and 'last' name field is 30 characters. This is all well and good ASSUMING company XYZ's internal system can handle 30 characters for the name fields. What if it can only handle 28 characters?

An example of an assumption from the client side:

My web development firm is still working on the website for company XYZ. We've completed the database and all the HTML template pages as well as the logo design and illustration. We hand the site off to company XYZ for approval before launch. Company XYZ in turn replies, "The site is great, but when we print out the web pages, they come out weird. We ASSUMED they would look fine."

The ability to print out each page and have it nicely formatted was not previously discussed as a requirement for the site. The client assumed that this was part of the package.

The larger the focus of the assumption made, the more time and money it will cost to fix the problem. Obviously, a detailed, well planned contract can help alleviate many of these problems. The good developer/designer should be able to coax the expectations of the site from the prospective client.

These expectations make up a good portion of the site. If the client simply says, "I expect the visitors to our site to print out every page of the website," then you have a section of the contract devoted to that part of the product.

As a developer/designer, I try and make it as clear as possible that I can only do the work that is specified in that written contract. If it's not written there, it will not get done. Many times, my firm would accompany contracts with demo HTML pages for look and feel.

Of course, a contract can only be so specific, otherwise, every contract will wind up being hundreds of pages long. So, any decisions on the site made past the initial contract signing needs to be put in writing, at least in an email.

As a developer/designer, you have to recognize that moment where you start to make a decision about the site you're working on... pick up the phone and call or email the client as to the direction you should head. It's not your decision to make. It's not your site!

Similarly, as a web design client, you have to communicate the expected outcome of the project, so the developer knows where to head.

Continued...