10 Ways To Make Your Web Site Design Project Go Smoothly

Time and time again, I have seen companies struggle with Web site design projects. Initial Web site design and redesigns of existing sites may each face a few different challenges, but overall, they are similar. My experience has been that these problems are not technical issues, but project management and cultural issues. Often, no one follows a game plan—they just blindly rush off and attempt to re/design the Web site with little forethought. On the other hand, I have also been through a number of successful Web site re/design projects (measured by, "Did we get a good-looking, usable Web site deployed in a reasonable amount of time?").
Here are some of the things I’ve learned to do that will help make any Web site design project go smoothly:

1. Politely keep those who lack a clue out of the process
It is amazing, isn’t it, how all you need is a rumor of a "Web site project" and the company president, CFO, VP of Facilities, and other people with zero Web design knowledge suddenly inject themselves into the process? Your job (or your project manager’s job) is to get them out of the process as soon as possible.
There is a right way and a wrong way to do this. The right way is to show these other groups that you will do more than pay lip service to getting their input, while also showing them that you will come to them with a targeting group of questions driven by their areas of expertise. The wrong way is to just stop inviting them to the meetings or ignore what they have to say. When you involve them in the process in a limited "subject matter" capacity and take action upon their recommendations when sensible, everyone walks away feeling like they played a part. When you give them the cold shoulder, those who have been shunned will turn every problem with the new site into an opportunity to say, "If only they had listened to me, "

2. Prototype on paper before coding
One of the attractive aspects of HTML is that it is relatively quick and easy to prototype designs in. One of the fatal flaws of too many Web projects is that designers start prototyping in HTML before doing anything on paper. HTML prototypes do, of course, play a valuable role in the design process, but my experience has been that it is best to not create any until the design concepts have been narrowed down to one or two (three, at the most) potential designs.
HTML prototypes take a lot more time to create than paper prototypes (particularly of the "wireframe" type). You can sketch out a few boxes on paper to represent navigation elements, logos, footers, etc., in a few moments in a meeting, and everyone can get the idea instantly. Alternatively, you can spend 30 minutes hashing together a skeleton of HTML, adding Lorem ipsum text all over the place, finding a location where the IT department will let you upload it, putting it up, testing it, tweaking out a few obvious glitches, and sending out an e-mail with the link.
After all of that, what happens? The people who look at it get confused because it is a basic prototype. They want to know where the logo is, or why they clicked on the Contact Us link and nothing happened, or why the navigation elements are in the order you put them in. In other words, HTML prototypes are deadly, precisely because to those inexperienced with the concept of a prototype, it looks like a really bad design. They get hung up on precisely the things that make it a prototype. So do your initial prototyping on paper, and with the time and energy you save, you can make sure that the few HTML prototypes you do make are more fleshed out.

3. Build your site map before you start designing
One of the deadly sins in Web site design is trying to draw up a design without having a site map. I'm not saying that you need to know every single page before you can decide whether to put the navigation at the top or on the left. What I am saying is that the navigation hierarchy gets driven from the desired relationship of pages to each other. And since it is impossible to decide where to place navigation elements without knowing how many items will be in each one or how many elements you will need, a site map really is the prerequisite to a site design.

to be continues ,
(www.paediatech.webnode.com)

yay! thanks, u two. certanly informative. few years back i went into seriuos problems when i lead a dev team and flopped major. we had already collected the money for err'tin only to get stuck mid-way. . . one thing led to another and the firm was serious about police action if we didnt fulfill our part of the deal. my friend and his dev team bailed us out of that stuff. after then i saw the importance of following procedures to do stuff.

in school we were thought to use SDLC (software development life cycle)
the whole idea is following phases:

1. requirement gathering
2. analysis
3. design (paper work)
4. coding
5. testing
6. deployment/uploading

don't know how best to explain SDLC in a few setences, but google can do that. lol

i think one big mistake most of us make is going straight into the coding phase. i think every good software/website development starts with biro and paper.