Wednesday, July 02, 2008

10 ways to make your Web site design project go smoothly

Practical tips for building a website ...

"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.

Note: This information is also available as a PDF download.

#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.

For example, let’s say that you settle on having a navigation bar directly underneath the header, and after you’ve invested a lot of time in this design, you discover that your site would be better served by a list of links on the left instead. That’s a lot of wasted time. Get your site map first. Once you have a decent idea of how the pages relate to each other, then you can start drafting designs."    (Continued via TechRepublic, Justin James)    [Usability Resources]


Post a Comment

<< Home

<< Home