The following is an excerpt from an ebook I wrote with Rachel Price, User Research for Taxonomy Design. We wrote it as a companion piece to a presentation we gave at Taxonomy Bootcamp 2016, because we think there’s a lack of good information out there about generative qualitative research for taxonomy. In our book, we break it down into simple steps so you can do your own research.

As we know, part of taxonomy development is an art, and part of it is a science. The themes you’ve identified as part of your analysis should be your major touchstones as your creative mind churns on how you’re going to approach this design process, but you can also look for specific details from your themes that will inform development, in this order.

What are your taxonomies?

First, look for the axes on which users want to pivot, because these are the taxonomies you need. So frequently, a client comes to us and says, “I need a taxonomy,” and that’s fine, I can always build you a taxonomy. But really, the client almost never needs just one singular taxonomy that they already know the domain for.

So do a check here: do your users need the taxonomy you thought they did? Do they actually need more than one? Is it best to build one overarching subject classification, or several smaller value lists that users can use to triangulate in on content? If you’re not sure yet, the next question should help.

 

What kind of structure?

Next, look for how your users want to interact with the content or items the taxonomy —or taxonomies— will be used for. We find that these are easiest to remember and act on when they’re framed in terms of user goals and tell a story.

What do your users need to do? How do they need to be able to do it?

Do they want to scan a bunch of it at once and decide based on comparison? Do they want to be able to narrow in on the most specific thing? The first suggests a shallower taxonomy structure, with many items all at a leaf node. The second suggests a deeper, more detailed taxonomy, with few items at a leaf node. Neither of these structures is inherently better than the other; it all depends on what your people need.

 

What are your terms?

Finally, look for the actual language they use, because that will form the user warrant for your terms. This is the part of the exercise that most taxonomists will probably be the most comfortable with, and good notes and a thematic analysis give very deep, rich data to support all of your diction decisions. Do think about the taxonomies themselves and the structure first, though, because they may change how you these findings.

Your users stay with you

When you follow this process, you end up with a set of very concrete answers to your research questions, which, if you’ve constructed them correctly, ought to give you the information you need to design your taxonomy. It also gives you a visceral sense of how people work and what’s important to them, which can’t help but inform the design decisions you make. When one of your stakeholders proposes an idea, you can identify the ones that are right for your users, or clearly explain why that would hurt their experience. You’ll be able to definitively say,

“No, our users need to be able to get context by looking at a bunch of products, and then narrow it with facets. We can’t make them drill down to a specific category with a product taxonomy, that won’t give them the information they need.”

Or, conversely,

“For our users, more clicks isn’t worse, they’re working through a decision-making process as they navigate the taxonomy. They need to be able to get very specific, and it’s okay if it takes a minute.”

The clarity of purpose that this information gives you as you design is immeasurably valuable. The benefits are immense:

  • It gets you a faster, easier taxonomy development process (because you know what your taxonomy needs to do and who it is for).
  • It means it’s easier to resolve disagreements about the taxonomy (because you can go back to hard evidence about what people said and did).
  • It means that v1 of your taxonomy is much more likely to work (because it’s based off of real information, rather than assumptions).
  • And if your project is internally-facing, it gets you immediate buy-in (because people feel heard and like they’ve had a part in it).