I’m sometimes faced with an awkward situation. Picture this: I’m sitting in a conference room table across from a client, and somebody will say something along the lines of “send us the IA.” That’s expectable: As an information architecture “expert,” customers reckon I will produce an IA for them. Often, that’s what they’re paying me for. Alas, IA means different things to different people. Some expect an artifact that looks like a sitemap. Others are thinking of something more abstract, like a conceptual model. Others expect something more concrete; a spreadsheet representing a taxonomy, navigation system comps, wireframes, etc.
Whatever the case, the awkwardness comes when I reply with a question along the lines of, “What do you mean by ‘IA’”? This often elicits a look of surprise. “You’re the expert!” the person’s probably thinking. “Why don’t you tell us what we need?” Indeed, this is often what I must do — figure out what the project needs, and then work to provide that as thoroughly as possible within the project’s constraints. However, there are always expectations that must be met. Knowing what those are upfront helps.
The issue is that information architecture sits higher up in the ladder of abstraction than most people expect. Broadly, IA aims to clarify the distinctions between parts of an information environment and the relationships between them. People most often experience these distinctions in websites and apps through the options in their navigation bars. But these aren’t the only means of doing so. IA also affects other aspects of the project; people in various roles need to understand how it impacts their particular domains. A developer has very different needs than the VP of products. Each needs to look at the implications of the IA for the area of their concern. This calls for various means of expression at different levels of fidelity. A high-level sitemap may be appropriate for the VP, while a developer expects something more granular.
This issue is not unique to information architecture. Consider another area of creative work that’s higher up the ladder of abstraction than people expect: music. Imagine a composer is brought in to create the music for a movie. “Send us the music,” the producer says. What does she mean by “the music”? Is she expecting a score? An orchestral performance? A recording of an orchestral performance? “The music” is quite an abstract idea! The composer may have expectations of what the appropriate level of granularity should be based on prior experience; he may even suggest a means of expression he believes will suit the work. Still, it behooves him to check in with the rest of the team to ensure everyone’s expectations are aligned.
Ultimately, the needs of the project must be met. This often requires going beyond what’s being requested (or expected, even if it hasn’t been requested) and may sometimes call for reframing what other team members understand by information architecture. In any case, an open, collaborative approach to the development of the information architecture is required. Ironically, the “you’re the expert” perception may stand in the way of open collaboration. Successful engagements call for a balance between rigor and flexibility; achieving this balance often requires that the “expert” make him- or herself vulnerable in service to the needs of the project and its stakeholders.