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

Auditing Documentation and Processes at tcworld11

Auditing your documentation, and your processes, can help you to gauge estimates and issues as you prepare for localization or content migration. That’s what I learned in Kit Brown-Hoekstra’s useful 2-hour workshop at tcworld (tekom’s international half).

You can easily do the audit yourself: Take a little time, step back from your documentation, and identify weaknesses and areas for improvement. Acting on your audit results, you can

• Improve customer satisfaction
• Decrease localization costs
• Establish a baseline and a direction to develop your documentation
• Calculate costs and benefits of changes

If you don’t have an express mandate for the audit, it can be worth it to do sort of a “draft audit”. It may come out a little patchy in places, but I think it can give you a first idea of where you stand. With the initial results and measures you can more easily get the time to do an in-depth audit. (But don’t be surprised if colleagues or managers hold you to the improvements you’ve uncovered… :-))

What to audit

The organization level

Perform a strategic SWOT analysis of Strengths, Weaknesses, Opportunities and Threats of your role in your organization. Internal strengths and external opportunities (mainly) will give you useful arguments to get buy-in from management for changes and further developments you plan. Internal weaknesses and external threats (mainly) help you to assess and manage risk as you proceed.

• Strengths, for example, may include technical expertise and an understanding of user needs and tasks.
• Weaknesses, for example, are poor self-marketing or resistance to change.
• Opportunities, for example, can include agile development (which gives writers a better position in the process) and social media (if you adapt to them and moderate augmenting user-generated content).
• Threats, for example, might be smaller documentation budgets or social media (if you do not adapt or cannot keep up with user-generated ontent).

Note how threats can be turned into opportunities, if you tackle them wisely! Or vise versa…

The process level

Assess your documentation process through all stages:

Requirements > Design > Writing > Review > Edit > Localization > Publication > Feedback > Modification > Deletion

Answer the following questions:

• Are all stages well-defined?
• Is it clear when and how you get from one stage to the next?
• Do all participants in a stage know what to expect and what to deliver?
• Can you measure the success of your process?

For the sake of an efficient process, imagine each hand-over between participants or stages as an interface and try to define what’s handed over when and how as well as possible.

The product level

Identify qualities and issues of the product you document to distinguish them from those in your documentation. Weaknesses in documentation often mirror weaknesses or issues in the product, e.g., a poorly designed user interface or a workaround that’s required to complete the user workflow.

You need to know about these issues separately, because they hurt your documentation, but you usually cannot fix them yourself. You can only supply band aid.

The documentation level

Assess the structural quality of your documentation (not the quality of a manual or each topic). Answer these questions:

• Do you have a suitable information model? This is an architecure that defines the structure of your documentation on the level of deliverables (such as a manual or online help) and on module level (such as a topic or a section).
• To what extent does your documentation comply with that information model?
• Do you write documentation so the topics or sections are reusable?
• Do you reuse topics or sections to the extent that is possible?
• Do you write documentation so it is ready and easy to localize?
• Do you use standardized sentences for warnings and recurring steps to minimize localization efforts?
• Do you leave sufficient white space to accommodate for “longer” languages? For example, German and Russian require up to 30% more characters to say the same as English.

Also assess the content quality of your documentation (now look at some manuals and topics):

• Is it appropriate for your audience and their tasks?
• Is it correct, concise, comprehensible?
• Remember to audit localized documentation, too.

It’s usually enough to audit 10-20% of them to spot 80-90% of the issues.

Audit for efficiency

• Be objective. …as objective as you can, if you’re auditing your own documentation.
• Collect issues. You can use a simple spreadsheet to collect your findings: Enter the issue, its impact, its current cost, and the cost to fix it.
• Prioritize improvements. Ensure that a lower future cost makes the improvement worth doing, after you’ve added up the current cost and the cost to implement the improvement. Start with changes that cost the least and will save you the most.

Bonus tool

To really dive into quality assessment of your documentation, you can totally combine Kit’s audit process with Alice Jane Emanuel’s “Tech Author Slide Rule” which focuses on content quality. Use both and you have a good handle on your documentation – and more improvement opportunities than you can shake a stick at!

Your turn

Do you find this helpful to audit your documentation? Do you know a better way? Or do you think it’s not worth it? Feel free to leave a comment.

Content strategy day at tcworld11/tekom11

Scott Abel hosted a full day of content strategy talks with many big shots of the industry at tcworld11 (the international half of tekom11). Strategies and case studies by Joe Gollner, Ann Rockley & Charles Cooper, Aaron Fulkerson (of MindTouch), Rahel Ann Bailie & Geoff Roberts, and Noz Urbina were followed by a panel discussion for which Ray Gallon joined them.

The content strategy panel, left to right: Scott, Joe, Rahel, Ray, Ann, Noz, Charles. Click to enlarge. Photo by @umpff, used with permission.

Highlights of the sessions

Joe Gollner on intelligent content strategies

Intelligent content, said Joe, is actionable information that exposes itself to people and machines. Such content (think tool-independent XML) is shareable, portable, resuable, findable and hence manageable. This makes content a strategic asset that can be leveraged to achieve business goals.

An integrated content solution requires 7 steps:

1. Define the content strategy as a goal-oriented action plan
2. Analyse what content you need
3. Design how you put your content together
4. Explore and learn about your content
5. Transform your content to make it intelligent (and loop back to 4.)
6. Validate your content to confirm it’s intelligent
7. Deploy and use it (and loop back to 1.)

Aaron Fulkerson on help 2.0 strategy

Documentation should live up to marketing’s promise, said Aaron, but instead it’s too often a crappy pamphlet in the shiny box. A better, a 2.0 version of help lifts customers over Kathy Sierra’s passion threshold in a social help center.

Aaron presenting benefits and key features of the Social Help Center. Click to enlarge.

A social help center turns documentation into a social learning experience, and it doubles as your customer relationship management center. Supply the documentation basis and empower your existing client base to augment it: Enable peer-to-peer learning for all the unique search terms on the documentation long tail that your documentation does not or cannot cover. Once you install success metrics, you can even use documentation to find what customers use and need to drive sales.

For an example of a social help center (built using MindTouch), visit http://wikihelp.autodesk.com/.

To read more about Aaron’s argument, see his Forbes’ article “The Evolution Of User Manuals“.

Two dimensions of content strategy

I came away with a extended take on content strategy. I still believe that content strategy means to break down silos between different producers of content within an organization, for more efficient and effective communication with consumers, whether they are customers or colleagues.

But now I think there are two dimensions of content strategy, with different scope:

• Breaking down content silos among content stakeholders is a daunting task for a technical communicator: You need to get product management and marketing, training and customer service, along with your colleagues, all in the same boat. But depending on your corporate culture, this might still be something that can be driven from inside tech comm, with enthusiasm and a clear mission.
• Larger corporate content strategies, as Joe and Noz presented them, essentially change the way an organization works. You still need all stakeholders on board, but you also need a mandate from management, a budget, and most likely some consulting help.

I asked the panel whether such a corporate content strategy could be taken on from within the organization, for example, by the tech comm team. They replied:

• Better not. You only get one shot, so you can’t afford to blow it. Better get the help of an experienced consultant who speaks management’s language.
• Most of it. Because consultants don’t do the actual work, they teach and enable technical communicators.

In the end, I think I saw the vanguard of content strategy and learned as much about this exciting field in a day as possible. I may well have seen one future of technical communications and will benefit from knowing its principles and objectives.

But a mismatch between the message and the audience remains: Much of what I learned seemed directed at managers, but not something I could apply in my current job as technical communicator.

So for now, I’ll stick with breaking down the silos which is more within my reach. For a more applicable example, check my post on Ray Gallon’s webinar about “Content Strategy for Software Development”.

But I’ll watch out for the corporate content strategy, so I don’t miss the boat when it sails… 🙂

Your turn

How do you think content strategy applies to technical communicators? Feel free to leave a comment.

tekom11 & tcworld11: Two worlds under one roof

My first visit to tekom/tcworld, the world’s largest tech comm conference in Wiesbaden near Frankfurt, left me inspired and overwhelmed.

Two floors of tekom, photo by @donormal, used with permission

Impressive numbers

I’ve been attending the trade fair part of tekom for several years, but this was my first time attending the conference. 2011 marks the 30th anniversary of the conference with impressive numbers:

• 200 presentations, workshops and tutorials (78 in English)
• 15 topical streams, ranging from content strategy and mobile documentation to localization, open standards and technical authoring
• 2,500 expected delegates at the conference plus another 1,000 at the trade fair
• 200 product vendors, service providers and associations exhibiting at the fair

Two worlds

The crowds mixed well, and I saw many Germans in English sessions (including my own). I talked to several people, and we all noticed that English and German sessions “felt” different, illustrating cultural habits I often find in documentation as well:

• Corporate visions and innovations often drive English-speaking sessions which often seek to engage delegates with easy to digest images and charts. Some German-speaking attendees are skeptical of such entertaining fluff.
• Methodology and processes often inform German-speaking sessions that seek to inform delegates of the right – or at least the best – way of doing things. Some English-speaking attendees find this staid or academic.

Axel Regnet also has a good analysis of this cultural rift in his German blog post.

My personal highlights

Understanding the Help 2.0 Revolution

Scott Abel’s keynote opened the first day. He presented a case study of ifixit, the socially-enabled “free repair manual that you can edit”. Their crowd-sourced documentation rewards authors with reputation, attention and a feeling of generosity. It drives sales of hardware parts and even allows to calculate ROI by product, manual, and author! There’s also a standard initiative of omanual.org, backed by guys behind ifixit.com and O’Reilly.

Scott Abel's keynote at tekom, photo by @donormal, used with permission

After some smaller or more theoretical examples of user-generated contents, it impressed me to see a working example on this scale. But then again, it’s like the cry from that vanguard to my own industry just got a little farther. More applicable to my own situation were a few insights from the next panel:

Have a question about TC? Ask the experts

Nicky Bleiel organized a panel discussion with Mark Clifford, Sarah O’Keefe and Scott Prentice. I had submitted a question that echoed Roger Hart‘s rant at TCUK:

Will technical communicators own content strategy or will they be overtaken by content strategists, information architects, UX designers who simply market themselves better? In other words, will influence (and jobs) follow skills or clout?

Some answers (to this and other related questions) were fairly obvious but, of course, valid:

• Tech writers need to continue to hone their skills and to widen their turf lest they be pushed aside.
• Tech writers must understand and argue their tasks and expertise in terms of the business.

Some arguments offered me a new perspective:

• Follow the content: Technical communication, content strategy, information architecture, knowledge management all offer different paths and different approaches to ultimately overlapping or identical content. And we tech writers need to contribute to that content in a productive way.
• Follow the role: Regardless of what the actual function is called in an organisation, we tech writers need to make sure we contribute to the efforts of the Chief Information Officer – or whatever that role is called.
• The competition is fierce: Many tech writers are essentially up against everybody else, and their contents need to beat Google’s results.
• The big disconnect is closing, as the distinction between retail and corporate information and user experiences disappears.

Content strategy day

Scott Abel brought eight content strategy experts to tekom for a full day of presentations and discussions, see the separate review.

Auditing your documentation

Kit Brown-Hoekstra presented a dense 2-hour workshop on the why and how to audit your documentation and processes, see another separate review.

Your turn

Whether you’ve attended tekom/tcworld or not: Feel free to leave a comment if you see things differently or to ask if you’re curious about a detail.

Join me for “Getting ahead as a lone writer” at tekom

If you’re attending the tekom conference in Wiesbaden, consider joining me for my updated presentation “Getting ahead as a lone writer” on October 19 at 8:45 a.m. in room 12C as part of tekom’s international, English-speaking tcworld conference.

tcworld conference at Wiesbaden, Germany, in October 2011

My presentation will be an updated version of the session I did at TCUK 10. I will talk about how to overcome neglect and raise your profile by running your job (more) like a business with best practices. Here’s the abstract:

Lone writers are often the only person in the company who creates and maintains documentation. They often operate without a dedicated budget or specific managerial guidance. In this presentation, Kai Weber will draw on his experience to show lone writers how to make the most of this “benign neglect”:

• How you can still develop your skills – and your career
• How you can raise your profile with management and colleagues
• How you can contribute to a corporate communication strategy
• How you can help your company to turn documentation from a cost center into an asset

Twitter meetup afterwards

Join us on Wednesday at 9:35 am on the upper floor in the foyer in front of rooms 12C and D for a #techcomm meetup after the session! @rimo1012 and I, @techwriterkai, are presenting at the same time in adjacent rooms, so if you know us from twitter, stop by and say hi!

I’ll be blogging from the conference, so watch this space…

How tech comm is like – desert hiking!?

This piece has appeared in slightly different form in ISTC’s monthly newsletter InfoPlus+ in October 2011 on pages 14-15.

Desert hiking and tech writing never seemed to have much in common. One is a perfect pastime, the other a job. Little did I know how they both challenge me in similar ways…

@techwriterkai in Bear Canyon near Tucson, AZ

In my day job, I’m Senior Technical Writer for SimCorp in Frankfurt and Copenhagen: I create and maintain user manuals and online help for our investment management system SimCorp Dimension. We’re currently (as of fall of 2011) using Word for manuals in PDF and an in-house help tool for online help in CHM, but we’re in the process of migrating everything to MadCap Flare for single sourcing.

Many of my professional tasks are pretty standard: I document newly developed or enhanced features in topics for release notes and user manuals. I try to make sense of the product and the underlying specifications. I seek out SMEs (subject-matter experts) for help when I’m lost on my own. I consolidate topics into user manuals. I try to pace myself well so I finish in time, even though I don’t really know how long I’ll take when I start.

I really enjoy my job for its interaction with different colleagues, for the joint effort to deliver a good, useful product. I sit in an office, divide my time between my PC and my colleagues – and I regret when sunny summers outside pass me by. Which is where my other life comes in.

Hiking canyons and desert floors

For about 15 years, I’ve been an avid desert hiker of the American Southwest. Day trips only, thank you very much – I’m not out for any “Survivor” trips. As I’ve explored the Chihuahuan, Sonoran and Mojave deserts on foot, I’ve come to appreciate, respect and love them intimately. I know the cacti and the bushes and detect animals and their tracks. I recognise the clouds, the friendly, fluffy ones and the fateful ones about to release a monsoon. I enjoy the hues of the sky, the orange at dawn, the deep blue before noon, the purple at dusk. I relish the smells, the herbal sagey dryness and the creosote’s syrupy resin after a rare rain. I move among the sounds, above the crickets’ chirps on the ground, beneath the canyon wren, a small fella of a bird who sounds like he can’t get his pickup truck started.

Walking in solitude, I let go of the words that I harness as a technical communicator. Often they accompany me on my trails, swirling around me like a flock of birds that feed on the only spirit for miles around. As they dissipate, they reveal my passions to myself and the challenges I enjoy.

Enjoying the challenges

There’s the trail that’s hard to find, as it crosses sheer rock or has been washed away by recent flooding. It gives me pause, not unlike an unknown, new feature without anyone around to ask how to proceed. Nothing left to do, but take a few steps back, try one way, evaluate, weigh, try another and decide on the most promising path, while allowing for the possibility of error. Like that one hike up a wash with no guidance other than the park ranger who mentioned a rock arch on the canyon’s rim to the right and a slot canyon to the left.

Then there’s the difficult, challenging terrain that taxes the body, not unlike difficult, unknown concepts that tax the mind. That’s the time for patience and endurance, focus and concentration, because I know that carelessness can get me into trouble. Like that hike down and up the Grand Canyon when there was no doubt about the path, but the steep climb back out is just really strenuous…

Regardless of the path and the terrain, I need to plan well and pace myself, before time and provisions run out. I only carry a limited amount of water as I set out and don’t know exactly how long it will last me. But with experience, I can gauge better how fast I will have move to make it in time. At work, time is my water: I don’t know how long I will take when I set out on a new manual. Experience helps me to come up with a reliable guess. But there’s always the risk that I lose my path and don’t know how to proceed. Or that the terrain proves unexpectedly difficult.

The most important lesson, however, has been this: If something goes wrong – don’t panic! I just need to pick up the pieces, retrace my last steps if necessary, and carry on. Moving faster or taking shortcuts usually doesn’t work, but will only wear me out faster.

At the end of the day, if I’m lucky, both hiking and technical communications leave me with a feeling of satisfied achievement. I appreciate both, my job and my pastime, and the balance they afford me.

Your turn

Do you have a hobby or pastime that could teach you something about your tech comm occupation? Or am I just over-identifying, seeing tech comm everywhere? Feel free to leave a comment.

Why TCUK is such a cool conference

Technical Communication UK (TCUK) has established itself as a leading tech comm conference in Europe, because it combines expected features with more quirky, informal elements of “unconferences”.

Pivotal programming

Part of the success comes thanks to a well-balanced mix of sessions. This is the “meat and potatoes” that covers the usual suspects of methods, tools, and technologies. It also excels by reaching out into neighboring disciplines. This year a whole stream of sessions was dedicated to “anything but text”. These presentations (and a couple of keynotes) went all visual and covered icon design at Google Maps, IKEA’s textless communication, technical illustrations, colour usage, video in user assistance, and more.

TCUK audience, photo by @FireheadLtd, used with permission

Fascinating fringe

Unconference features, such as lightning talks, a rants session, and a fringe program, make up the rich dessert buffet. They inspire and foster an accessible sense of community among delegates who want to carry ideas and conversations into less formal contexts. Fringe events ranged from meetups of user groups or regional ISTC groups to a film screening, from informal social get togethers to the latest instalment of the legendary annual salsa class.

Committed community

That sense of community is what makes TCUK unique to me: Beyond getting the logistics right of putting on a conference, these worthy folks hit the sweet spot by establishing a framework within which stuff can happen. The amiable atmosphere draws delegates together, whether they’re there as repeat speakers or just for one day. I’ve met someone determined to make the most of his one day, and he was hooking up with people left and right everytime I saw him between sessions.

Three-and-a-half takeways

What did I take away from TCUK 11?

• A feel for where the tech comm industry is at. Technical communication is as dynamic a field as ever and there’s no better place to take a temperature than conferences such as TCUK.
• Learn to think and act outside the box. Thanks to the good programming, I got a lot of insights and inspiration. This goes for tech comm topics, such as personas and minimalism. And it extends into other applicable areas, such as being a riveting speaker and interpreting and visualising statistical data.
• A long-term perspective. Perennially repeated discussions are such as “What do we call ourselves and why?” are legitimate and important. But we also need to think in terms of progress, how we tech comm’ers want to the industry develop and in which direction(s). Fittingly, the final sessions did a good job whether it was Ellis Pratt’s closing keynote or Roger Hart’s compact 3 minute rant that content strategists have little on us, but still might do us in.
• Tech writers will be tech writers. You can’t stop a bunch of tech writers from editing a dinner menu. You just can’t…

Your turn

If you’ve attended TCUK 11, what were your impressions? You probably took something else away… Feel free to leave a comment!