It amazes me to see how many people out there call themselves web-experts. It is amazing to see business managers or owners who think that just because they can buy a template, or pay someone for services, they are getting a “professional” website.

The truth of the matter is that the web has made it easier for anyone to use web technologies. But this doesn’t mean that anyone understand how to do it right. I was researching for what others have written about site development process, and found a valuable resource for small-business or small non-profit organizations who might be considering a web development project. This is valuable regardless if you have in-house development team, or if you are looking to outsource.

The Web Style Guide starts with this:

In the long run men hit only what they aim at.
— Henry David Thoreau

THE FIRST STEP in designing any Web site is to define your goals.Without a clearly stated mission and objectives the project will drift,bog down, or continue past an appropriate endpoint. Careful planning and a clear purpose are the keys to success in building Web sites,particularly when you are working as part of a development team.

A lot of it only applies to small-to-medium site projects, and wouldn’t be applicable to large user-driven or to database or dynamic sites. Things like page counts are irrelevant when there aren’t really “pages” to count — its all according to parameters or variables. But, there’s still a lot in there.

Here is the one section I was looking for, and the one area where I think most companies flounder with.

Information architecture

At this stage you need to detail the content and organization of the Web site. The team should inventory all existing content, describe what new content is required, and define the organizational structure of the site. Once a content architecture has been sketched out, you should build small prototypes of parts of the site to test what it feels like to move around within the design. Site prototypes are useful for two reasons. First, they are the best way to test site navigation and develop the user interface. The prototypes should incorporate enough pages to assess accurately what it’s like to move from menus to content pages. Second, creating a prototype allows the graphic designers to develop relations between how the site looks and how the navigation interface supports the information design. The key to good prototyping is flexibility early on: the site prototypes should not be so complex or elaborate that the team becomes too invested in one design at the expense of exploring better alternatives.

Typical results or contract deliverables at the end of this stage could include:

• Detailed site design specification
• Detailed description of site content
• Site maps, thumbnails, outlines, table of contents
• Detailed technical support specification
• Browser technology supported
• Connection speed supported
• Web server and server resources
• Proposals to create programming or technology to support specific features of the site
• A schedule for implementing the site design and construction
• One or more site prototypes of multiple pages
• Multiple graphic design and interface design sketches or roughs

To summarize, have a plan, and make sure someone is in control. Actually, make sure whoever is in control knows a little something about everything — someone who understands enough about engineers’ code, database queries, HTML & CSS, design and usability to be able to talk the language and bridge the gaps. You need a project interpreter — someone who can collect the business requirements from a marketing executive, write up a technical requirements documentation, tell IT to stop showing off with their techno-speak, and explain to the marketing people what server log file is all about.

Otherwise, you are going to waste a lot of time and money.

technorati tags:web, design, architecture, style, guide, project, managment