20 year content strategy veteran, Sharon Burton. Sharon Burton consults about content strategy, content business issues, social media and managing post-sales customer experience issues.

5 reasons why content creation/development vendors have it wrong

5 reasons why content creation/development vendors have it wrong
5 reasons why content creation/development vendors have it wrong
1.97 (39.31%) 29 votes

Note: Since I wrote this, I’ve discovered 2 other blog posts on this subject: 

Clearly, this is an issue. [update added 11/14/14]

I’ve spent the last few months getting new content development tools set up or helping to change the workflow. And (in my opinion), no content development vendor has it right yet.

Here’s my top 5 reasons why:

5. You have to be an expert in the tool

The vendors assume people will become expert in the tools. This is dumb for many situations. For example, in the oil and gas world, many domain experts are former field guys. They are not going to be experts in a content development tool – correctly using Word is too much for them. But they have important expert domain knowledge that has to be captured. If the tool is hard, they will author (badly) in Word and send it to others to be included into the content development tool. This is a waste of time and effort.

4. Developing output is hard

Sure, many tools, after the output templates are set up, are set it and forget it. Until the re-branding. Or a client wants a special look for their docs. Or a new output must be supported. Then you bring in the expert to set you up again or lose a staff member for weeks while she gets it all sorted. The tools that output to Word are hard because the corporate upgrade never happens in synch with the tool update. And this version of Word is different than the previous version, in that stuff doesn’t quite work the same. Or, in some tools, you have to get yet another tool, shove your existing content out from your existing tool, into the new tool and that one transforms to the new output. It feels cobbled together.

3. Reviews are hard

In 2014, content reviews are still hard. To the vendors credit, they’re trying. But things still have to be emailed around, or sent to a server or accessed from a cloud. Some tools send automatic emails to let the reviewers know there’s something to review but most depend on the content developers to do that. At some point, Sharepoint gets involved and things get complex. Or, as a few vendors do it, a cloud is involved. But what about the important reviewer who travels with an iffy internet connection? They can’t download the files and review offline. At some point, the reviews get lost or tangled up. Or the reviewers have to be expert in the review tool and see 5 above on that.

2. Content reuse is hard

This one really frustrates me. Humans are bad at remembering strings. Computers are good at it. So why is it so hard to automate content reuse? Maybe one content developer can remember, but when you add in 5 or 25, no human can keep track of the content that already exists. One vendor has this pretty close to right but the last 2 times I’ve evaluated their tools this part didn’t work. Yes, they fixed it (both times) in a month or so, but. We’re all told that 30% of our content should be reused. But how do we see this efficiency when no one has it right all the time? How do we see the lower localization costs from reusing our content if we have to remember it?

1. It’s all just hard

It’s all hard. And it shouldn’t be. The vendors are creating content development tools for geeks. Which, for me, is fine. But that’s not what the world looks like out here. Out here, people don’t want this to be so hard. Some hard, perhaps, but this is crazy. Half the time, I feel like we’re gluing this together, doing workarounds and hacks to get what should be pretty easy. The whole thing often feels fraught with issues, as though it’s going to all fall over any second.

Your thoughts?

Is it just me? Do you feel this way? Am I missing something in the content creation and management process?

Like this article? Share it!
By Sharon Burton

5 Comments

  1. Hi Sharon,

    I agree entirely.

    I think there are two root causes:

    1. There are no content development vendors. There are publishing tool vendors. There are content management tool vendors. There are XML tool vendors. There are not content development vendors — that is, vendors whose goal is to ease content development. The vendors we have design downstream processing and delivery (often very well) and then present a front end to authors that requests the data they need to do downstream delivery, without regard to the conceptual and practical difficulties that this presents to authors.

    2. The content profession has become obsessed with the idea that any solution must be a universal standard. This is very much driven by the first root cause, as having content written to a universal standard make all the downstream stuff — publishing, content management, etc, easier to do. The problem is, those universal standards are driven by publishing and content management concerns, not authoring concerns, which makes them hard for authors to understand and use.

    It is also driven by the bad experiences that many organization have had in the past with custom systems. But those custom systems were also built to solve publishing and content management problems, and were equally cumbersome for authors to use.

    We don’t have to throw ways those publishing and content management tools. But we do have to stop allowing them to dictate how authoring is done. We need to build a layer on top of those systems that is designed solely to make authoring easier in specific organizations and for specific groups of authors.

    This will involve creating authoring interfaces that are highly concrete and specific to the subject matter that the author is writing about, and which also capture enough semantics to drive the back end publishing and content management systems.

    What we do to authors today is the equivalent of asking bank customers to write SQL statements at the ATM console in order to deposit a check. We need concrete task-specific authoring interfaces. To get there, we have to get over the idea that we need to write directly in a global exchange format.

  2. I agree, tools are too hard. What you can do is develop a tool that will support your process and your writing guidelines every step of the way. No extra features, no fluff, just the stuff you need and only when you need it. Surprisingly, this is much cheaper than buying a system off the shelf and sooooooo much cheaper than buying one of those huge systems off the shelf.

  3. Greg Daffern

    Surely learning the tool is part of the job of the writer? You wouldn’t expect people to manage multiple-project development programs without first learning to use Microsoft Project (other tools are available) or develop software without first learning to development language, so why is creating documentation different?

    The problem is more to do with how documentation is viewed. A common view seems to be that the domain expert is the right person to document a process. This ignores the core skill of the technical writer: the ability to express the ideas in terms that can be understood by the audience – and also the skill to use the tool.

    • Sharon Burton

      Greg, I agree with you and don’t. There are lots of times it’s appropriate for non tech comm people to be creating the base content and then give it to more trained people for re-write/edit. I’m working with a client right now for whom that’s a valid workflow for good business reasons.

      The answer is: It depends.

  4. On the other hand, if it were easy, we wouldn’t need to be the highly skilled professionals we are. They could just replace us with trained gibbons.

    Still, you’re right: it shouldn’t be this hard. Especially the part about engaging SMEs and getting them to review our stuff. Sure would be nice if we had a workflow where SMEs and reviewers could work in an uncomplicated WYSIWYG format, professional writers could work in an authoring environment that’s moderately complex without being intimidating, and experts could come in behind the scenes to add metadata, modify XSL transforms, and other assorted bits of sorcery.

Trackbacks/Pingbacks

  1. Wrapping up your content strategy - […] Content development vendors don’t have it quite right. Read more… […]

Leave a Reply

Your email address will not be published. Required fields are marked *