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 
You must be logged in to post a comment.