Effective Information Architecture

By Popi Kleinman, Fundación Ambiente y Recursos Naturales (FARN)
May 2001

An information architecture (IA) is effective when you, as a Web site administrator, can meet your goals and reach your intended audience. The needs of the user and that of the administrator are not always the same, but if you can find the points where those needs overlaps, and build your IA to satisfy those common needs, then you'll have an effective architecture.

Let's put this into a realistic situation. You probably work in an organization that doesn't have the resources to acquire the technology to facilitate your maintenance tasks, and you probably do other work on top of Web site administration. Not only do you have a lot of information that the user wants to find easily and quickly, but you also want to be able to easily maintain and update your Web site. IA is your main weapon, your main tool, to meet all of these objectives.

Effective IA facilitates your work as an administrator, and helps users find what they're looking for quickly and not get lost within the site. On the other hand, if your IA is not effective, you will probably lose control of its growth and suffer several headaches. Your audience may feel confused when navigating within your Web site, and if they get lost or don't find what they were looking for, they won't come back to your Web site, making all your efforts and time done in vain.

Every situation is particular and all content different, so decisions you make to achieve effectiveness will vary on a case-by-case basis. However, there are some general values that you can keep in mind when building your Web site to help you achieve effective IA.

Simplicity
Users don't like to put effort into trying to understand the logic of your Web site to find what they want. They want to arrive at your site and easily find what they're looking for or where to continue the search. Complex Web sites with too many deep branches and pages that reach dead-ends will turn people off and away from your site. So be as simple as possible, for you and for your audience.

Usability
Usability is defined as "the effectiveness, efficiency, and satisfaction with which specified users achieve specified goals in particular environments." A usable Web site is easily navigated. Take advantage of the non-sequential characteristic of the Web to provide easy access from any part of your site to any other.

Functionality
The functionality of your Web site is its capacity to perform according to your objectives. Functionality may or may not be easy. In some cases, you may need to set up a database to manage large volumes of information that can not be easily put into a simple index or table of contents. Thinking about functionality is thinking about what works best for each type of information that you need to upload.

Following is a list of questions to help you decide where to place information/documents/data:

• Is your content static or will it be updated frequently?
  In general, the variability of the information will determine where it will be placed on the site. If the information needs to be updated regularly, it is normally placed on the first level of the site. In other words, a calendar of events, that is frequently updated, is best placed at the front, accessible from the home page and not from within another section (e.g., sections could be About, Activities, Resources and Calendar of Events). On the other hand, static information such as mission, staff, background, etc., can be grouped and placed within the same section.
• Does the information include a fixed date?
  Sometimes information about conferences, seminar, courses or other events need to be put online but have fixed dates. This type of information, that has a short life line but is important, should also be made accessible by being placed at the front. However, because this information is temporary and eventually removed, don't place it where you will leave a hole in your site once it's gone.
• Is the content a resource or tool for the user?
  Feedback forms, help guides, sitemaps, search engines, etc., are designed to assist and facilitate the user. In general, this type of information should be accessible from all pages, or in the case of help guides, from all main sections.
• Should your site mirror the structure of your organization?
  It is not always necessary to stick to the structure of your organization. Sometimes copying the internal structure for the Web site structure makes a site ineffective and diminishes the accessibility of the information. For example, if a department or program in an organization publishes a document and it is therefore placed within its section (say Programs/ProgramEnviro/PublicationX), the user will have a hard time finding it if they're unaware of the structure of the Organization. In this case, it's better to have a section entitled "Publications" that unites all publications produced by the Organization, as well as having the document accessible from within the specified program. The above is also true for certain resources produced or maintained by internal departments of the organization, such as databases, newsletters, bulletin boards, etc. Depending on its importance and frequency, this information should be easily accessible instead of having the users search through various programs to find it.
• When do you need to create a database? And when is a table of contents sufficient? The volume or quantity of the information will determine how it could (or should) be organized. In the case of publications, there are organizations that have few references online that can be placed as internal hyperlinks. When the number of documents begins to grow, it becomes necessary to place them within their own section with a table of contents or list of publications (organized by date, title, author or theme). If the number of publications increases to the point that this method is confusing or unmanageable, it is time to create a database with a search interface. This last option requires some technical knowledge or specific program that will depend on the resources (both technical and financial) of the organization.

SD Case Study

Considerations in FARN's Information Architecture
While the FARN site largely mirrors the organization's management structure, some consideration was given to breaking this pattern for special online modules of interest to their users.