I’ve been working in the information architecture (IA) space in various capacities for 20 years: first as a grad student applying biological, evolutionary, and geological theories of taxonomy to my studies of ancient Christian and Jewish texts; then working for a publisher, creating reusable, multi-channel content and building and supporting the systems that stored and delivered it; and finally, as a consultant, helping large organizations develop classification schemes for their business content to facilitate retrieval and lifecycle management.
These experiences have allowed me to be a nit-picking perfectionist, a hard-nosed pragmatist, and everything in between when it comes to getting the job done for IA projects. On the one hand, I’ve been passionately focused on achieving the highest standards in IA (cue swelling orchestra, waving flag, and F-16 flyover) and on the other, with my head hung low, I’ve been involved in duct tape and bailing wire efforts that likely did more harm than good, when all was said and done. But I’ve also been fortunate to be involved in many efforts that managed to achieve success and deliver value, without either turning the project into rocket science or a romp through every worst practice in the IA playbook.
With that in mind, I want to share my thoughts on how to find the IA sweet spot between NASA and Honey Boo Boo, as it were – the not-too-hot, not-too-cold, just right approach to IA.
The Goldilocks Principle
My approach to IA, like my approach to most things, is founded on the Goldilocks Principle, i.e. finding the right balance between too much and too little: What works for the temperature of porridge and size of beds, also works for effective IA. Figure 1 expresses the Goldilocks Principle in an infographic format.
Figure 1 – The Goldilocks Principle Applied to Information Architecture
As you can see, the two variables are the attitude of the resources doing the IA work and the cost and risk of the effort. Basically, the cost and risk of the project are tied to whether the resources doing the work care way too much about IA or not nearly enough. Typically, the kinds of folks who care way too much are dyed-in-the-wool library science types—you know, people who self-identify as taxonomists, subscribe to taxonomy list servs, and so on (guilty as charged). On the other hand, folks who don’t care nearly enough are system integrators. For them, IA is simply a box you check off on the project task list and get out of the way as quickly as possible to get on to the “real” work.
A Moveable Sweet Spot
Now that we have the basics of the principle in hand, let’s see it in action, because when we do, some interesting insights about the nature of IA work emerge.
Figure 2 shows how we might plot the cost and risk profile of a high-complexity IA project against the Goldilocks Principle.
Figure 2 – Sweet Spot for High-Complexity Information Architecture Projects
High-complexity IA projects in this context would be things like a professional association digitizing their paper library of 3 million publications for web delivery or a car manufacturer restructuring its entire parts catalog.
For these kinds of projects, you definitely want people who care way too much about IA working with you to reduce overall cost and risk. Of course, there is a diminishing return to it, so you don’t want to strive to be all the way on the left end of this continuum, but you’ll need to be pretty darn close. And you definitely don’t want to go very far toward the other end of the spectrum, because having resources who don’t care nearly enough about IA (e.g. system integrators) will be a disaster: Your metadata catalog will be inadequate, controlled vocabularies will be less than optimal, etc.
Contrast this with the sweet spot for low-complexity IA projects, illustrated in Figure 3, below.
Figure 3 – Sweet Spot for Low-Complexity Information Architecture Projects
In this bucket I would put things like migrating scanned invoices from a legacy archive to a new one, backfile scanning of purchase orders (or other simple, highly structured documents like contracts or vehicle inspection reports), etc. Typically, the IA requirements are fairly low, because you are simply taking the folder structure, metadata, doc types, and so on that are already in place, and using them whole (or nearly whole) cloth.
For these kinds of projects, specialist knowledge of IA principles and practices are not necessary, so a system integrator would be a great choice to balance cost and risk. In contrast, hiring someone who cares way too much about IA for these kinds of projects will be, best case, a long and expensive endeavor, and worst case a complete train wreck: weeks of card-sorting exercises with stakeholders, months of controlled vocabulary development, interlocking levels of metadata frameworks, 11x17 concept maps—the whole shebang—when, in the end, all you needed was to carry over PO Number, Customer Number, and Customer Name with a lookup to JD Edwards to make sure the field values were correct.
Contrast the previous examples with the medium-complexity IA projects shown in Figure 4.
Figure 4 – Sweet Spot for Medium-Complexity Information Architecture Projects
By medium complexity IA projects, I mean things like defining the IA for SharePoint team collaboration sites or for an enterprise content management (ECM) departmental repository. Basically, you’ve got to define a core set of metadata, tie it in to any existing corporate metadata frameworks, define the core document types, and design the basic site structure (site>sub-site>document library>folder hierarchy).
Now, I wouldn’t trust this to a SharePoint development shop; you’ll likely have the same issues you would for a high-complexity project. But I also wouldn’t go out and hire a best-of-breed taxonomy shop: They may very well do a great job without going overboard, but, more often than not, they’ll end up going overboard on you.
You Can’t Do It All
Figure 5 combines all three charts into one, and to me suggests that finding a one-stop shop for all your IA needs is unlikely—and exposes you to unnecessary cost and risk.
Figure 5 – Comparison of Sweet Spot for High-, Medium-, and Low-Complexity Information Architecture Projects
As you can see from the highlighted sweet spots, completing your IA project with acceptable cost and risk requires folks who fall at radically different points on the caring-about-IA spectrum. It would take a lot of effort on the part of any single provider to deliver IM projects of different complexities in the cost/risk sweet spot.
Think about it: A system integrator would need to build a practice that not only understood IA, but also when to go big and when to be more practical. And a dyed-in-the-wool taxonomy shop would need to be comfortable abandoning best practices to dumb it down for less complex projects—possible, of course, but in my experience, not likely.
The Final Word
So that’s my take on the hiring the right resources to help with your IA project. I’ve no doubt angered taxonomists and system integrators the world over who feel wrongly accused, defamed, etc., and let me close by saying that these folks do wonderful work in the IA space, but the road to IA success is also littered with the bones of many, many projects that over- or under-achieved. Hopefully this approach helps some of you out there avoid that same fate.