Taxonomy planning (webinar)
Bill Swallow and Gretyl Kinsey share some of the most important steps to take when planning for your taxonomy in The Content Strategy Experts Webcast.
“When starting with a taxonomy, never start with a blank slate, because chances are somebody has done something already.”
—Bill Swallow
Related links:
- Tips for developing a taxonomy in DITA
- The benefits of a taxonomy (podcast, part 1)
- The benefits of a taxonomy (podcast, part 2)
Twitter handles:
Transcript:
Elizabeth Patterson: Hello everyone and welcome to The Content Strategy Experts Webcast. This presentation is Taxonomy planning and it’s presented by Gretyl Kinsey and Bill Swallow. The Content Strategy Experts Webcast is brought to you by Scriptorium. Since 1997, Scriptorium has helped companies manage, structure, organize, and distribute content in an efficient way.
EP: I want to go over just a couple of housekeeping things before we get started. Attendees are going to be muted during this presentation. Many of you sent in questions when you registered and we have included answers to those in our presentation. But if you have any other questions that come up during the presentation or if you didn’t get a chance to ask your questions when you did register, please type them into the questions module and we will get to them at the end of the presentation.
EP: If you would now, just go ahead and locate that questions module in the GoToWebinar interface. Again, I will get to those at the end of this presentation. With that, I’m going to go ahead and turn things over to Gretyl and Bill. Gretyl and Bill. Are you ready?
Gretyl Kinsey: Yes.
Bill Swallow: All set.
GK: Hello everyone, just to briefly introduce myself. My name is Gretyl Kinsey and I am a Technical Consultant here at Scriptorium where I’ve been since 2011 and some of the things that I focus on here as a consultant are information architecture, metadata modeling. I’ve also done a lot of work on our LearningDITA site, which is a free e-learning resource for learning how to write content in DITA XML. A lot of the stuff that I’ve done on the sort of information architecture and metadata side of things has really helped me get a lot of experience when it comes to things like taxonomy planning.
BS: I’m Bill Swallow. I am the Director of Operations at Scriptorium and I’ve been with the company a little bit. Well, not as long as Gretyl, but getting close to that mark. I’m mainly involved in enterprise content strategy and localization strategy, although I do quite a bit of work with taxonomy and metadata as does Gretyl. A lot of my experience does come from the localization side of things. I’ve worked for a couple of different localization service providers in the past and have brought that knowledge along into my work with enterprise content strategy.
GK: We want to kick things off with going through sort of an introduction and some general information about taxonomy. We got a lot of really great questions from all of you as you registered, kind of in the vein of just what is a taxonomy? What are some best practices, how do we get started? Kind of just getting information on what a taxonomy is and how you might use it. Bill, the first question that I have for you is just how would you define taxonomy?
BS: That’s a really good question. If you have done any kind of searching online, you’ve probably found 1,000,001 different definitions that I’ll touch upon, kind of the same line of thought. But when we talk about taxonomy for content, it’s really about classifying and organizing content based on either heredity or based on different types of the same thing. We’re looking right here at a nice table setting and you could create a taxonomy based on this table setting.
BS: But one of the questions that actually came through was asking a very specific question about, what is the difference between ontology and taxonomy? The two kind of play hand in hand when we talk about content. Ontology is building relationships within a certain context or within a domain of knowledge and taxonomy classifies that information.
BS: Looking at this dinner table, you have a taxonomy of utensils, so you have many different types of forks. You can have salad forks, dinner, forks, seafood forks, and dessert forks all sitting in front of you. They’re all different types of forks that would be classified as forks, but you wouldn’t necessarily lump them into the same taxonomy grouping as dishes and bowls. They might be somewhat related, but they are not of the same kind. This is what we’re talking about how the two play together.
BS: You have these taxonomies where you’re classifying things as belonging to a certain type and you can drill down into many, many, many levels of weeds to define exactly the specific differences between the similar things or you can look at it as more of an ontology to say, okay, you’ve got a dinner setting. You have plates which have their own taxonomy. It may encompass bowls, and you would use a combination of your utensils and your flatware or your plates and such to perform a certain task such as devour dinner.
GK: Yes, absolutely. We see a lot of practical application of this sort of thing every day, I think, as content consumers and content creators. From the consumer side of things, anytime that you are doing some sort of online shopping where you are considering different products to buy, there is some sort of a taxonomy driving that from the backend that allows you to sort through the information that you’re finding based on whatever might be helpful for you to get what you need. Whether that is particular product features, whether it is things like when a certain product line came into being versus kind of different generations of the same product line. Whether it’s kind of comparing different products against each other or different kind of groupings of products against each other.
GK: There are all kinds of ways for you to sort through the information that you would get about those products so that you can make the most informed decision about what you’re buying. The implication of that on the content creator side is that when you are documenting all the different products that you have and putting out what information your customers might need, you have to really think about not just, “What are we going to say about these products?” But, How are we going to organize and classify that information so that users can filter through it, sort through it, search it, and find exactly what information that they need at the right time so that they can accomplish their goals. Whether it’s buying a product, using a product or kind of both of those things.
GK: I want to move on from here to the question, or I guess I should say several questions because we had a lot about this too. But how do you get started? If you are that content creator and you are planning and setting up your taxonomy, what are the kinds of considerations that you need to keep in mind?
BS: I think that the very first question to ask is, why do you need it? Most people don’t walk around going, “I could really use a taxonomy.” There really has to be a purpose behind it and what are you trying to do with this? What problems are you trying to solve? From that point, you start diving into a few different areas. One of which is definitely scope because just like a tree your taxonomy can branch out seemingly forever, fork after fork after fork going out and drilling down not only up into the clouds but also down into the soil.
BS: You really have to figure out what the full scope is that you’re intending to look at? Is your taxonomy… does it need to be a company wide focus? Is it limited only to one or a few departments? Is it limited just to products? Is it limited just to the web interface? Do other people need their own specific taxonomies? Do they need to align with the larger one or can they stand alone on themselves? So, trying to figure out the scope of what it is that you need.
GK: Yeah, that’s really-
BS: Likewise… Oh, sorry. Go ahead.
GK: I was going to say just jumping in on scope, that I think is kind of one of the most difficult things that I’ve seen working with different clients here at Scriptorium because when you do have a large company and you’ve got all these different departments trying to figure out what their taxonomy needs are or sometimes you have one department that knows they need a taxonomy and then these others don’t until the first one brings it up, that’s where you really get into these questions of scope. There’s a whole lot of coordination that has to happen just to make sure that any relevant groups in the company or the entire enterprise at large has this clear understanding of what scope of taxonomy they need.
BS: Exactly. The needs are going to vary.
GK: Yes.
BS: In one group, might leverage the taxonomy in a very different way than another. The web group might be more focused on user-facing taxonomies and the content development group might be more interested in source content development taxonomies. Being able to classify things so that they can find information to quickly edit, update, make sure that they have a full content set for whatever it is they’re developing in these types of things, and also inform any kind of metadata use that they might be planning and making sure that that’s aligned as well.
BS: Certainly there’ll be a handshake there between a lot of the metadata and a lot of the organizational work that the writers do when it comes time to publish information on the web.
GK: Absolutely. I think as you were starting to say before we kind of went off there, the next kind of logical place to ask questions and start that planning once you have really determined the scope that’s needed is looking at your stakeholders and asking, “Now that we’ve nailed down our scope, who has to be involved in this planning process? And kind of what levels of the company need to be involved?”
GK: For things like the actual taxonomy planning, it’s likely to be people like your employees, your writers, your subject matter experts, other contributors that really know the ins and outs of what your needs might be. But then, it’s going to be people at the management and executive level that sort of have that power to make it happen and to get the resources together to actually put that in place. It’s really important to think about that representation of stakeholders from all different levels across the company.
GK: Then especially if you get into this, what we talked about with scope, with different departments having to be involved, any of their kind of corporate hierarchies that may be the same or different from your own department. There’s got to be that sort of coordination of stakeholders as well.
BS: Yep. Then also, after you’ve done your navel gazing internally, you also have to consider the audience that is going to be consuming the content ultimately. Does your internal taxonomy match up with what they’re expecting? A lot of times especially when the web was young, companies would organize their websites based on what was important to them. They found out very quickly that people were either not finding information or weren’t finding them at all, getting frustrated and leaving their site because the information was not arranged in a way that they could find what they were looking for or was using even terms that did not mesh with what the company thought things should be called.
BS: These are other things that you need to start considering, who are your users and who are your audiences? To what end are you doing this taxonomy work and how will it impact those who are consuming the content?
GK: Absolutely. That gets into the idea of, once you’ve established who are those users, as Bill said, how are they going to be using it? What kinds of things are your users going to be searching for to find that information they need? That’s going to be a very different answer depending on what kinds of segments of an audience you might be serving. For example, if you are serving content to your kind of external facing customer base, they’re going to be using very different search terms and methods of categorizing your information probably than someone like an internal user or an author or a subject matter expert who knows the products a lot better than an average customer would.
GK: You have to think about the kinds of metadata that you would put on your content for an internal user, trying to find what content that they’re going to be working on versus an external user, a customer, just trying to find the right information that they need to make a buying decision. That’s a really important place to where I think it’s necessary to plan and gather metrics from your external audience because when you’ve got your internal audience, it’s a lot easier I think to kind of have an understanding of what’s needed.
GK: But when you are trying to figure out what a customer needs, as you mentioned, Bill, just kind of guessing or organizing things based on what’s important to you as a company is not usually going to align with us. It’s really important to put things in place where you can get user feedback, user metrics information from your target audience on how they need to find information, what they’re looking for, how they’re searching for it, so that you can actually serve up what they need.
BS: I think the final thing to really focus on when starting with the taxonomy is to never start with a blank slate because chances are somebody has done something already, just kind of wrap their own brain around things at your company or the products that you have and so forth. Chances are someone has the taxonomy. More times than not, it’s a web team because they have to organize and classify this information in order to put it online in the correct place. It’s usually a good place to start. It may not necessarily be the correct organization of things that you need.
BS: Again, it goes back to, what the purpose is for yours? But especially if you were doing something that’s more company-wide, you do want to start with what people have already done and acknowledge where the taxonomies are coming from and being able to draw associations between them and see how well they mesh together and where they diverge and need to be corrected. But you definitely want… I mean, it’s not a small task to build something like this out. Wherever you can leverage what’s already been done is going to save you a lot of time and a lot of negotiation with other groups.
GK: Absolutely. Find those resources and even if it’s not kind of a formalized taxonomy, there is likely still something there that has been used that has been driving the kinds of user searches that you’ve been doing in the past. That is the best place to start. That can often as Bill mentioned, sort of resolve arguments. A lot of times departments will go, “Well, my particular way of classifying this information is definitely the best because of this.”
GK: If you’ve got that proof that maybe this one department because it’s been the most closely linked with what customers are doing, if you’ve got that evidence then that kind of helps resolve that argument because it says, “Okay. Well, customers are used to this set of terms so that means these other departments should look at how to align with that.”
GK: I want to move on, I think from this point of where do we get started to really kind of get into some of the nuts and bolts of planning and gathering information. We had a lot of really great questions from all of you on this as well. The first one that I want to put to you, Bill, is how do you make sure your taxonomy is scalable and future-proof? Which is a very loaded-
BS: A scalable.
GK: …. question.
BS: It is a loaded question. We’ll address the future proof first. Nothing is ever future-proof and nor should it be. Things are going to change. Your company’s direction, the services that you provide, the products that you produce, they’re always going to change. Being able to say it’s future-proof, would be fine and good if your company never plans to change the way it’s working other than just putting out new models or putting out new associated services.
BS: But more times than not, things are going to change and you need to be able to account for those change, which is where scalability comes into play. Being able to grow new branches and recede some as needed. Those are incredibly important. Probably the best way of starting to do that is to keep an open feedback loop going both internally and externally to kind of figure out if people’s needs are being met.
BS: If suddenly there’s no home for something that you can’t easily classify something new in what exists already in your taxonomy, and being able to hopefully not as a reactive measure, but hopefully as a proactive measure, being able to plan for these things and have people say, “Hey, we got this new thing coming out. It doesn’t quite fit in this bucket doesn’t quite fit in that bucket. What do we do with it? What do we call it? How do we address the public with this and stir up an offering and categorize it in a way that they’re going to understand what it is?”
BS: There’s nothing that’s ever future-proof, but hopefully you can start classifying things a little bit more carefully and being able to identify where these new shoots are going to start rising up from and how they might diverge over time.
GK: Absolutely. I think to kind of address the scalability part of that question too. One thing that I’ve seen really work pretty well with organizations who maybe have not had sort of a formalized taxonomy or have paid attention to putting a taxonomy in place before, but they really want to start doing that now and make it scalable is they often start small and start with maybe one product line or in one department and then think about how they’re going to make sure that scales up.
GK: One example that I can think of is the company that I’ve worked with that said, “Okay, this is our kind of flagship main product line and we’re going to develop metadata for all of the content around that product line, knowing that we have three or four other product lines in the works that will be released in the next two years that kind of mimic the structure of the way this product is being delivered.”
GK: Looking for that proof of concept or that pilot, it works not just for kind of general content strategy, but for something like a taxonomy as well. You can kind of leverage the way that you plan for that one piece and say, “Okay, we know that we have this product over here, we know there are going to be similar products or maybe it’s going to evolve into a larger product line. If we start with taxonomy planning there, then we can think about how to scale that up knowing that that growth is coming.”
BS: Again, a taxonomy is simply one tool of classifying the information. So, you may have a couple of other things going on. We spoke about ontologies earlier and being able to draw those associations between different things in order to put together or create a complete context. One easy way to do that is to look at some information that you’re putting out for a product. You might have some conceptual information about a product. You might have some instructions in there.
BS: Certainly, some different types of reference material, and training material, and so forth. These all stem from different types of content. Within your taxonomy, they’re classified differently, but they are collectively related in order to paint a complete picture about whatever it is you’re writing about and being able to keep those things in mind as well. When you start having a new offering or a new product or a new audience type, it’s important not just to look at the taxonomy but to look at these other relationships as well and start seeing, “Well, if we’re developing this new thing for this new offering, if we’re classifying things a little bit differently here, how does that impact all the other stuff we have and should we start classifying those things in a similar way as well?”
GK: Absolutely. Another question that we got is, how does your taxonomy affect organization planning and execution? I think this is a really interesting one because I think both of those things kind of affect each other. So, your taxonomy can affect the way that you organize and plan things in the future. But then, also, things like organization and planning and execution affect your taxonomy. What are your thoughts there, Bill?
BS: Well, it certainly does give you a place to start and you need to kind of know what you need in order to develop against this new thing. You already know that. Let’s say you’re putting out a new model of, I don’t know, some device and it’s based on an existing device but has some new features. It was missing a few others and serves a slightly different purpose or serves multiple new purposes. You can already classify a lot of that information by studying your taxonomy and figuring out where it’s going to fit.
BS: From that, it can inform a lot of the different needs you have around your content and you can begin to develop a plan for being able to provide all the different pieces of information that need to go with this new device.
GK: Another question and a couple of these are kind of getting into some of the more specifics as well, so this is kind of fun. We got a question of how to design classifications for topics that may cross multiple categories, are hierarchies of classes a good way to go? This one’s really interesting too because kind of seeing this in action with having sort of these categories and subcategories of information and how that can really both make content more organized and easier to find, but can also add some complexity to the way that it has to be searched.
GK: I think the biggest thing to think about is, if you’ve got sort of information that crosses multiple categories or that fits in multiple categories or that maybe it fits in sort of a large hierarchy to think about the cost benefit analysis, if you will, of the complexity of that and how that affects the end users ability to find information versus truly categorizing it as it should be and not having it where it’s such a kind of a loose taxonomy structure that nobody can find anything.
BS: Right. But also, these complexities can also change how you’re leveraging your taxonomy in order to implement solutions for your audience as well. In this case, maybe it’s classified in a very specific way, but the taxonomy also drives a level of complexity in the metadata that is relatively easy to implement and manage but kind of solves a few different problems on the publishing side, particularly when it comes to a faceted search for example.
GK: One other question that we got which I think is really interesting because I’ve seen this one in action at a couple of different companies and that is about how to establish or plan for taxonomy across multiple products that use different terminology and strategies for different audiences and groups. That’s actually something that for about the past year or so that I’ve been helping with one of our clients to kind of look at this exact problem especially with the issue of different terminology across different products and different departments.
GK: I think that’s kind of a common thing that can happen, especially if you’ve got an organization where maybe there’s not a lot of great communication among the different departments. In this particular case that I’ve seen the problem they’re facing is that, for example, they’ve got the group that develops the products and they’ve kind of got their own terminology around different product features and ways that they write about the product.
GK: You’ve also got a group of trainers. That’s both in-person and web-based trainers who write about how to use the product. Sometimes even between kind of the in-person and the online training materials, there are some different pieces of terminology that pop up for the same feature or the same action that you can perform with the product. Then, you get into other departments like marketing, they’ve got different terms that they’re using for features that are focused on using that as a selling point. Then you’ve got things like legal that have their own set of terminology as well.
GK: The problem that they’ve started to encounter is that when the internal users of this content, so people at the organization who are contributing and creating new content and trying to put together all these new materials are having a hard time communicating about a certain feature because somebody over here in marketing is calling it one thing and somebody over in training is calling it something else.
GK: Now, they’re faced with this issue of, we want to align our terminology across the entire organization, but at the same time we understand that there are some reasons why certain features might be presented in different ways to different audiences and that may sometimes involve different terminology. Bill, have you seen anything kind of similar to this and have any possible solutions or ideas in mind for how you might address it?
BS: I’ve seen it to a degree, yeah. I’ve especially seen it with regard to terminology when it comes to localized products particularly when we’re talking about products that not only vary based on where they’re going, but the different languages that all the content is being translated into and that sometimes the terminology that you’re using can either overlap or diverge from what was originally intended, which makes perfect sense to the person reading it in their native language but doesn’t necessarily follow the same… The literal translation, I guess, is what would diverge from what was being used internally on the source side.
BS: Also, being able to look at the different configurations of different products. When it comes to more global audiences, you might have very different configurations for the exact same product based on different environmental factors. It could come right down to being able to classify things based on the type of power supply it has. If you’re sending it out to three different companies that use two different voltages and three different amp settings, you suddenly have a whole different problem within the same product line.
BS: You could resolve that with drilling your taxonomy even deeper and being able to classify these things not only by product type but also by regional distribution. That again, leads back to your problem. Gretyl, you mentioned with having these multiple ways of classifying the same thing.
GK: Yeah. I think when it comes to figuring out the solution for that, the first place to look is to ask yourself, “What are the problems that’s causing?” If there is some really important reason to have sort of this different terminology in different contexts that that should be documented and communicated and understood so that it doesn’t cause any confusion internally or externally.
GK: Then, second, if there is no real reason for it, it’s just something that’s grown out of different groups, not really coordinating together then that point that this idea of, “Okay, well, maybe now we need a solution where we all come together and decide what are the consistent pieces of terminology going to be and how do we determine that?” I think that gets back to what we were kind of talking about previously, Bill, when it comes to getting that feedback and those metrics from how people are using your information. That’s going to kind of give you the path ahead to saying, “Well, training calls this feature this, and then marketing calls this other thing, and tech pubs calls it yet this other thing. But if our audience calls it this, then everyone across the company should start calling it that as well.”
GK: That should be implemented and enforced as the definitive terminology that gets shared across the entire organization as part of the taxonomy.
BS: Of course, in managing a lot of these things, what we see happen in some cases, especially with very large companies is that you end up having a taxonomy of taxonomies and it sounds really good on paper to be able to classify things and have basically an entirely new taxonomy being used in one group that is structurally related to a taxonomy that someone’s using in another group. But maintenance on that can be a nightmare.
GK: I think that’s actually a good segue into the next topic that we want to talk about, which is governance and maintenance of taxonomy. Because as you said, that can be a nightmare or it can just be a challenge depending on somewhere in that scale of challenge to nightmare depending on what you’re up against, and kind of how you got to that point of building your taxonomy and how you’re going to manage it. I think, one thing that’s important to talk about is considerations and things to ask yourself internally as a company about how do you manage the implementation and use of your taxonomy once you’ve got it defined and set up?
BS: In this case, it’s not the same as just letting a tree grow and letting-
GK: Absolutely.
BS: … letting it grow, you do need to be there, pruning the branches as things happen and allowing other ones to grow. Getting your hands around that, the first thing is you have to start looking at, who’s going to be responsible for maintaining this thing? Is it a specific role in your company? Is it a person with a side responsibility? It kind of depends on how big of an organization you have and how much bandwidth you have to manage the taxonomy.
GK: Yeah. I think that’s kind of one mistake I think I’ve seen a lot of companies make is that they come up with this taxonomy, they get everything organized, they define everything, but then they don’t think about a dedicated resource of who’s going to keep it maintained, who’s going to keep it updated, who’s going to be the one responsible for making sure that any changes that happen to that organization get in and get communicated outward everywhere that they’re relevant?
GK: I think a lot of times people assume that it’s going to be as simple as one sort of tool that manages it all. But it’s really more about having the human resources and someone who understands the way that this problem might cut across a lot of different departments that may be using different tools when it comes to actually tagging their content with the relevant metadata from the taxonomy. Or, if they’re on kind of a website of things and they’ve got web tags, making sure that everything is consistent across the board is something that requires dedicated resources and people to constantly be kind of keeping an eye on it and maintaining it and communicating that information to everybody so that everyone across the organization is on the same page.
BS: Absolutely. I mean, the one thing you don’t want to do is invest all the time and energy in putting one together, putting it up on a shared server, and have everyone clap and then look how pretty it is and then forget about it for 6, 8, 12 months.
GK: Yeah. And then things just grow.
BS: Because a lot can change in that time.
GK: Yeah. Things grew back. Those branches we talked about start growing off on their own and nobody’s pruning them. It really can just kind of take you right back to whatever disorganized state you might have been in before you put a taxonomy in place.
BS: Yeah. You need to have some processes built in there. Not only who is maintaining it, but how are changes or change requests for this taxonomy coming in? And having a process for that so that you know what group requested it, for what purpose? What does it impact? You can start cataloging all these things before you even start going in and tweaking things in the taxonomy because the change that you make could affect how another group needs to use information.
BS: Particularly if you have some content authors doing some fairly rigorous structured content authoring and suddenly someone from another unrelated group requests a change, it could upend the entire way you’re producing content. There needs to be a gatekeeper there and there needs to be not only a process for requests, but there needs to be documentation around it to understand why a decision was made, why a change was requested, and what impact that has on all the groups that use the taxonomy.
GK: Absolutely. When it comes to kind of planning for that and making sure you can do it, it’s important to think about the fact that all of these different people and groups will be using it and that there are going to be limitations based on each group’s tool sets and processes for how that taxonomy can be applied, how it can be deployed, where it can be deployed, how it can be used. That’s why it’s important to have that kind of built in sort of chain of command as far as how to make a change.
GK: Because as you said, if there is no responsible party there to make sure that those changes go through in a way that works for everybody, then somebody might make a change over here, but because of the way another group’s tools are set up or the way their processes are set up, it could break something unintentionally. It really is important to think about that and plan for it, and then have all of your guidelines and your governance around those updates based on those limitations and features that each different department has with their process.
BS: Actually that’s a good segue into the next area-
GK: It really is.
BS: … we wanted to talk about because we’ve got some good questions around this as well. That’s spanning silos and handling any kind of corporate mergers and what you do with the taxonomy in that case.
GK: Yeah. We’ve seen this play out quite a bit, I think, with different clients we’ve worked with. Actually, the idea of spanning silos or handling mergers or in some cases both things tend to be a big driving force behind things like overhauling your content strategy, putting a new and improved taxonomy in place. This is kind of a very common driver for this exact issue. We had a question about this that says, “We are revisiting existing taxonomy due to a merger with another company. Any tips on creating a single unified taxonomy?”
BS: The easy answer for that would be, use whichever company won in the merger. But that doesn’t necessarily work in implementation.
GK: Right.
BS: Yeah, it’s a good time to kind of sit down and I’m thinking visually here with tracing paper and being able to overlay one company’s taxonomy onto another one and seeing exactly what kind of a mess you’re going to have to work with. It’ll probably be pretty daunting, but the best ways to start looking at, well, first of all, letting the merger derive the shift in the taxonomy itself. So, why was there a merger and for what purpose? Is it that you want to combine offerings into a single solution? Is it that you wanted to just expand product offerings or service offerings? Letting that reason kind of guide how you’re going to go about merging and modifying these taxonomies because it’s not going to be as easy as company A’s taxonomy wins and company B just has to make it fit.
GK: Right.
BS: Which sometimes happens, but a lot of times no. As we mentions all throughout this webcast so far, there are many different areas that are touched by a taxonomy and that depend on a taxonomy to get things done. You need to kind of lift the covers on everything on both sides of the company and say, “This is how we were working, this is how we were classifying things, this is the reason we were doing it that way. And these are the implications of changing it.” And sitting down and really working through those rather difficult issues.
GK: Yeah, absolutely. I think one place to start there is once you’ve sort of identified all of those things, those reasons why you had the merger and any information that we talked about upfront before with kind of getting the metrics and information from how customers have been using information. Now, you’ve suddenly got that issue twofold. You’ve got it coming. Anything that you’ve been gathering like that is coming from these two or sometimes more different organizations have merged together.
GK: It’s important to once you’ve got your priorities down for what caused the merger and where are you going from there and what are your goals now as this new unified company to look at everything you had been gathering before and use that to inform, which pieces of taxonomy do we keep? Which ones do we toss out? Which ones do we literally merge together just like we did with the companies? I’ve worked in a few cases like this where there’s been a fully fledged developed taxonomy from one company or one group and then you may have something from an entirely different company, but there’s a lot of similarity and overlap despite the fact that they were created completely separately.
GK: That’s where you can look and say, “Okay, company A and company B were both organizing this particular kind of information in a very similar way. There are a few differences here and there, let’s clean those up and bring them into alignment.” But then you also look and you say, “Well, company A was classifying this other thing in a very different way than company B was. Do we take one or the other or do we do some sort of a hybrid?”
GK: Then, of course, there are issues where company A was addressing something that company B didn’t even think of and vice versa. It does take a lot of time and a lot of back and forth and collaboration and sometimes arguments, but it is really important to go through that exercise with everyone that is a stakeholder that’s involved and say, What are the kind of best and most useful pieces of our taxonomy to keep from whatever different companies came together?”
BS: Yeah. In that case, you do have to embrace the conflict because it’s the only way you’re going to get through it.
GK: Yes, absolutely. That applies not just for mergers but for spanning silos as well. There are a lot of considerations there too. They’re kind of similar in a way because even if you still got one company, that doesn’t necessarily mean that your taxonomy is unified, especially if you do have this problem that I sort of described earlier where different departments don’t talk to each other. They work in these very closed off silos and there’s no open communication and they’ve kind of homegrown their own content solutions and taxonomies to go along with that.
GK: It’s important to address things like what tools and processes that each different department or silo was using. What solutions do they offer for implementing and maintaining taxonomies? How are they similar? How are they different? Where are their conflicts? What kinds of gaps exists? What kinds of overlaps exists?
GK: That’s again, that same exercise that we just talked about with going through and looking at what each department was doing sort of the same way that if you had a merger, you would look at what each company was doing and kind of determine who comes out on top, who wins, which pieces of the taxonomy end up in the final version based on what’s going to be most useful for achieving your goals. Those are kind of things to think about when you’re asking yourself, “How do we solve this problem? How do we get all these different silos into alignment?”
BS: Yeah. It all comes down to the core needs and being able to find that common ground or be able to at least identify that there is no common ground and that you need to work together to solve both needs.
GK: Yeah. I think it’s important to acknowledge here as well that this is something that takes time. I’ve never seen this be accomplished overnight or even in a week or a month. I’ve seen a company with the silo problem kind of chewing on the taxonomy question for over two years, just because it takes a long time to get different groups into alignment and sometimes you have to take an approach of one group at a time. Maybe you get tech pubs and marketing into alignment first.
GK: Then from there, you expand and you pull in training or then from there, you expand and you pull in support or legal or whatever. Just because there are other focuses than just content, departments are busy, everybody’s pulled in different directions and even if there’s sort of this taxonomy initiative growing in one group, it doesn’t necessarily mean it’s going to be a priority across the board.
GK: You kind of have to just strike while the iron is hot as you can. A lot of times it comes down to, is there a specific problem or roadblock that’s caused by having these sort of siloed off taxonomies? That ends up being the breaking point when finally these groups will sort of cave in and start working together. But until then, you really sort of have to sell it and sort of communicate to this other department, “Hey we’re not able to serve up this content in the way that our customers need because of some effect that your taxonomy is having on what we’re doing. So, let’s talk, let’s solve this problem. It’s going to make things better for both of our teams.”
GK: But a lot of times, you kind of have to do it as you can, one piece at a time, just because unless you have an executive champion somewhere up there and forcing it very quickly across the board, it’s something that sort of develops slowly over time based on needs.
BS: Keep in mind that while you’re doing all of these things continue to change in the background.
GK: Oh yes. That’s kind of why you said you can’t ever truly future-proof because the future is a moving target and so you can do what you can, but you have to make sure that you are flexible and have that adaptability in your taxonomy and in your larger content strategy in general, just to make sure that as goals change and needs change and priorities change, that your taxonomy can be flexible and change with it.
BS: Well said.
GK: I think at this point, we can start taking… We’ve got a little about 12 minutes left, so we can start taking any questions from all of you that you did not have a chance to ask ahead of time when you registered.
EP: Gretyl, I’m going to have to ask you to look at those questions because my GoToWebinar panel is frozen.
GK: Oh no, let’s pop those out. All right. We’ve got one that side more of a comment than a question, but I agree with and it’s worth discussing. It says, “This is why it’s important to have periodic meetings between technical writing and training development.” That is absolutely true. I’ve seen big improvements in companies that do that, that establish these regular meetings and discussions and communication, especially if that did not exist before and it was causing some sort of a roadblock or a problem.
BS: Yep. Yeah. This is just another form of governance, being able to essentially have a committee that goes and reviews things and make sure that everyone is on track, that everyone’s needs are being met, that new needs are being floated up to the group for discussion. Because the last thing you want to do is plan this in the vacuum and then have everyone starts screaming when you roll it out.
GK: Yeah, absolutely. I think it can be sort of difficult to establish those meetings if that’s not been part of your corporate culture before. I think that’s one thing to think about as well is how something like taxonomy can end up cutting into the area of change management and how you may have to… You’re not just establishing a new taxonomy, but you’re also establishing a new way of working going forward and how that can definitely be challenging and it can be hard to get people on board, but the reward is very much worth it once you get that up and running as it should be.
BS: Provide snacks. That usually gets people on the road.
GK: Definitely provide chocolate, specifically. Another comment that’s come in, which I think is really interesting and agree with as well, that just says, “When I think of a taxonomy workshop, I think of people in a conference room with sticky notes and markers.” Yes, a lot of times that is a really great way to start is just everybody get together and brainstorm and discuss. I think that’s especially true if you don’t really have kind of that starting point taxonomy yet and you’re just asking yourself, “How are we going to categorize and organize all of our content and our product information?” That’s often a good way to have it start is just people get together in a conference room and sit down and plan. It kind of gets back to the other comment we had as well with having those meetings and that communication.
BS: Yeah. Sticky note to your friend in those meetings because you can easily jot things down and move them around on a whiteboard very easily and start building out, even just the fundamentals of the taxonomy. Usually, that’s just enough. Once you get everyone’s ideas down and organize them, you can all step back and look. There’s usually that aha moment when suddenly you have a collective click. At that point, everyone understands what the purpose and the approach needs to be.
GK: Yeah. I’ve actually seen this kind of grow where something started like that with sticky notes and then ended up becoming digitized with diagrams and spreadsheets or just lists and sometimes all of the above and kind of growing it organically that way, and then distributing it to a bunch of different teams and using that as ways to have different options for how to categorize things easily and move them around and try different things.
GK: That really kind of gets into the next question as well, which says, “Since we’re all a near universal remote work world at the moment, taxonomy development is going to be largely online. Are there tools that you’d recommend?” I think kind of like I just mentioned one that it’s very simple, but just people using shared spreadsheets, Google sheets or having an Excel file like a company SharePoint, something like that where it’s an editable and living document where you can easily put things into categories and shift them around and share it with everybody is one place that I’ve seen several different companies use as their starting point.
BS: Yeah. There’s a ton of software out there that you can certainly use. I tend to err on the side of keeping it as simple as possible, which always brings me back to spreadsheets when it comes time to manage these things mainly because then the information can go wherever it needs to. You can usually write some kind of script or something to import a spreadsheet into almost any application for implementation purposes. But about the collaboration, aside from the spreadsheets, I know it depends on what stage you’re at with developing your taxonomy.
BS: If you’re looking for that initial kickstart, that in-person meeting where you’re all going up to a whiteboard or writing sticky notes, there are a lot of virtual whiteboards that you can use and share with people in a conference call or a web meeting. Actually, even some web meeting software does have them built in as well to start sketching these things out and having people literally point and move things around based on where they think things should go or to make a point or what have you.
BS: But yeah. I tend to go back to spreadsheets more than not when things start to harden a little bit and you have some direction and you just need to start building out layers. Those are usually the quickest, easiest, and most universal tool out there to start building this out.
GK: Yeah. I want to come back to some of the other things that you mentioned as far as things like whiteboards and sketching out because we did just get another comment, is that spreadsheets are really hard on a shared screen, which I do agree with because I’ve been in a lot of taxonomy meetings where we’re looking at a shared spreadsheet and if the categories are very extensive or very large, you can only sort of look at one piece at a time and that does get difficult.
GK: That’s where I think some of these, especially as you’re in the early planning stages and before things are really finalized, having something even more simple, something that’s kind of maybe more of a sketching or block building style tool or something that kind of allows you to mimic a digital version of those sticky notes on a whiteboard that you would use if you were in person is often a kind of a better way to start when it comes to sharing screens.
GK: Then later as things get more developed and you’re using a spreadsheet that that can be something that you reference later but isn’t necessarily something that you’re screen sharing with other folks because I do agree that’s a little bit challenging with just screen real estate and size.
BS: Yeah. I’ve glazed over once or three or a dozen times in meetings when we were just digging into spreadsheets online. Yeah, they’re really good though for making sure that everything gets captured appropriately. If you are at the level where you’re starting to use spreadsheets to manage a lot of your taxonomy development when you have these meetings, it’s probably best to do some kind of a pivot table or some kind of a query or a snapshot of some of the information that you’re collecting so that you can drill through it easier with a remote audience.
BS: For those who don’t know, I work remotely usually. All of my taxonomy development with clients and even with my cohorts at Scriptorium has pretty much been online. I can understand the frustrations that come with drilling through a spreadsheet that’s 50 columns wide by, God knows how many thousands of those layers deep.
GK: Yes, absolutely. We’ve got one more question, which I think is perfect. We probably have time just for this one more, and that is, can you explain where taxonomy is typically applied in most organizations in the content and the structure of the content such as XML or HTML in metadata, other or all of the above?
BS: Yes, it’s other and all the above.
GK: Yes.
BS: No. Yeah, all the above is absolutely correct. A lot of times, we see a taxonomy driving content organization on the backend, content organization on the front end. Wherever things are being published and how, the content is being arranged for publishing. A lot of times, it drives not only the content model, but also the metadata that lives within the content itself for both internal and external purposes. So, yes. D, all the above.
GK: Yes.
EP: Okay. Well, I don’t see any other questions, so I think with that we’re going to go ahead and wrap up. If you do have any other questions that come up, feel free to reach out and contact us. You can get our contact information off of scriptorium.com or you can email us at [email protected]. Thank you so much, Bill and Gretyl for sharing your insights today.
BS: Thank you.
GK: Thank you.
EP: Thank you all for attending The Content Strategy Experts Webcast. The next webcast is coming up on Wednesday, May 27th and Jake Campbell is presenting InDesign and DITA. So, you can register for that on our website under events, and thank you all.
About the author
