Developing Taxonomies
Overview
In a previous post, I dived into identifying the value that having a shared language, such as a taxonomy, can bring. In sum, we’re looking for:
Ease of use and findability for users
Gains in operational efficiency through common understanding
Readily available data insights
The next step would be to develop taxonomies that help us realize these benefits. As previously noted, I identified the taxonomy needs so let’s go through each to see how they could be used.
Website Structure
From a consumer perspective, the website structure is, in some form, the taxonomy of interacting with your business. There are a few different ways to go about it, and there’s not really a “wrong” way to do it. But, sometimes there is a “better” way to ensure the website matches expectations and interaction. A website should flow logically, almost intuitively.
Thinking about why the website even exists should simplify things for you. In my case, this is simple. I’ll be using it for:
Content Hosting - LDL content, educational pieces, maybe the occasional rant. This section informs the user about something.
Resources - Things like playbooks, data sources. This section enables the user to do something.
Projects - Data Dashboards, etc. This section shows the user tangible accomplishments.
So, I’ll adopt a hybrid of a 2-level hierarchical website with a database-style secondary layer. While more structure would allegedly be helpful from an SEO perspective, I don’t think it will matter too much long-term. This will be more future proof because it leaves room for future categories that a user would see as key interactions, such as Services, without creating a really rigid hierarchy. Within the top-level categories, things like Content Type can be used to further breakdown the website, while being able to search for something like Business Function can span across higher-level categories without impacting structure. We’re keeping it user-centric — what a concept!
This is pretty simple, so instead of providing a taxonomy I’ll just provide a visual:
Business Function
I went back and forth on whether Business Function was something that I could see value in. In my opinion, business functions are somewhat silly. If we take something like Customer Service and compare it to Product Development, on the surface we see these as very different functions. But, if we break the business functions down to the task-level the differences become much more minimal. Both require strong understanding of what customers need, and this is oftentimes arrived at through some form of data analysis. Both require time management, benefit from automation, and get easier when you can lean on connections. And, when you consider cross-industry differences, the Customer Service function in one industry could be equivalent to Product Development in another. I don’t like barriers that only exist because of industry jargon, or in this case, function jargon. But, just because I don’t like it doesn’t mean it’s not valuable to others. With that, could I anticipate someone trying to navigate or find information that’s business function related? Absolutely. And, there’s value in being able to contextualize subject area with function application at times.
Keeping in mind that this is supposed to be just granular enough to be useful, I’m only focusing on core business functions. Here’s what I’ve landed on:
| bfName | bfDescription |
|---|---|
| Product Development | Creating and improving products to meet market needs. |
| Sales and Marketing | Promoting products and driving customer acquisition. |
| Operations | Managing day-to-day activities and processes. |
| Finance | Overseeing budgeting, accounting, and financial planning. |
| Human Resources | Recruiting, training, and managing employee relations. |
| Customer Service | Ensuring customer satisfaction and addressing concerns. |
| Quality Assurance | Maintaining standards and improving product quality. |
| Function Agnostic | Catch all for non-business related content or projects. |
Subject Area
Before diving into this one, let’s define what we mean by Subject Area to make sure it drives additional value beyond our other taxonomies. This isn’t complex, but it does need to be purposeful. While there are definitive subject areas, they’re not logical and the “hierarchy” of subject area is more dependent on other dimensions like company size, industry, job scope, or even just personal perspective.
So, let’s define Subject Area as an informal noun that Operations attribute toward, but does not include a Business Function or Application. For example, Client Relationship Management is a Subject Area, while Salesforce is the Application, Sales and Marketing could be the Business Function, and Lead Quality Scoring could be the Operation. I think it also makes sense to acknowledge that a Subject Area could be part of another Subject Area. For now, I’ll acknowledge that by allowing the layering of Subject Areas through parent/child relationships. Here’s how that will look:
| saName | saParent | saDescription |
|---|---|---|
| Website Operations | Oversees website functionality and updates. | |
| Content Management | Website Operations | Manages content and content optimization. |
Content Type
Content Type taxonomy focuses on what is being created and the value that it brings. When we think about content related to marketing, it’s generally categorized based on how it’s being positioned to the reader. Are you building community, establishing authority, provoking action, etc.. And, that’s great but not the point of what I’m doing. Trying to research a subject like this is incredibly frustrating - you’re essentially bombarded with lead generation forms with vague niceties like “good content is valuable! Fill out this form and we’ll make it for you!” The other dimension content is oftentimes classified by are more about the medium - so, is it a blog, an infographic, a video, things like that. Again, maybe interesting to someone but knowing something is an infographic vs a blog doesn’t really help beyond preferred learning styles, and in some cases, accessibility. While both are important, they’re not the problem we’re focused on right now.
Keeping in mind that if we’re staying user-centric, some content types should only fall under specific parts of the website. The content type has associated value, which means it has associated user intent. Here’s what I’ve decided to implement:
| ctName | ctDescription | wsStructure |
|---|---|---|
| Community | LDL, Musings, Rants | /Blog |
| Education | Instructionals, Consulting, Industry-Related Breakdowns | /Blog |
| Resources | Data, Playbooks | /Resources |
| Portfolio | Projects, Dashboards | /Portfolio |
Putting it all together
I referenced this in my previous post, but I’ll bring it back up now that I’ve outlined the taxonomies. Something I found really helpful when building up and filtering down the dimensions was to see if I could summarize the work through a standard user story template (learn more here) and defining the relationships between the dimensions for the deliverable (similar to a knowledge graph). Using this piece of content as an example, you could describe it through the taxonomy:
Relational Classification - Community Content Type about Content Management through Developing Taxonomies on Squarespace for Sales, Marketing, Product Development, and Customer Service
User Story Template - As a {Business Function}, {Subject Area} I want {Content Type}, {Operation}, {Applications Used} So that {Content Type: Value}
And, reminder that the Asset Taxonomy will be mapped to our other taxonomies with the inclusion of Asset Type and Operation:
Folder: Mapped to Website Structure
Naming: ShortDescription_Operation_AssetType_Version
With this template, it forces me to think about the value generation of each piece of content, project, etc., which should enforce some natural refinement, prioritization, and most importantly, thoughtfulness.
What’s Next?
That concludes our development of taxonomies, but, they’re not doing anything by just sitting in a spreadsheet! I’ll be working through implementation in the next blog to see if we can deliver on our three outlined goals of taxonomy. Or, it may uncover some gaps for further development. Thanks for reading!
