Taken from a purely theoretical point of view, the point of information architecture is to connect users with content. That's why it's so important to survey the information needs of your site's users and to inventory the content assets you wish to serve: text, images, applications, databases, and so on. And you need to do this research before you begin designing the architecture.
But reality adds a third factor: For lack of a better term, let's call it corporate strategy.
It's really impossible to develop a quality information architecture, much less implement a decent site, without having a clear picture of the business model that is driving the project. It's foolish to plunge ahead before achieving understanding in these three areas:
- Vision. What is the sponsoring organization trying to achieve in general? How will the site help fulfill those goals? How will success be measured?
- Culture. Is the organization capable of centralized effort? Can autonomous units set aside their politics in order to develop and maintain a user-centered site? Has the organization pulled off such coordination before, perhaps in other media? Who will ultimately control the site's content and user experience?
- Resources. What can the organization practically afford to accomplish with the site, given that time, money, and expertise are naturally limited? Is there a single individual in place who will have both the responsibility and the authority to manage these resources and make tough decisions?
Certainly these questions are obvious ones for an information architect to ask, and the sooner they are answered, the better. But in reality, getting the answers is another story. In fact, sometimes the answers won't come from corporate strategists, managers, or directors. They'll come from a more humble source: the information architect and other members of the web team who are, incidentally, often fairly junior members of the organization. Or, in the case of outsourced vendors, the answers are coming from outsiders.
Scary, but true.
Corporate realities
Let's face it: Running a large, decentralized organization is, well. ... an oxymoron. You can't really run it; if anything, managers are fortunate if they can simply keep up with their own organizations' inertia. The world begins to move faster, the marketplace becomes more competitive. Strategies and business models are picked up, tried on, and tossed away like old Levis at a vintage clothing store. We begin to resign ourselves to the fact that reorganizations are everyday occurrences in the workplace.
|
"Designing an information architecture -- defining what an organization is, what it wants to communicate and to whom ... is ultimately about strategy."
|
Somehow, in the eye of this hurricane, managers have finally accepted the Web as something that has extreme importance to their organizations--even if they're not completely sure how the Web actually fits into their constantly shifting business models.
Which leads to an interesting and unexpected reversal: In such settings, the process of architecting the site happens before the business model is determined. And, because the architect is trying to learn about something that doesn't yet exist, it's during this process that the architect and other members of the web team are forced to make decisions that affect the business model. In other words, the architecture often defines the business model. Here's an example:
Two multinational corporations are merging. The two are based in different countries, speak different languages, espouse different cultures, and are managed with very different levels of centralization. It's not yet clear what the language (or languages) of the merged corporation will be or whether their corresponding sales and engineering divisions will continue to exist separately or not. Nevertheless, an immediate post-merger task is to unify their intranets. When the architect asks such relevant questions as,
- "How many languages should we support?"
- "What content needs to be translated?" or
- "Will the two sales forces be selling the same product lines?"
the answer is "We don't know, and we can't wait for the answers to come down from on high, so we'll have to improvise." By default, these decisions get made in conference rooms many floors below senior management's offices.
Another example: A corporation is (once again) reorganizing in response to intense market pressure. Its culture traditionally has been highly autonomous, to the point that its divisions often produce competing bids for the same projects. A new goal is to centralize and remove redundancy. One obvious way to do this is to merge the six internal R&D divisions, but it won't be easy. And, in fact, the corporate decision-maker inadvertently offloads this major strategic task by essentially issuing the command "Organize thyselves" to the six previously squabbling and, at times, competing divisions. But even more troubling is the additional edict: Begin by creating the new division's web site before the merger has actually happened.
As the site needs to represent a unified message to clients of a division that doesn't yet exist, that message gets defined during the process of architecting the site. Who the users are, what content they will need, who will manage the site, how resources will be shared, and other architectural decisions get made by a dissonant committee, not by management. And the resulting architecture's chances for success are greatly reduced if the strategic decision-makers are not involved from the get-go.
Sometimes the effect that the web team has on strategic decision-making is completely indirect, but can be just as damaging. Here's an example:
Bob, a fairly junior production person, sits on the team that is making decisions about a multinational site's architecture. Bob happens to love CGI coding. The proposed architecture uses a back-end database to allow content to be reused by the "mini sites" that will represent the corporation in different countries, helping to achieve the stated corporate goal of globalization. But this proposed approach will also reduce the need for CGI coding, so Bob fights it. If he is successful, his personal preferences for coding CGI will defeat the revised site architecture and thereby jeopardize a Fortune 500 corporation's efforts to globalize.
Grass-roots strategizing
Maybe it's not such a bad thing that control of corporate strategy is inadvertently slipping into the hands of information architects and site design committees. If we value the experience of those who work where the rubber meets the road, then a case can be made that grass-roots strategizing is often the best approach. And the exercise of designing an information architecture--learning or defining what an organization is, what it wants to communicate and to whom, and what its business model is--is ultimately about strategy. As the business world is increasingly cognizant that information is often a corporation's chief asset, why not define strategies and business models around the creation, flow, and use of information? You could certainly do worse.
And to think, you can get strategy consulting from an information architect for a fraction of what you'd pay a corporate strategist. Yet another reason to hire an information architect. ...
Flames welcome, as always, at [email protected].
