Web Development

10 ways to make your Web site design project go smoothly

Politics, lack of planning, overlooked details, and poor prioritizing can compromise your Web design or redesign effort. Justin James offers a simple roadmap to lead your project to a successful conclusion.

Politics, lack of planning, overlooked details, and poor prioritizing can compromise your Web design or redesign effort. Justin James offers a simple roadmap to lead your project to a successful conclusion.


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.

#4: Don't worry about the home page or link names

One of the most common stumbling blocks I have seen organizations get stuck on is the home page of the site. For whatever reason, there is this tendency of any meeting about the Web site to become a shouting match over what the home page should look like. As the technical person, I try to squash these immediately. Something like this usually does the trick:

"We are wasting time worrying about the content of the home page when we need to be focused on the design of the site. The home page's design will be identical to the rest of the site, unless there is an overwhelming reason for it not to be. The only difference is that the content area will be much more free form and will showcase what is inside the site. Let's get back on track with the Web site design, and once we have that nailed down and we are in the content creation phase, we can decide what content needs to be on the home page."

Without taking a stand on the home page contents, you can spend months talking around it without ever actually designing anything for the Web site.

Like the home page, everyone loves to get together and scream about what the words on navigational links should say. Whether the link says Contact Us or Get in Touch with Us is not something a Web site design project needs to spend time and resources debating. Again, take a stand on the topic and remind the group that link wording is a content level discussion, not a technical/design level discussion.

#5: Forget about the content, too, while you're at it...

On that note, you will want to try to keep all content discussions out of the design process. The home page and the links are two areas that are especially contentious. But there is also a tendency for people involved in the process to get hung up on what any given element will actually say. My experience has been that if you stick to Lorem ipsum text throughout the process, you make it easier for people to focus on the design itself, not the content. The last thing you want is to turn every design meeting into a grammar and spelling check competition. This also applies to images. Don't put any "real" images on the site for anything that is content and not design until you are headed for production. Why? Because the head of Project X will get hung up on the fact that you used the product from Project Y on the Products page instead of concentrating on things like color and placement.

#6: ...But don't let others forget about the content

Ever notice that in nearly every Web site project, the people who jump on your case about making your deadline never seem to have the content ready when you ask for it? Ironically, while it is your job to make sure that your working group doesn't get bogged down in content, you need to make sure that everyone else is staying on track with getting the content ready.

All too often, you spend months hammering out the perfect design, and then it languishes on the staging server for months, waiting for various departments to create their content. Sometimes, in the case of a redesign, someone says, "Just reuse the old content," even when it's not appropriate to the new site map. Either situation is bad. Once you have that initial site map together, you need to get a second group going (probably led by the Marketing department), devoted solely toward generating the content that the site map asks for. Of course, as this group gets its work done, the site map might change. This is normal. At the same time, if the site map changes radically and that forces a need to reconsider the design, better to have found out now rather than later.

#7: Organize the site around the users, not the organization

A common mistake when designing Web sites is to have the site map look an awful lot like the org chart. The problem with this is that unless the Web site is an org chart, users are not likely to use your map that way. For example, let's imagine that your company makes telecommunications gear and their accessories. Product X is a router made by the router division, and Product Y is the T1 module made by the module division. Users don't not want to navigate to different sections of the Web site to find the router and the related T1 module; they want to find Product X and Product Y next to each other, because to the user, they are related products. When working on your site map, ask yourself, "Is this relationship valid in the users' eyes or are we just organizing based on internal silos?"

#8: Don't overlook SEO, usability, and accessibility

Three specialized areas that are woefully ignored during Web design projects are SEO (search engine optimization), usability ("Can users use this?"), and accessibility ("Can users with disabilities access this?"). It's tempting to think the SEO "just happens" or to assume, "If I can figure out how to get around the site, it's usable," or, "Special needs users won't be interested in our site anyway." Wrong, wrong, and wrong.

SEO takes a lot of work. I try to keep up with the field, and a few years ago it was mostly, "Write clean HTML, use appropriate metadata, and make sure your content is targeted." Now, there is a lot more to it. If you want to leverage your Web site as much as possible and minimize the amount you need to spend on paid ads, you might want to bring in an outside expert (or groom one in-house, for large companies) to give you some guidance.

You don't need consultants for usability, although they can be helpful in providing an objective opinion. But you should keep usability in mind from Day 1. You don't want to invest three weeks on a special feature that everyone loves, only to find out afterward that its design is confusing. It's far better to say, "I don't think people will be able to use that" when the idea is first brought up. Likewise for the site's overall design. Better to have the usability baked in from the get-go than to try to bolt it on at the end, after committing to the design at large.

Accessibility is still mostly a technical challenge, but it is important to understand the relationship between certain design/development ideas and accessibility. For example, if you have committed to having some fancy AJAX widget, make sure that it either contains nothing that can be discarded or that users who can't use AJAX widgets have an alternative means of getting to the same information. Usability and accessibility need to be rigorously tested by "real users," too, as opposed to merely following a checklist.

#9: The details make the difference

Have you ever been trying to buy a product online and left certain sites because they seemed fly-by-night? Chances are, it was minor details that made you feel uneasy. Recently, I wanted to make a purchase and I got a "bad SSL certificate" error because the certificate was for the right domain but a different hostname. While I was willing to accept that, a lot of people won't go to check out if their browser tells them the certificate is bad. Mistakes like typos, JavaScript or other errors, and incorrect SSL certificates will ruin your chance to give the user a good impression of your company and its products. So make sure that you have the office spelling and grammar pro check out the wording, have real users batter the site looking for errors, and go over everything with a discerning eye looking for any glitches. If spending 5% of the project timeline finding these small errors can increase sales by even 5%, it's worth it. Even if you absolutely must launch the site without the final quality check performed, there is no reason you can't do it post-launch.

#10: Have a game plan!

Having a project plan in place is extremely important. Everyone involved needs to know what is expected of them, whether it be providing input into the site map, content, or graphics or selecting an SEO consultant. It's also important to properly set expectations on the goals and timelines. I have seen Web site design projects literally spend months hung up on minor points like "What goes on the home page?" while the rest of the site design was not progressing at all. I have also seen situations where the site design itself was done, but someone forgot to code up some widgets for it, or get the IT department to set up the new domain name, or have the e-mail administrator make an account for the Contact Us system, and so on. Make a game plan -- and follow it.

About

Justin James is the Lead Architect for Conigent.

17 comments
derekball614
derekball614

I can access it just fine. What browser do you use? Did you try to clear cache? Try chrome it should work better since the link is loading just fine Derek Balldwig CEO @ HGH Reviews

jevvv
jevvv

As I said above - dead download link for the pdf of this article

creativ1
creativ1

Interesting insights, but there are many conflicting issues here that are present on many projects that I've seen, including #1, which may or may not include a clueless manager or client to ensure mediocrity throughout. #7 is the best piece of advice that the rest of the article should follow. @creativcatalyst

RVossen
RVossen

In stead of paper prototyping you can use software like Axure or iRise to create prototypes. They very closely resemble the real thing. It's great to make stakeholders enthousiastic about the project, and to communicate requirements with people and elict requirements from people who aren't at home in the requirements process.

cerolog
cerolog

"Politely keep people without a clue out of the process..." LOL! Easier said than done, but it's true! If I had to single out one tip, it would be the wireframe design before coding. It does help. A LOT. Thanks, keep up the good work!

alexclover
alexclover

This post covers points that are far too basic and obvious to be of use to anyone in a real PM position. The real issue in PM is managing expectations, internally and externally (client), as well as putting a lot of effort into the specification/architecture process. Once that has been approved internally and externally, if it is very detailed, you're basically on your own to manage the thing. I've never heard of a home page mulled over for months... where on earth does that happen??

Thomas907
Thomas907

What is web site design? I know it describes the word project, but what is it and what does it include?

iain.sutherland
iain.sutherland

Good to see a sensible approach, not just a dive in and hope methodology to web design.

Justin James
Justin James

I agree that the PM is at the core of this. But at the same time, a lot of companies don't use PMs too much either, and that is more who this was aimed at. And the home page things... it happens anywhere that the CEO decided to inject themselves into the process, but had diferent ideas from the Marketing department who officially owned the home page, who had ideas that conflicted with the SEO consultant, who had ideas that conflicted with the usability consultant, meanwhile, the IT guys wanted to do something else that was more "fun". Sad, eh? J.Ja

mrtgrady
mrtgrady

To most of the industry it's the graphic design, supporting accessibility, usability and #(sometimes) SEO requirements. This covers everything from the look and feel of the pages as a whole down to the individual buttons, etc., that make up the pages. What it's not is organising how the user experience should flow - that's down to a well defined information architecture based on the intuitive and/or logical progression of a user from the home page of the site to the content they want to find. In large, complex site's information architecture is often supported by usability architecture to help plan the user journey. In any case neither one of these is web design, but they should be used to inform the designer of the parameters in which they should work - to set boundaries to their brief. Most web designers AREN'T information architects. They concentrate on the aesthetic rather than semantic aspects of the site and you often find beautifully designed sites with misleading or confused navigation, or lack of attention to SEO and accessibility.

Justin James
Justin James

Glad it makes sense to you! Sadly, it was the result of too many "dive in and hope" experiences. :( J.Ja

chris
chris

having this process bought into by the person who can implement it (keep it on track/enforce it).

jptess676
jptess676

Hey Justin- There's a 'tech-snob' on every thread regarding every subject...it's probably best to ignore them. The subject of your reply says it all. Most everyone here learned something from your article as did I... Thanks for writing it.

chris
chris

I think of websites as business tools, not art projects, therefore usability/workflow/speed are primary. I wrap them in nice packages, but I always place the things you discounted first.

lahiruj
lahiruj

This is the best article related to web design planning I've read to date! I've been in these situations and had to learn things the hard way (in the very beginning). Yet, convincing some know-it-all clients is next to impossible.

chris
chris

by content. I have now started taking payment up front.

gandolfo
gandolfo

Good to remind me again (and again) of the mistakes I fall into, and also to explain in a short clear format to the others involved, the reasons behind these recommendations. Graham / Switzerland

Editor's Picks