Information architecture is the science of figuring out what you want your site to do and then constructing a blueprint before you dive in and put the thing together. It’s more important than you might think, and John Shiple, aka Squishy, tells you why.

Squishy first looks at how to define your site’s goals, shedding light on the all-important art of collecting clients’ or co-workers’ opinions and assembling them in a coherent, weighted order of importance. He also shares his scheme for documenting everything so that all parties can keep up.

The next step is figuring out who the heck your audiences are going to be. Once that’s out of the way, you can start organizing your future site into pages of content and functions that the site will need to have.

Next, Squishy gets into creativityland, where you start to build the beast:form a skeleton, pick your metaphors, map out your navigation. Then it’s time to break out the graphics program, come up with layout grids, design sketches, and mock-ups, and get ready to build!

Suggested readings

The web server cannot find the file or script you asked for. Please check the URL to ensure that the path is correct.

Please contact the server’s administrator if this problem persists.

Ha! I bet you thought this page wasn’t here. Ha ha! Hooo! Yeah.

That 404 message above is familiar enough to most people to stimulate a Pavlovian click of the Back button. Which means it’s doing its job. 404 Not Found is the most famous of the HTTP status codes. These status codes are three-digit responses that an HTTP server returns when given a request. These codes fall into three series:2xx, which means success, 3xx, which means partial success (redirection), and 4xx/5xx, for errors on the part of the client and the server respectively. Some highlights include 200 OK, which is the most common, but rarely seen in the flesh — it just means everything worked; 401 Unauthorized, when HTTP authorization has blocked a request; 500 Internal Error, when the server somehow couldn’t provide the requested page. 404 is the one that pops up when the client asks for a page that isn’t there.

So what does your average web surfer do when she hits a 404 page? At best, she trims the URL layer by layer until she finds what she’s looking for, or returns to the home page and searches. At worst, she goes elsewhere and never returns to your site.

Either way, 404s represent a major bleed-off of traffic and source of user frustration, which, as hospitable web providers, we want to do our best to avoid. So what can be done?

Why’s Information Architecture So Important?

Information architecture (also known as IA) is the foundation for great Web design. It is the blueprint of the site upon which all other aspects are built – form, function, metaphor, navigation and interface, interaction, and visual design. Initiating the IA process is the first thing you should do when designing a site. This series of articles describes specific methods and processes for developing a site’s information architecture.

Clients sometimes view the development of an IA to be impractical, both in terms of the time it takes and the skill needed to do it effectively. But this mentality is slowly changing. A good IA is incredibly effective, and knowing the basics of the IA process can save both time and money in the long run. Also, you don’t need to be an expert to use it to your advantage.

This series will demonstrate how easy and powerful the IA process can be. We’ll present two ends of the design continuum, which can be thought of as either the difference between developing a small and a large site or the difference between having little time and having lots of time to design a site.

Each article presents a portion of a design document. Upon completing this series, you will have the template for a complete IA design document; the record of the decisions made in designing the site. It serves as a road map for the site’s construction. Additions and revisions are made easier by the presence of this document. Oh, yeah – and clients and management love this stuff.

Also, just about everyone these days is a proponent of ease-of-use. Well, ease-of-use starts here. It’s practically guaranteed if you have a solid information architecture at the outset.

Define the User Experience

After figuring out why a site should be built, the second most important aspect of designing information architecture is determining who the audience is. This is an invaluable step that many people fail to grasp. Many sites do not even take into consideration who will be using them. How can you design a site if you don’t know who’s going to be seeing it?

Some people think an audience is defined by the technology it uses to access the site. This, too, is missing the point. That a user visiting the site uses a 28.8 modem is only a small part of the audience definition. A true audience definition consists of who the users are and their goals and objectives. Scenarios, or stories, are useful in visualizing the audience.

Oftentimes, a single department or group in a company takes the lead in putting together a Web site. The result is usually a site focused on that group’s needs, which ignores the needs of everyone else. For a long time, MIS departments were responsible for putting together their corporate sites. These sites were utilitarian, and neglected important departments, like marketing. It is your job to prevent this from happening on your site.

Defining beforehand the user experience you seek establishes a clear, well-documented definition of your audience, and it helps in understanding how users will react to the site.

To get started on this stage of the IA process, just as with defining the goals, you need to figure out who will be involved and how much time you will have. Generally, the same people will be involved. However, you probably will change how you weigh each person’s opinion. For example, the marketing department should have a good idea of who your audience is. If that is the case, you’ll want to listen to them more than to others.

Defining the audience takes less time than defining the goals, because you have already established how you will be working with people – whether formally or informally – and you are more familiar with asking them questions and getting responses.