 | Information Architecture for the World Wide Web |  |
The information architect must communicate effectively with the web site development team. This is challenging, since an information architecture is highly abstract and intangible. Besides communicating the architecture verbally, documents (such as blueprint diagrams) must be created in ways that can be understood by the rest of the team regardless of their own disciplinary backgrounds.
In the early days of the Web, web sites were often designed, built, and managed by a single individual through sheer force of will. This webmaster was responsible for assembling and organizing the content, designing the graphics, and hacking together any necessary CGI scripts. The only prerequisites were a familiarity with HTML and a willingness to learn on the job. People with an amazing diversity of backgrounds suddenly became webmasters overnight, and soon found themselves torn in many directions at once. One minute they were information architects, then graphic designers, then editors, then programmers.
Then companies began to demand more of their sites and, consequently, of their webmasters. Simple home pages quickly evolved into complex web sites. People wanted more content, better organization, greater function, and prettier graphics. Extensions, plug-ins, and languages proliferated. Tables, VRML, frames, Shockwave, Java, and ActiveX were added to the toolbox. No mortal webmaster could keep up with the rising expectations and the increasing complexity of the environment.
Increasingly, webmasters and their employers began to realize that the successful design and production of complex web sites requires an interdisciplinary team approach. An individual cannot be an expert in all facets of the process. Rather, a team of individuals with complementary areas of expertise must work together. The composition of this team will vary, depending upon the needs of a particular project, available budget, and the availability of expertise. However, most projects will require expertise in marketing, information architecture, graphic design, writing and editing, programming, and project management.
The marketing team focuses on the intended purposes and audiences for the web site. They must understand what will bring the right people to the web site and what will bring them back again.
The information architects focus on the design of organization, indexing, labeling, and navigation systems to support browsing and searching throughout the web site.
The designers are responsible for the graphic design and page layout that defines the graphic identity or look of the web site. They strive to create and implement a design philosophy that balances form and function.
Editors focus on the use of language throughout the web site. Their tasks may involve proofreading and editing copy, massaging content to ensure a common voice for the site, and creating new copy.
The technical designers and programmers are responsible for server administration and the development or integration of site production tools and web site applications. They advise the other teams regarding technology-related opportunities and limitations.
The project manager keeps the project on schedule and within budget. He or she facilitates communication between the other teams and the clients or internal stakeholders.
The success of a web site design and production project depends on successful communication and collaboration between these specialized team members. A linear, black-box, throw-it-over-the-wall methodology just won't work. Everyone needs to understand the goals, perspectives, and approaches of the other members of the team. For example, while the marketing specialist may lead the audience analysis process, he or she needs to anticipate the types of questions about the audience that the specialists will have. Otherwise, each will need to start from scratch in learning about that audience, wasting substantial time and resources.
For the information architect, communication is a special challenge because of the intangible nature of the work. Anyone who has played Pictionary knows that it is much harder to draw an abstract concept such as science than a physical object such as moon. As an information architect, you face the daunting challenge of helping others visualize such abstract concepts as a metaphor-based architecture and indexing systems.
The information architect has to identify both the goals of the site and the content that it will be built on. This means getting the people who drive the business, whether bosses or clients, to articulate their vision of the site and who its users are. Once you've collected the data and developed a plan, you need to present your ideas for an information architecture and move the group toward consensus. All in all, this significantly burdens the architect to communicate effectively.
This is the point of the rest of this book. The next four chapters introduce the foundations of information architecture to support your efforts to communicate an information architecture by providing useful terms, definitions, and concepts. Chapter 7, "Research" through Chapter 10, "Information Architecture in Action" provide a framework for these communications, and for the role of architecture in site development as a whole.
|  | |
| 2.2. Who Should Be the Information Architect? |  | 3. Organizing Information |
Copyright © 2002 O'Reilly & Associates. All rights reserved.