Creating a controlled vocabulary can be a puzzling experience. But, like all puzzles, the collective pieces that define the domain of information architecture for the Web are destined to be solved. I’d like to update you on the DSIA glossary of information architecture terms in this post.
I find it necessary to document a vocabulary on the topic of information architecture as a way to improve my ability to build concepts, interpret and vet existing ones, and then logically connect those concepts across the theory and practice I’ve been developing over the years. Ultimately, a controlled vocabulary helps to improve communications about a subject domain.
The DSIA glossary is rather unique when compared to existing IA glossaries because many of its terms derive from new IA subject matter I’ve been exploring. However, convention is not lost—amongst the newly minted terms are familiar terms as well. Below is a list of several terms that were recently added to the DSIA public glossary. You can click any term to view their definition on this page.
- Boersma Assertion
- Content Model
- Entity
- Information Architecture (Work Product)
- Koltay Assertion
- Shirky Assertion
- Taxonomy
Three Information Architectures and Counting
It’s worth noting that there are three entries in the DSIA glossary for the term information architecture. The most recent definition was released due to my latest UXmatters article, Creating a Web-Site Information Architecture in Six Steps, which discusses information architecture as a work product.
In previous articles, I intentionally referred to information architecture as a practice, as in a set of unique interests and activities that help promote discipline. In the article, Creating a Web-Site Information Architecture in Six Steps, I decided to advance my usual conversation beyond practice and discuss how to actually create the information architecture work product that happens to carry the same name as the practice that makes it all happen! Herein lay the semantic conundrum, where the term information architecture is used to describe multiple things.
Taking on the challenge to clarify the sense of the term information architecture when it can be used to describe multiple concepts can be achieved through a thoughtful exercise of disambiguation.
Disambiguation can be described as an effort to remove the uncertainty of a word or phrase that is used in two or more possible senses or ways. Merriam-Webster describes it as an effort “to establish a single semantic or grammatical interpretation.”
Similar to what you may see on Wikipedia, the DSIA Research Initiative qualifies the meaning of terms by placing contextual phrases within parentheses shown next to the word that requires disambiguation. For example, below are the three unique DSIA definitions you’ll see for the term information architecture. Disambiguation for each instance of the phrase embodies a unique context and meaning.
- Information Architecture (Business Function) – The organizational function responsible for simplifying how people navigate and use information on the Web
- Information Architecture (Practice) – The effort of organizing and relating information in a way that simplifies how people navigate and use content on the Web
- Information Architecture (Work Product) – The assumptions and governing constructs for assigning properties and attributes to information and the endowment and evolution of information relationships over time within a given domain; a governing model for information behavior within a digitally mediated environment.
While these three definitions appear unique, they are fundamentally the same—differentiated only by a level of technical disclosure that’s tuned for specific audiences.
Not New. Simply Unfinished.
To explore what we mean when we say “information architecture” is not a new idea. It’s been tried many times in various ways. However, most attempts seem misguided by the omission of context.
Andrew Hinton was one of the first practitioners to publicly suggest that it is “helpful to be clear on the distinctions.” However, he was referring to the “IA” label. In a 2008 IA Summit plenary presentation titled “Linkosophy,” Hinton observed how the IA acronym was a label for multiple ideas such as title, practice, role, activity, and thing. Even though Hinton did not set out to formally define information architecture in his presentation, he inadvertently exposed concepts that future definitions would have to consider.
Figure—1 Uses of the IA label observed by Andrew Hinton
| Title | Label one can be called, whether or not their work has anything to do with the thing, practice, activity or role. |
| Practice | Shared history of learning among people who affiliate with the role. |
| Role | The ‘hat’ for the person performing the activity on the thing at the moment. |
| Activity | The actual work of designing the “thing.” |
| Thing | The designed ‘stuff’ itself. |
At best, the history of defining information architecture can be summed up as a formidable effort that has been given the not-so-flattering acronym DTDT (Defining The Damned Thing). Yes, it’s natural to struggle over definitions in a maturing profession. However, we’ve been doing this long enough. I think it’s time we do away with the excuses.
It’s been apparent, at least since Linkosophy, that we must abandon the idea of a single definition of information architecture and pursue what has to be multiple definitions that apply in various contexts. Currently, the DSIA glossary is the only IA glossary available that disambiguates the information architecture term.
Individuals who take on the challenge of defining information architecture must recognize that ambiguity sits at the heart of this prolific task, so much so that the effort to disambiguate is just as important as the definition that follows. Hence, any attempt to define information architecture without qualifying the sense of its use will fall short of clarity and do more harm than good. Case in point, many writers—from critics and skeptics to passionate practitioners and storied pioneers—offer to educate audiences by defining or explaining information architecture but do so by conflating practice, role, and title in the process. Disambiguation at the outset would limit the discussion to only one of these since they are all unique concepts.
Defining Our Future
The realization of a robust discipline of information architecture remains in jeopardy if we fail to mature an actionable language of discourse that’s relevant to solving real problems. If you’re a practitioner, I encourage you to seek and demand clear definitions. Demand clarity from industry organizations and those claiming to be practitioners of information architecture. Or, if you see an opportunity, take a shot at crafting your own definitions. If you do, share it for the sake of progress. Maybe you’ll be the next person to help us move the information architecture dial one notch closer to clarity.
Continue to visit the DSIA Portal of Information Architecture and the DSIA Glossary as we seek to expand and improve our IA vocabulary.
No responses yet