User-Centered Information Architecture

Originally, most projects focused only on business requirements and did not even take into account user needs. The goal of projects was to meet the functional requirements that the business demanded. It didn't matter if people did not understand how the interface worked, or what the categories were called. Users received extensive training, were forced to learn on their own for their job, or weren't given a choice due to lack of competition. Systems were difficult to use, lacked necessary features, and didn't help users get the information they were looking for.

As usability and information architecture started to gain prominence, the scales started to move in the other direction, sometimes too far. The cult(ure) of usability made people disregard the business aspects and throw their full faith in the users. This led to decision paralysis, where no decision could be made--no matter how small--without donning the white lab coat and testing it on the users. What is good for the user, however, is not always good for the business. Users were happy, but businesses failed. Of course, the opposite is true as well - incredibly successful businesses that continuously find ways to piss off their customers (Microsoft comes to mind).

Middle Path

Can a happy medium be reached? How does one temper user-centric tendencies with a concern for the business?

Lou Rosenfeld recently addressed the question, "Can two or more entities have identical or nearly identical information architectures?" The basic answer was, well, they can, if they have the same type of content, the same types of users, and the same business context, which is a fancy way of saying theoretically "yes," but realistically "no."

His example showed how the differing business models of two similar companies--Gateway and Dell--contributed to their different site architectures. Gateway sells through retail outlets, whereas Dell's business relies on the factory direct model. It's not just the business model that impacts the architecture of the site, though. Two sites with the same basic business model could still have different information architectures. The major factor that influences the design from the business side is the business goals for the site. This is just as true with the different information architectures of Gather and MySpace; Different users, different businesses, different structures.

Using the example of two hypothetical computer manufacturers... both may be trying to sell low-cost computers to a general consumer audience. They both may direct all sales through their Web site, and sell the same basic models and options.

Their organization schemes and labels, however, depend on the business goals of the site. One business may want their site to encourage add-ons (scanners, printers, digital cameras) to meet the goal of increasing the price of the average sale. The other may not care about add-ons but focus on selling extended warranties and support plans to meet the goal of creating recurring revenue. These are two similar companies with two similar business models and two similar user groups but two very different business objectives for their sites. Their sites should be designed accordingly.

The problem is that, many times, there are no defined business goals. A goal of getting the site up and running--that is to say, to have a Web presence, no more, no less--as quickly and cheaply as possible may be the closest thing to an actual business goal that is attached to a project.

The responsible information architect should never begin a project unless they understand what the business goals of the project are. If the goals aren't defined, it is the information architect's job to work with the business so that the business goals of the project can be determined.

Well-defined business and user goals are essential to the success of any project, and the establishment of those goals before the project begins helps you achieve the most elusive of all tasks: proving your value as a professional.

There is an ongoing struggle in the IA community to "monetize" IA or prove the ROI (Return On Investment) of our work. People complain that it's not possible to show the value of IA. It's only impossible if you don't know how you're measuring the value, and that's where business goals come in.

You need to establish and understand business goals, and meet those goals by understanding the corresponding user needs. If you can meet those business goals, you can prove the value of IA without undue complications.

The skeptics will argue that it is impossible to separate information architecture's contribution from the contributions of all of the other Web-related disciplines, and I won't argue with that. No one questions Java Server Page production's contribution to the site's ROI, and server administrators are never asked to "monetize" their efforts. If the business goals are reached, everyone should be judged as successful.

To borrow an example from another (somewhat related) industry: a common saying is that half of all money spent on advertising is wasted, and the trick is just figuring out which half. An advertising campaign is deemed a success if it meets is goals. No one questions whether the media planning proved its ROI, or whether the color scheme was "monetized." There may be a project postmortem or after-action review where each individual element of the project is analyzed, and suggestions for improvement are offered, but involvement in a successful project is usually indicative enough of a worthwhile contribution.

Using information architecture to meet business goals by focusing on user needs not only proves your professional worth, but makes users happy and helps businesses succeed--something that wouldn't be possible by a focus on users alone.

Information architecture goes beyond deciding what content should go where and how it should be labeled. It's more than just blindly listening to what users say. It's more than just making the client happy. Giving all of your attention to only one of these three aspects of account service is irrational, irresponsible, and impractical. The key to successful information architecture is understanding all of the variables involved in meeting project goals, and coming up with an appropriate balance. Balance is the key. Balance is the I-Ching of Website Architecture.