While I haven’t been an official content strategist/publisher for that long, I actually have been web publishing for a long time now. Over the years, I’ve learned the difference between good practices and bad practices, from experience and through classes and webinars I’ve taken. I’d like to think that from all of this that I’ve learned to be a pretty good content strategist and web publisher. Even so, I still don’t understand why people find content strategy difficult to understand, and why creating a high standard of quality in content strategy and publishing content that’s user-friendly is so difficult. It makes me want to pull out my hair it frustrates me so much!
A recent occurrence of this lack of comprehension spurred my intense frustration again. I’ve experienced this before in many places that I’ve worked, but this was just the latest occurrence that sparked my ire. Among several projects that I’m working on at work, one of them is managed by another web publisher. In our project, we’ve been assigned to revamp a current internal website. Par for the course–this is what we do. The project manager was given an outline by the internal client, along with the main content, which included documents to be linked within the pages. That sounds fair enough. Of course, as most technical communicators know, content written or planned by non-technical communicators usually needs some help to make it more user-friendly. In this case, much of the formatting of the content was…less than desirable. In addition to making the outward facing part of the microsite user-friendly, we also had to make the back end–the organization in the content management system–user-friendly as well, since the client would be maintaining the site after we were done setting it up. This all sounds like a reasonable task, and a technical communicator would be just the person for the task.
However, I found myself frustrated with the process, or rather, the quality of what was starting to go up. The project manager gave me sections of the website to work on and format. I found it difficult to decipher the client’s outline because the outline was written poorly. Nevermind the actual text itself, which wasn’t always well written either. I couldn’t really touch that. The outline was meant to help the web publishers–the project manager and I–understand how the client wanted the site organized. At a high level, the main outline seemed fine, but when getting into the finer details, it easily fell apart for many sections. I often had to consult the project manager for clarification, as I wasn’t supposed to be talking to the client directly, for some reason. Whatever.
The other problem was that nothing was labelled in a way that made sense or was user-friendly for use on the front or back end. I can understand that people have different naming conventions for files that make sense to themselves. But when creating the name of a file that is some sort of document or form to be used by others, and not giving the document a title? I don’t get that. For example, if the document is a quick reference guide about how to use your Lotus Notes account, then the text on the web page should be something like,
Quick Reference Guide for Lotus Notes
and the file on the back end should be called something like, “QuickRefGuide_LotusNotes.pdf,” or something like that in order for the user to understand what they are downloading. The file shouldn’t be called something like, “QFC-LN_ver1_01.02.14.pdf”. Down the road, someone will look at that downloaded file and question what that file is. Wouldn’t it be easier to title the file more appropriately rather than have to open it? I’m sure some would argue something about versioning here, but in our CMS, there seems to be a bad practice of putting many versions of the same document up with different names rather than utilizing the versioning function of the CMS. I use the versioning function on the CMS extensively on the other sites I work on, so this confuses me that others think it’s okay to clutter up the system with many versions of the same file under different file titles.
To add to the grief, the client sent files in zip files which yielded unorganized folders and files as well. In this instance, the project manager would keep the folder convention the client had given, even when it didn’t make sense. When I questioned the project manager, I received the response of, “The client had them organized that way, so we’ll leave it because they’ll be maintaining it later.” NOO!!! The organization didn’t make sense, it didn’t follow the client’s own outline, and complicated the back end so that it didn’t make sense! I am confident that the client just slapped some folders and files into a zip file, and sent it along for us to decipher it. I spent the past year cleaning out another department’s very large microsite doing just this–giving files more appropriate names and creating a folder system that would make sense to ANYBODY going into the site to find the page or document needed that followed what was on the front end. And now, when changes need to be made, it’s easy to find the appropriate documentation.
As I’d do the pages I was assigned to do for this new microsite, it became clear to me that the project manager didn’t care. Granted, it’s a big project, and we want to get it done quickly. It would be easier to be able to merely cut and paste content into the site and be done, but it’s also our responsibility as content strategists and technical communicators to make things easier, more streamlined, more user friendly for both the front end and back end. The mantra for all technical communication is always user advocacy– for all aspects of the project, whether it be digital or print.
This means that there needs to be attention to details, thus the “copy and paste” method of entering content into a CMS system alone is not enough. I used to be known at one job as the “Table Queen” because the CMS used didn’t like the copy and paste of tables from Word, so I usually had to go into the HTML code and fix everything so it displayed correctly–or if I could, make it display even better. Tables are something simple to figure out in HTML, but even so, it was something that other people at that particular job with the title of “web publisher” did not know. (They didn’t even know HTML at all, so why were they called “web” publishers?) It was important to make the pages look consistent and be organized in a way that would allow the users to find information quickly and easily.
In this project, I’ve found that the project manager isn’t taking the lead in setting the standard for the website. I’ve been disappointed that the same standards that I would expect aren’t being displayed by this person. It frustrates me, but like I said, it’s not the first time I’ve encountered this reluctance to make a website work.
Do understand that I’m not a perfectionist. I let things slide to a certain point, too, and post things that are “good enough”. But in the end, it comes down to the foundation of the website. If the foundation and the building blocks aren’t sound, it’s not going to hold up. In content strategy, if the infrastructure of the site isn’t sound, and the content isn’t well defined, then the website will reflect that disorganization.
Content strategy, at its core, is really easy. It’s all about organizing information in a way that it can be easily searched and retrieved. It’s about labelling files and folders so that they make sense. Val Swisher’s analogy about content strategy being like one’s closet still stands at the heart of it. If you can organize your closet and identify the different clothing pieces in order to categorize them, then you understand how to do content strategy. The only difference is that instead of having shirts, skirts, pants, and shoes to organize, you have folders of documents, webpages, and multimedia. The method of making sure that users can find those documents, webpages, and multimedia should be streamlined, clear, concise, and user-friendly. As content strategists and user advocates, it’s all about making sure that what the audience is viewing looks and reads well, and what the content managers can maintain easily.
Ultimately, when creating a content strategy and setting it up for maintenance, do it correctly now, even if it’s time consuming. If for no other reason, it’ll save time and headaches later. It’s not difficult. It’s just common sense.
TechCommGeekMom 
Hmmm….There’s a lot here to digest. I’ll hit just a couple of points.
First, Danielle, thanks for telling your story. To me, and I’m sure to most of your readers, it sounded very familiar. How can other people miss seeing what seems so obvious to us? Well, not everybody sees things the way we do. I guess that’s how we know we’re in the right line of work.
You chided the project manager for not caring. In his or her defense, perhaps the tasks you’re describing — renaming and reorganizing the source files — are outside the scope of the project. If the work scope doesn’t include these activities, and if there’s no money in the budget for them, then the PM is just trying to deliver what the client asked for. Of course you want to streamline and improve anything that falls within the scope of your assignment. But not necessarily what falls outside the scope.
Finally (and forgive me if I’ve misunderstood you), you imply that content strategy is a matter of organizing content and ensuring that it’s usable and findable. In fact, content strategy is much more than that: it involves analyzing content in terms of the business’s goals; it involves promulgating guidelines for creating and publishing content in keeping with those goals; it involves issues of process and governance. Content strategy, at its core, is NOT easy. That might help answer your question of why so many people don’t “get” content strategy.
Thanks for your response, Larry. This is my third attempt at a reply, so let’s hope this one sticks.
You are right that content strategy is certainly more involved. I oversimplified it here. However, in this particular project, all the streamlining, reorganizing, and renaming source files are within the scope and budget of the project. The extra effort really isn’t that much effort at all, and it isn’t even all that time consuming either. These steps are the basics of making sure that the content is promoting this department’s goals and processes clearly. So, I don’t understand why the minimal amount of effort isn’t being done by this PM to create the best site for this client. Content strategy takes time, energy, and especially careful thought and planning. I haven’t gotten the impression in this particular situation that all that is possible has been done in this regard. Content strategy, in that respect, is easy to learn, because for me, a lot of it is about the mindset, not just the skills, and I’m just not seeing it in this project. Hence, my frustration.
Thanks for clarifying. You’re right: content strategy is about the mindset. It’s not for the lazy, and it’s not for the uninformed. I hope that by gentle persuasion, and by setting an example, you’ll start seeing changes in the way your project is being managed.
Thanks, Larry. It could be that the PM is just overwhelmed right now, and I’m not against “good enough” practices sometimes. But as I said, some of these are details that really count in the long run, so it’s worth taking a step back, thinking it through, and making the time for those changes.
Hi Danielle
To say that the situation you describe and the frustration you feel is familiar would be an understatement. I am one of those people, who, like you, finds the idea of content strategy both obvious and easy. (I am talking about the tech comm type of enterprise content strategy you describe. I know there are lots of people in the digital marketing world who use the same term to mean something rather different.) However there are lots of people out there who simply don’t get it. Some of those people have years of experience in tech comm, and have impressive job titles as well. We have to do our best to encourage, educate, enlighten or evangelise those people. That’s never easy and is sometimes damn near impossible. We just have to do our best!
Hi David,
Thanks for commenting! This is a big reason why I have this blog. I have it to share the knowledge I’ve gained, but also to share the information that I’m learning along the way as well from others. There are people out there that are much more experienced and well-versed in content strategy practices than I am. But at its core, it’s not that hard. When it comes to content strategy, I often feel like saying that cliche phrase, “If I can learn it, so can you!” Glad to hear that you are willing to help and share your knowledge with others as well.
This sounds more like information architecture to me than content strategy, more related to things like taxonomies and hierarchies of information, versus the information itself. Larry makes good points on this that I don’t need to restate, but there are enough conflicting definitions of content strategy out there.
Taking a strategic approach to this architecture, however, is very important.
Although, I should add, it does seem like tech communicators specifically use “content strategy” in this sense. Perhaps that is why you and I have been going around and around in our conversations about it: I’m coming at it from a journalist’s point of view!
Nope, we don’t. We look at a bigger picture, and content strategy is just one piece of the entire puzzle.