Tech comm meets content strategy, with Ray Gallon

Technical communications and content strategy have a lot to say to each other.  Bloggers have frequently related the two disciplines. Tech comm conferences run streams on content strategy, for example, tekom11 dedicated a whole day to the topic.

Content strategy for software development

Ray Gallon at tekom. Photo by @umpff, used with permission.

Leave it to Scriptorium and their excellent webinars to shed some light on the situation. Recently, they invited Ray Gallon to present his “Content Strategy for Software Development“. (To learn more about Ray, read his recent interview over at the Firehead blog. Or you can check out the very similar presentation which Ray held at tekom.)

Ray’s presentation was very enlightening to me, because he applied content strategy to software development. I create documentation for software applications, so I can relate to creating content for them. In the following, I’ll mainly focus on the first half, but I recommend watching the entire webinar.

Software development as information-rich environment

For the sake of his argument, Ray set the stage by looking at (complex) software developments not as products or tools, but as information-rich interactive environments. Software could thus be an expert system that supports users to make an appropriate decision, e.g., a medical diagnosis.

The first question to content strategists is then: What does the user need from the software? There are several answers; the user may need to

• Know something (relating to concept topics)
• Do something (relating to task topics)
• Explore or understand something
• Integrate or combine the software with his other tasks and processes

Plan to help your users

Ray then presented several document types which help content strategists to plan how they can best support users in their tasks and decisions. Among them was the Content Requirements Worksheet:

Ray Gallon's Content Requirements Worksheet explained. Click to enlarge. (Pardon the mediocre quality; prezi > WebEx recording > SlideShare is one compression too many...)

This document was a real-eye opener for me. It represents a holistic view of all user-facing content in a software application:

• Informational, editorial content
• Structural software content, such as user interface messages
• User guidance, such as tool tips, help screens
• User decision support to help users do the right things for the right reasons
• Dynamic content, such as search results
• Live interactive content as preesented in forums and social networks

Content workers, unite!

The Content Requirements Worksheet can be very beneficial to future users of a software. But it presents a challenge to content strategists to get a wide variety of requirements right. That is the opportunity for technical communicators and user experience designers and information architects to pool their skills and join forces.

As Ray said in his comment to my previous post:

Many tech comms do a bit of, or a lot of, content strategy in their work, and if an organization has a content strategy then everyone, tech comms included, needs to understand it and be on board.

So let’s transcend the silos of our systems, their manifold features and the artefacts we’re used to creating. Let’s start with good, thoughtful design from which our users benefit.

Your turn

Is this a good way to relate content strategy to technical communications? Or do you know better ways? Feel free to leave a comment.

Advertisement

All aboard! Onwards to structured authoring!

Our team of technical writers is embarking on a journey towards structured authoring. With 10 writers, we’ll move from an unstructured Word to PDF/CHM environment to a structured Flare to WebHelp/PDF environment. Or I should say “semi-structured”: We do have an information model based on DITA, but we won’t actually be able to enforce it with Flare (which we knew before we chose the tool).

It’ll be an interesting cruise, to be sure! Four writers already apply topic-based authoring rather than the previous free-form documentation guided mainly by common sense. The others have had training, but no real opportunity to write topics continuously. We have drafted tighter new processes to draft, write, review and edit topics to replace the previous loose processes of writing and reviewing, but they are not in place yet.

And then there’s the new tool, of course. Only one of us has worked with Flare before. Many of us are excited about getting Flare. Some really like it – what we’ve seen in several demos so far. Others just really loathe the current writing environment.

“Regarding the pain of others”

So as we’re about embark, I’ve been looking out for others who’ve taken the trip before. Scriptorium’s State of Structure webcast has been very helpful: Its results of a survey among 200 tech communicators helps to position us in relation to others who are currently implementing structured authoring or considering it. It also collects some mistakes respondents have gone through. I’ll just be quoting a few select points, but the whole webcast by Sarah O’Keefe is totally worth checking out, so thanks to Scriptorium for making this webcast available!

Reasons

The top reasons why survey respondents (consider to) move to structured authoring made us nod emphatically: Reuse, consistency and cost savings are also at the top of our wish list of achievements. Looking ahead, it’s promising that the majority of respondents achieve these goals.

We’ll also take other goals that respondents achieved, whether it’s to automate processes or to reduce content (oh, yes, please, we’re not even exactly sure how much redundant, almost identical content we have). So far we’re confident, we’re not only doing the right thing, but doing it for the right reasons, too!

Efforts

Savings have their own price, of course. Sarah’s survey confirms several cost points we’ve already identified in the project.

• Converting legacy content is a biggie for us, simply because we currently have a lot of stuff.
• Redefining output layout will take time, but will be worth it given what Flare is capable of doing with CSS in both web and print outputs.
• Integrating a new system with its writing and publishing processes into our product and workflow systems will also take some time.

Mistakes

Mistakes have been made by others before us, and we’ll have plenty of chances to make our very own mistakes. If we’re lucky, we can avoid repeating the mistakes of others:

• Planning and project management cause problems, maybe because most companies lack the experience of major documentation overhaul projects. Sarah specifically mentioned the lack of understanding of the project scope and of the need for testing. So we’ll look through our project plan again and ensure that the estimates are plausible.
• Converting legacy contents can also get you into trouble, especially when you convert something that’s less than structured. It doesn’t help if you reserve too little time to do it or get inexperienced people to do, whether it’s off-shore labor or student helpers. That’s sound advice: GIGO (“garbage in, garbage out”) can certainly endanger the expected benefits. A new tool can help us be more efficient, but we still have to learn and apply structured writing in topics. So this confirms one of my two tech comm dogmas: Don’t get a new tool to fix your processes!

Setting out

What do you think? Is our crew well-equipped, given a tried and proven method, well-defined processes, a new tool and the words of warnings above? If you have additional advice, please leave a message.

Trends in technical communication 2010

Tech writers will branch out into related organizational and technological functions, according to the transcontinental webinar on “Technical Commmunication Trends for 2010 and Beyond“.

Sarah O’Keefe from Scriptorium, Ellis Pratt from Cherryleaf and Tony Self from HyperWrite gathered around a virtual crystal ball and shared six trends they’ve indentified.

I’ll summarize and comment on two of the trends that have resonated with me. The recording and slides are available on the web, so be sure to check out all six trends…

Shape an emotional user experience

Ellis sees that documentation will leave its detached attitude behind: Instead, it will be part of a more personable, emotional user experience that’s driven by mutual trust, community participation and brand loyalty. So documentation should be planned as part of a more holistic user experience. Look for docs going touchy-feely is what I was hearing.

I find that very fascinating and engaging – I’m just not sure I really see it. I’m all for making documentation trustworthy and engaging, to empower users and solicit their feedback. But unless you have somewhat homogenous user groups and know them very well, you might rub some of them the wrong way: What’s amiable to some is inappropriate to others.

Much also depends on context: If your product is hip, chime in with hip documentation, why not. But for many professional products, especially in regulated environments such as medicine or pharmacy, I’d rather play it straight to be taken seriously.

Include content curation

Sarah argues that documentation will include content curation, that is the evaluation, editing and incorporation of other people’s contents. As part of larger content strategy, tech writers get to deal with user-generated content and information by colleagues in a company where “everyone can write“. So in addition to producing content, tech writers also become gate-keepers, similar to a newspaper editor or a librarian.

Sarah added that you’ll still have to draw the line due to technology and regulations: You obviously can’t curate sources that are beyond your control (such as third-party blogs), and regulated industries may require you to keep official documentation and user contributions strictly separate.

I think Sarah’s hit on a good compromise between inviting community participation on the one hand, but retaining some (quality) control over the contents on the other hand. I believe such a curating role would make the available content more valuable by presenting it in context and by directing user attention – not unlike a museum curator does!

In fact, content curation is a good description for what I find myself doing frequently: Rather than creating contents from scratch, I collect and aggregate it, write up a nice label (like a wall text, so people know what they’re looking at) and in general make it presentable.

Your turn

What do you think? How do you see our role in the changing tech comm landscape? What does your crystal ball show? Please leave a comment.