Not being interviewed by BBC Radio

I was due to be recorded/interviewed first thing this morning over the phone for a piece a BBC local radio station was going to do about instructions and how get written. I was standing in for the President of the Institute of Scientific and Technical Communiators (ISTC).

However, a producer called this morning to tell me they couldn’t stand up the facts that had prompted them to look at this subject (regarding some instructions in a Homebase product), and they’d decided to shelve/postpone the item. I also suspect the Charlie Hebdo killings have (rightly) taken precedence over other stories today.

I’d spoken one of the producers the day before. What they were interested in knowing was, how do instructions get written? She said she wouldn’t know where to start or what to do. We chatted about the technical writing process: how technical communications learn about a product; how they work out what topics need to be written; and how the instructions themselves are organised.

It was nice for them to have contacted the ISTC, and perhaps it will be something they pick up again in the future.

Five predictions for technical communication in 2015 and beyond

It’s time to put our heads above the parapet, make ourselves hostages to fortune, and predict what will happen in technical communication in 2015 and beyond.

1. “User Churn” will lead to SaaS providers looking to assist users in better ways

The move towards Software as a Service (SaaS) has led to organisations worrying about “user churn” – if users give up using the application after only a short period of time, the company won’t generate enough income. This means it’s becoming more important to assist the users when they begin to use the product.

2. Organisations will take a more holistic approach to communication with users

We’re seeing organisations looking at the all the ways it communicates with users, and making sure they are consistent and supportive of each other. For example, the training emails sent out to new users, the User Interface text, the Help and the training videos.

3. Software developers will see Help as part of the product design, as first user Help grows in popularity

Instead of seeing the user documentation as almost as an afterthought at the end of the project, we’re seeing organisations considering the first user interaction Help you see in mobile applications. This has to be planned into the UI itself, which means technical writing can no longer be left to the end of the project.

4. Microsoft’s greater level of informality in its Help will be copied by others

Microsoft’s “No more robot speak” programme, which has lead to a more empathic and informal tone will be noticed by more companies. We understand Microsoft has only spoken officially about this change twice; it’s likely that many organisations will misunderstand what Microsoft is doing and make mistakes when they try to adopt a similar approach.

5. DITA will make slow progress

It’s easy to forget that the DITA technical writing standard is used by fewer than 10% of technical communicators. When the Lightweight DITA standard approved later in 2015, it may become easier for smaller organisations to adopt DITA. However, the adoption of DITA is likely to continue as its current rate – a slow, but steady 1% per annum.

Your predictions?

A lot of these trends actually began some time ago, but we’re likely to see them adopted more widely in 2015.

What you see as future trends? Use the Comments box to let us know.

The four words that account for 19 minutes of a typical Technical Communicator’s day

Peter Norvig has some interesting statistics on word frequency in the English language. It turns out that four words – the, of, and, to – account for 16.94% of the words we write.

In field of technical communication, Technical Authors typically spend 50% of their time writing and the rest on researching, planning etc. If we adjust for the fact that these four common words are half the length of an average word in English, that means Technical Authors spend an average of 19 minutes every day typing those four words. In a 37.5 hour week, that amounts to 1 hour and 35 mins.

The need for empathy in technical communication

One of the subjects Doug Kim covered in his TCUK14 presentation, on the changes to Microsoft’s user documentation, was how Microsoft now normally begins its Help topics with an empathetic statement. The writers seek to understand the user at the moment they’re reading the content.

For example, if someone is reading the topic on auto save, it’s likely they’ve just experienced a crash and have lost some data. So they express empathy by saying, crashes happen:

Microsoft Help screen

By doing this, Microsoft is moving away from the norm – the generally accepted way to structure task topics in DITA and other standards is to dive straight into the task without any introduction.

We think Microsoft has go this right – there is often a need for empathy in technical documentation. Of course, this is difficult if your content could be reused anywhere – you lose the understanding of the user’s point of view. However, being empathetic, from the research Microsoft carried out, is what users, today, prefer.

See also: Trends in Technical Communication Course – Advanced Technical Writing Techniques

Draftback – could it reveal how Technical Authors actually write?

James Somers is releasing an add-on for Google Docs, Draftback, that enables you to play back and analyse the creation of any Google Doc you have permission to edit.

It means you can see how a writer created the document, the sections they spent time rewriting and rearranging, the elements that were pasted into the document from elsewhere, and so on.

From an organisation’s perspective, the graphs Draftback that produces potentially could be used to show when and where the writer spent most of their time:

Timeline of activity

I could see this illustrating the impact of last minute changes to a product, review comments and other external factors. Potentially, it could also highlight areas where a writer might need assistance or training.

What do you think?

Cherryleaf “green screen” videos

We’ve been putting together some short length videos that we can use on the Cherryleaf website. These are “quick and dirty”, three to four minute videos, shot behind in front of a green screen.

One explains why technical communication is changing:

Another looks at recruiting a Technical Author:

Each video takes a couple of hours to create, and we hope to add more over time.

Microsoft’s “No more robot speak” in action

 

Our post about how Microsoft is changing its writing style (Microsoft moves away from “robot speak” in its user documentation) generated a lot of interest, so I thought it might be useful to post some examples of it that we’ve spotted.

These examples are from Office 365 Premium Edition.

Continue reading

Reframing technical communication as marketing

We’ve noticed a few slidedecks and blogs recently that have been looking at the value of technical communication in marketing a product successfully. With the trend towards earning revenues over a lifetime (rather than in a single upfront payment), the marketing strategies employed by organisations is changing.

Scott Abel has posted a slidedeck called “The Future of Technical Communication is Marketing”, which you can see below:

Acrolinx has also been posting blog posts on a similar theme, such as How Technical Communicators Help Build Customer Relationships and Building Customer Relationships: Why Content’s in the Driver’s Seat.

Marketing is becoming, particularly on the Web, about designing User Interfaces for prospects and for customers.

Technical Authors will need to understand how marketing is changing in order to understand and explain how they can add value to that activity.