Tech comm trends 2012, mashed up and commented

2012 is the year when tech comm’ers need to understand business processes and align documentation with new technologies, say tech comm pundits – and yours truly.

What I expect for 2012

Tech comm’ers need to understand business processes.

Okay, so this trend is not exactly new, but I expect it will gain traction this year. Scott Abel thinks so, too. Business processes are crucial for us tech writers in more ways than we might think. Ideally, we understand them in three domains:

  • In tech comm, we need to understand business processes to do our job efficiently, to improve how we work and to measure if (or prove when) we are understaffed.
  • In our employer’s business (or whoever has ordered the documentation we provide), we need to understand processes to contribute to the bottom line and to get out of the cost center corner.
  • In our customer’s business (or whoever uses the documentation we provide), we need to understand processes to ensure these customers or users are efficient and happy with both, the product we describe and the documentation we create.

In a nutshell: We need to know business processes, so we know which are the right things to do, whether it’s moving our documentation to a CMS, aligning our deliverables with the corporate content strategy, or updating our personas. At the same time, we need to hang on to our tech comm skills, so we know how to do things right.

What others expect for 2012

Here are two trends predicted by Sarah O’Keefe and Connie Giordano that resonated with me. (And I recommend you follow the links to get the experts’ predictions first hand!)

Creating documentation moves to the cloud.

Documentation will follow other content production to the cloud, such as collaborative Google Docs, blogs, and wikis. With this trend, I’m wondering:

  • Compelling event? Will cloud-based tech comm creation take off now – or do we need a more compelling event than ubiquitous access and the (alleged) lower operational costs?
  • Whose market? Will conventional HAT vendors be the major players, so their customers can keep their sources and move them to the cloud – or will HAT vendors (and tech comm’ers sources) be disrupted by other providers?

Documentation design aligns with mobile UX.

Tri-pane web sites are too large for effective user assistance on mobile devices which require new, condensed documentation designs. These will in turn feed back into other documentation formats. Here, I’m wondering:

  • Turf wars? Will tech comm’ers and UX designers engage in turf wars – or pool their skills and resources for better user assistance?
  • Innovation? Will the reduced real estate lead to genuinely new ways of presenting user assistance – or to a resurgence of minimalism?

What no one expects for 2012

The survival of the classical tech comm job profile

Virtually all tech comm predictions and trends for 2012 are driven by external forces of change: The cloud, mobile devices, or new social media habits which expect collaborative documentation and user-generated content.

At the same time, the trends and predictions I’ve seen show little initiative to define or advance technical communications as a profession around a set of skills and tools, methods and processes. The classical tech comm job profile (as described in the Occupational Outlook Handbook by the U.S. Bureau of Labor Statistics, for example) that is centered around deliverables and tools, formats and styles seems to wane.

In many sectors, technical communications has instead become a function that contributes to corporate assets and the bottom line. Technical communicators provide it, as do content strategists, information architects or UX designers. And whoever pays them doesn’t necessarily care who does it – or even know the difference.

In a way, this is the other side of the coin of the trends above. Scott Abel points out:

The real value we provide is not our mastery of the style guide. Rather, it’s our ability to impact the customer experience in positive ways.

And Connie Giordano calls for the evolution of “integrated technical communications” to coordinate and integrate

all technical communication processes, tools, functions, and sources within an organization to convey information and knowledge relevant to optimizing the users’ product experience.

So I believe technical communications is here to stay – but we may have to look for news ways of selling what we do and deliver.

What do you expect for 2012?

Will you follow the trends above? Are there others in your future? Please join the discussion, leave a comment.

Advertisements

8 Responses

  1. I agree that tech writers need to learn more about business processes, particularly if you’re interested in IT.

    If you’re not familiar with the Business (Process) Analyst role and the tools they use, take a look at the ToC of “The Business Analyst’s Handbook;” http://amzn.to/wvm8xv . BAs focus more on requirements documentation, before code is written, but they often document internal applications for IT staff as well as end users.

    Some of the BA practices that tech writers should (re)consider:
    * Structured information-gathering meetings with all SMEs.
    * Use cases and diagrams that provide context and workflow detail
    * Collaborative rewriting: SMEs participate in a walkthrough of the doc

    • Thanks, Charlie. I wasn’t aware of the BA Handbook, but it looks like an excellent resource for tech writers to get over the dogma “I don’t care about the requirements wish list; I need to know what we’ve actually built!”

      The three practices you mention are a great start because they link straight into the tech comm workflows and deliverables! (I can feel my brain running off with this as I type, so you probably started something good with your comment…)

  2. Agree; the traditional job description is already gone for me. As of 1/1, I am now an Information Engineer. I’m writing content for Help systems, helping to design the UI, analyzing agile user stories, managing blogs and producing videos.

    • Thanks, Patty. I’m still fine with the tech writer moniker – however, I also do most of the tasks you mention. 🙂

  3. One of my earliest satisfying memories as a tech writer occurred when I got a product manager and a developer in a meeting to talk through a draft document. The dialog went something like;

    The product manager said, “This is wrong. If the user does A, then the application does B.”

    To which the developer responded “No, that’s the way it works.”

    “Well,” replied the PM “it shouldn’t!”

    Customers got a better product and a better document.

    • Thanks, Charlie, as chance has it, I’ve just heard something similar around the office. It’s good to see that documentation works to improve the product, especially when it eliminates mistakes that escaped testing before customers have to find them..!

  4. Thanks for the mashup. I found your comments on the UX of mobile help documentation particularly interesting. I wonder if we’ll see help become more and more integrated into its target applications given the limited mobile screen real estate (similar to the trend towards client-side form validation).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: