The Age of Information Architecture

In: Columns > IAnything Goes

By Jeff Lash

Published on August 20, 2002

This month’s issue of Digital Web focuses entirely on information architecture, and this is the first monthly column titled “IAnything Goes” which will address information architecture on its own.

What’s the big deal here? Why is IA important? If you don’t care about IA, why should you?

In the beginning, there was the webmaster

Let’s look back to the initial growth of the web, from 1994 until 1999 or so. Most people didn’t know anything about the Internet, and if they did, they were probably just learning. Many sites didn’t have a defined purpose, they were just experiments and hobbies. Businesses were trying to use the web to their advantage, and, in many cases starting to succeed.

The people who were building the sites were learning as they went. There were no degrees, certifications, or formal educational curricula. Careful study of online HTML tutorials and the purchase of a Visual Quickstart guide was the typical description of a web designer’s skills and experience.

Needs were fewer, both on the business side and the employee side. Not many people knew how to make web pages, and businesses were competing to hire any viable candidate. In many cases, knowing how to make a CGI form work and lay out pages in Illustrator made you a hot prospect.

Businesses started realizing that “this Internet thing” might be more than just forwarded jokes and dancing cartoon characters. Companies that specialized in web design were started, and existing companies that specialized on everything from marketing research to annual report design started augmenting their services with web design and development. “Old economy” businesses were infiltrated by “rogue” intranet sites or supplemented with extranets to assist with partner relations. The Internet was becoming so big that it wasn’t just part of business–it was its own industry.

Specialization across the nation

With the explosion of web jobs came multitudes of workers entering the field, and the “webmaster” role–one person in charge of everything–was supplanted by 1999 or 2000 by larger web teams with more specific and stringent requirements. The same “web developer” job posting that asked for CGI and JavaScript (easily learnable on your own) was now asking for several years of experience with Oracle, Java, and C++, and instead of competing with a handful of other candidates, there were dozens or even hundreds of others.

Those “web builders” who had for so long straddled the line between visual style and programming were in a crux. Their main selling point–experience with a variety of different skills from design to copywriting to coding–was useless as they competed with more candidates who were increasingly specialized. Without the BFAs that design jobs required, or knowledge of the multitude of languages needed to be a “developer,” many turned to related specific subdisciplines into which their generalism could be expanded. These were areas that blended design and technology, without getting too heavy into either–things like accessibility, content management, CSS, web standards, technical writing, usability, and–you guessed it–information architecture.

The choice of a new classification

This is not to say that information architects are the leftovers, the bottom of the barrel, or the lost souls who could find no other home. This path actually makes a lot of sense. For the most part, information architects are communicators and strategists. While others merely tolerated the mishmash of responsibilities, they relished it. Designers often put up with having to write HTML but jumped at the chance to “just do design.” Programmers were forced to meet with clients and work on strategy, but all along probably wanted to just write code. When these two ends of the spectrum split off, the empty middle was a perfect place to be.

At the same time, there was an increased (but still hidden) need for information architecture. As the average web project process matured, more problems arose. Formal documentation was needed, business objectives were taking on increased importance, and, as the size increased exponentially, information organization became a much more important role. (The fact that this evolution took place during the “dot.com fallout” is not insignificant, as this led to the placement of web projects under the same microscope as other business endeavors.) Some of these positions could be filled by existing disciplines; project managers, business analysts, and usability specialists transitioned from “traditional” work and were added to web teams. Still, there was something missing. The connection between “the big picture” (business strategy, high-level user tasks, basic structural architecture) and the nitty-gritty (categorization, labeling, bottom-up information hierarchies) often wasn’t being made. This is where information architects fit in.

Not all information architects came out of the “falling between the cracks of design and programming.” Library science was the foundation for Argus Inc., who didn’t coin the term but put it in perspective for the web era and are to thank (or blame, depending on your view) for the current definition and emphasis. Visual design, usability, communication, psychology, architecture, business, and computer science are other common backgrounds for those interested in information architecture. That doesn’t mean that it is unstructured or haphazard; this diversity and interest in all of the interlocking elements is exactly where information architecture draws its strength. One of the more recently proposed and accepted definitions of information architecture, in fact, is Users + Context + Content = IA (credit: Lou Rosenfeld with help from Jess McMullin), which accepts and extols the fact that information architecture draws from many sources.

Bringing back the generalists

In many cases, though, it is not possible to have one person whose job description is based upon information architecture. The project manager may have to nail down the site goals, the code jockey may have to develop the sitemap, the designer may have to test the interfaces and the developer may have to optimize and fine-tune the search functionality. While the role of “information architect” has drawn much attention, the power is in the idea of information architecture and the application of its principles by everyone on a project.

While having a dedicated information architect is nice, a situation where one or more information architects are working on a project and incorporating IA concepts throughout the project with the help of everyone involved can magnify their positive impact on the final results.

Jesse James Garrett’s ia/recon–part 5 especially–does a wonderful job of explaining how “the future of information architecture is in [non-IAs] hands.”

It should not be the case that the information architect creates a wireframe, for example, without consulting the visual designer, just like it would be irrational for one to create a sitemap without confirming the scope and priority with the project manager and business analyst. The benefit of a focus on information architecture can only be achieved by integration and acceptance of its importance throughout the project.

Show me the–well, you know…

And what are the benefits of effective work on information architecture? Well, it depends on the project and objectives–but things like reduced development time, reduced maintenance cost, increase in visitors, increase in visitor time spent on site, improved actual and perceived usability, reduced time to accomplish tasks, increased sales and better alignment with the underlying business are common. Information architecture helps make sure that business needs and user needs are met, leaving everyone happy, and isn’t that really what it’s all about?

It’s no wonder, then, that there is increased interest in information architecture. Individuals who can supplement their technical skills with solid understanding of business strategy, information organization experience, user-centric techniques and critical thinking make much better candidates for prospective employers, and much more effective employees. Businesses who realize the importance of information architecture can realize cost savings, improved organizational efficiency, improved communication, and increases in revenue.

Gone is the short-lived environment where web projects were chosen based simply on the e-appeal to investors and coolness of the underlying technology. ROI is now used just as often as RDBMS, and user needs can no longer be disregarded by citing of the first- or only-mover argument. Organizations and individuals realize the benefits of information architecture, and those who are equally adept at formulating the big picture strategy (top-down IA) and digging deep to implement the proper solutions (bottom-up IA) will be the ones who benefit.

So where does this column fit in? Well, hopefully you’ve seen the benefits and value of information architecture. The next step is to actually do it. This month’s IA-focused issue of Digital Web is a great place to start, and there are plenty of other resources available online. Of course, that’s what this monthly column is meant to do: describe practical approaches to information architecture and related concepts.

• Add to Magnolia
• Add to My Yahoo!
• Add to Newsvine
• Digg this story
• Add to Del.icio.us

Related Topics: Information Architecture, Technology