Summary: A top-down approach is not always the right tactic, and purpose-driven, bottom-up activities have a place at the taxonomy table.
Taxonomy, a topic I just don’t seem to get tired of discussing, keeps coming up in my professional life—with clients, in workshops, in discussions with peers, and recently, in-house at TUG. Driven by a desire to get everyone on the same page when it comes to how we discuss our activities and deliverables internally and externally, I’ve been trying to wrangle the TUG team to start the discussion about creating an official TUG taxonomy. Eating our own dog food. Like a cobbler making his own shoes. You probably have heard all the aphorisms.
I started this journey with the end already in mind: a top-down, mutually exclusive set of buckets and associated, agreed upon nested terms.
Image 1: What I thought we wanted: Traditionally Structured Top Down Taxonomy
Our first attempt at discussing our needs, direction, and eventual outcomes for the TUG taxonomy, resulted in a harvest of great thoughts and piquant questions yet yielded absolutely no structure or tangible taxonomy. This was fine and apropos for the minds of our team members—who can delicately balance chaos and simultaneously begin the quest for structure—but was infinitely more frustrating for me. Being a linear-thinking, structure-and-process junky, I was frustrated in our inability to come together and just, you know, architect our taxonomy!
I had to step back and laugh at myself. What a great opportunity to deepen my empathy for our clients, many of whom must feel this same way from time to time in matters of taxonomy. “One does not simply CREATE a taxonomy” was a joke flying around the Ann Arbor studio after our initial conversation. There really is a ton of research, thinking, and debate that can go into making these structures, and coming in demanding a top-down taxonomy where there has been none to date is probably not incredibly effective, especially if there is no vision or clear purpose for the generation of said structure.
Creating this taxonomy is of relatively serious import for TUG. As our firm is somewhat redefining information architecture—how it’s communicated, how it’s used, how it’s defined—we all have skin in the game. Our taxonomy isn’t JUST a taxonomy: it will really need to define our collective philosophy, mission, and goals and will end up being a reflection of both who we are and who we want to become as practitioners. I’m sure this is not an issue germain only to The Understanding Group, but to all companies redefining themselves or the spaces in which aspire to exist.
In a subsequent conversation with Dan Cooney, I vented my frustrations, confusion, and asked his advice. Dan shared three pieces of sage wisdom:
1. Taxonomy needs to have a purpose: It wasn’t clear to him what the purpose of our taxonomy need was. Was it to drive the overall business strategy? Was it to improve our communication with clients? Was it to improve internal communication? Was it to improve quality of the work we do? I thought I had made our purpose clear within the group, but apparently had not. Dan encouraged me to think about framing taxonomical needs within an immediate purpose to help all invested stakeholders have a focused vision.
2. You can drive to Chicago at night without seeing anything outside of the headlights, and that’s fine: This concept confused me at first. Turns out Dan was referencing this E.L. Doctrow quote: “Writing is like driving at night in the fog. You can only see as far as your headlights, but you can make the whole trip that way.” What Dan was getting at was the idea that, as in writing, when creating a taxonomy you don’t necessarily always need to understand the entire problem space (ie: see all the roads to Chicago or create an entire corporate taxonomy) to solve the problem at hand (i.e.: get to Chicago tonight, create a section of taxonomy or controlled language to solve an immediate organizational problem). This was another way of him encouraging me to see our internal TUG taxonomy discussion not as a top-down master taxonomic solution, but perhaps to approach it as smaller, bite-sized chunks.
3. It’s ok to start with little chunks at a time when you’re building something big: Dan pointed out my proclivity to approach a lot of structural things from the top down, and how working from the bottom up might be helpful in this taxonomy creation—especially in an unknown or emergent product space. While top-down definitely has its place, sometimes bottom-up is more useful or practical given time and resource constraints. Even Google did this, and in fact, it’s what has probably made them so likely to achieve their goal of becoming “One Beautiful Google”. If they had started with some sort of product taxonomy and worked down to fill in the blanks instead of allowing the parts be what they need to be (while still adhering to company design and ethos parameters), would they have the robust product and service offerings they have today? No, probably not, but now that those products are there, they can work on unifying their universe to bring them together cohesively.
After some thinking, I took this away from my conversation with Dan:
In instances where resources are limited, scope is not yet defined, or the strategy is not yet firm, consider creating purpose-driven controlled vocabularies or smaller section specific taxonomies. Eventually, they will lend themselves to being woven into in a comprehensive, purpose-driven master taxonomy, when the structure actually needs to be there.
Though this might seem like common sense to some of the more advanced taxonomists or systems thinkers out there out there, to me, it was a massive mental shift. I had to trade in my top-down thinking for a bottom-up approach.
Approaching this taxonomic problem internally going forward, we are going to shift the approach to creating smaller controlled vocabularies that solve an immediate business or organizational need, one group at a time, instead of trying to rig up a master taxonomy for the sake of structure alone that didn’t actually address any of our organizational issues [See Image 1 for a comparison].
Image 2: What I realized we needed to do: Create smaller purpose-driven clusters before building the master taxonomy
During these exercises, we are going to focus only on the problem at hand, and not get too worried about the larger structures, knowing they are happening organically in their own problem spaces. Eventually, when there are enough pieces that necessitate the relational structure that a taxonomy so valuably adds, we will have high-quality near term source material from which to derive this larger, more structured and hierarchical taxonomy. Time will tell if this is the ideal approach, but a hunch—and some of the world’s leading IAs on our team at TUG—tell me it is, for us, at this moment.
This is something other organizations who are thinking about creating a shared language across multiple users, situations, and contexts may find worth considering. Is it really time for the structure of taxonomy, or should there be more focus on honing those smaller, purpose-driven controlled vocabularies first? Do we have the parts, have we identified the problems we need controlled vocabulary to solve, and is it time to tackle the whole? Do you really need to see the whole map to get to Chicago tonight?
I’m not prescribing one over the other by any means—as I mentioned top-down and bottom-up both have advantages. In fact, I’m pretty sure a combo of strategy-driven, top-down and purpose-driven, bottom-up approaches in concert with one another, will probably end up being the ideal path for taxonomy creation at TUG. Like most things in information architecture, the correct approach has much more to do with the context, the constraints, the culture, the purpose, and the people it’s serving than prescribing to any one approach. The question organizations would do well to consider in taxonomy creation is this: does your desire for structure have a purpose and an audience, or are you creating structure for structure’s sake? Or, as we say frequently at TUG—avoid jumping to the How until you’ve adequately framed the Who and the Why.