Our Webinar in August will be: From Technical Communication to Content Strategy

MadCap Software has asked me to present, as a webinar, one of my conference presentations from the  MadWorld 2014 conference - Bust a Move: From Technical Communication to Content Strategy.

In this webinar, we’ll look at how technical communicators can get more involved in corporate content strategy. We’ll look at why they might want to do that, the differences between technical communication and content strategy, as well as looking at how they might re-position themselves. We’ll also look at what tools and skills technical communicators can bring across from the technical communications field.

It was a popular session at the conference, standing room only in fact, with 20 minutes of questions from the audience at the end.

This webinar will be held on the 12th August at 4.00pm BST (8:00 am Pacific Time), and it’s a free event.

I’m afraid there was some confusion over which presentation from MadWorld 2014 we would be repeating, and I mistakenly stated the webinar would be on metrics. That was my mistake. We’ve also had to move the webinar from its original date on the 13th August to the 12th August. Sorry for any confusion caused by these changes.

Ellis

Technical communication as a brand

Flickr image by Ruper GanzerOne of the tea break discussions at the Congility conference I spoke at last month was over the need to improve the awareness of technical communicators and technical communication as a profession.

I suggested the profession would benefit from having (and promoting) a simple positioning statement that explains the profession as if it were a brand. This is something I believe Tekom, the German professional body, did in the early 2000s. Tekom carried out some research in Germany that suggested as many, if not more, people were carrying out a technical communication role as part of another job, and that they were not aware the profession of technical communicator existed. So they aimed some of their marketing efforts at these groups, to make them aware of the profession. They wanted to see if they could bring these people into the Tekom membership.

In fact, I think there should be two statements to improve awareness of the profession:

  1. One saying there are these people called technical communicators who could help your business.
  2. One aimed at people who are writing technical documentation, but don’t realise it is a profession, with a professional body, standards etc. that could help them do it better.

Looking at the STC and ISTC sites, there are some useful simple descriptions of the profession. I’ve used content from these two sites to come up with the following description for the first statement:

“Technical Communicators are professionals who take technical and complex information and make it clear to people who need to understand and use it.

They have skills in providing the right information to the right people, at the right time. They communicate by using technology such as Web pages, Help files or printed content.

Having clear instructions can make all the difference to users of products or staff carrying out tasks. That’s because the need for accurate and accessible content has never been greater.”

We hope to progress this idea a little bit further, and produce something that the ISTC, the professional body for UK technical communicators, and ourselves could use.

Do you think the description we’ve used could be improved? If so, please use the comment box below.

What would life be like if there were no instruction manuals you could read?

Illiteracy is, sadly, something that can greatly affect people’s lives. According  to The Literacy Trust, less than one per cent of adults in England can be described as completely illiterate and approximately 16 per cent as “functionally illiterate”.

There are various articles on the Web that indicate how people live with their illiteracy:

  • They depend on people (relatives or the kindness of strangers) to read and explain things for them.
  • They recognise places and the location of things based on colours or shapes.
  • They often have to trust people aren’t scamming them.
  • They generally work within more limited boundaries, keeping to a consistent routine.
  • They often memorise how they completed a task last time.

If we produce a product but do not supply user instructions with it, the user has nothing to read, whether they are literate or not. The user has to fall back on coping mechanisms similar to those used by people with illiteracy. They can function, but they would do much better if they had something to read.

Writing troubleshooting topics

It’s a fair bet that the introduction of the new Troubleshooting information type into the DITA 1.3 technical authoring standard will affect how all Technical Authors write troubleshooting topics, regardless of whether they use DITA or not. That’s because the proposed elements for troubleshooting topics make good sense, and it offers a standardised approach to writing these types of topics.

According to the Oasis DITA standards committee,

Troubleshooting topics provide descriptions of and solutions or workarounds for problem situations that users might encounter. Users refer to troubleshooting information to understand what condition or event generated their problem situation and to find out what they need to do to recover from or work around a problem, or to prevent a recurrence of the problem.

The user would see a topic that looks roughly like this:
Continue reading

Why you probably shouldn’t use Word to create your policy documents

Flickr image "Holmes McDougall Employee Handbook" by Edinburgh City of PrintImagine you are an IT manager for an organisation that has been implementing new IT systems. You have now reached the point where you need to create and document the new IT policies and procedures. The organisation already has some general policies for IT in its staff handbook, but you need to provide more detailed information on how to use the organisation’s IT efficiently and securely.

For example, the staff handbook tells staff that customer information must be treated confidentially and only approved communication channels must used. The IT policy and procedures document will provide more detail  - that web email services (such as Yahoo Mail) must not be used to send customer information, because they often store a copy of the email even if you have deleted your sent message.

The best approach would be to have some sections in both the staff handbook and the IT policy document. In other words, the same content in different documents. Otherwise, staff would need to have two manuals open each time they wanted to check they were doing things correctly.

If you use Word, you’re likely to do this by coping the text from one Word document and pasting it into the other Word document. The problem with this approach is that when you make a change to the text, you need to remember to paste any amended sections into the other document. This make it very difficult to create customised variations of documents, such as cut down versions for managers or new staff, branch-specific versions etc. It becomes unmanageable.

One of the benefits of using some of the alternatives to Word is you can embed a piece of information into multiple documents. In a similar way to how you can use the same image in lots of different web pages, you can use the same chunk of text in lots of different documents. The advantage of this approach is that in the future you’ll only need to change the source, embedded chunk of text when it’s time to make a revision. That piece of text gets updated automatically (or semi-automatically) in all the documents that use it.

Reputation Management – Can user documentation help quash rumours?

Photo of a tiger in the streetIn the ‘Whispers’ episode of BBC Radio Four’s Digital Human programme, Aleks Krotoski explores how rumours spread both online and in the physical world.

As an example, she looked at how two people were able to spread a rumour that a tiger was running loose in London during the 2011 riots.

Aleks claims we are now in a world of misinformation. For organisations, this means they now have to pay attention to any misinformation or rumours about their products and services, an activity that is often called ‘reputation management’.

Seven minutes into the radio show, Nicholas DiFonzo of the Rochester Institute of Technology states groups believe rumours typically because there is a lack of information from official channels, they don’t trust official channels, or because their friends believe it. People use rumours to figure things out.

This means if there is a gap in information, then rumours may fill that gap. For this reason, it’s important organisations publish their Help files or equivalent on the web, so that there isn’t any uncertainty over what your product can and cannot do. If you don’t, whatever Google serves as an alternative source of information will fill in the gap.

Where people might not trust the official marketing content, they are more likely to trust the technical, instructional information. It’s seen as more ‘truthy’.

What do you think?

Please share your thoughts, using the comments box below.

Is there gender bias in your Technical Author job advert?

Simon Morisawa-Bostock pointed me towards an article on gender bias in job advertisements (You Don’t Know It, But Women See Gender Bias in Your Job Postings):

A scientific study of 4,000 job descriptions revealed that a lack of gender-inclusive wording caused significant implications for recruiting professionals tasked to recruit women to hard-to-fill positions underrepresented by women.

Researchers studied gender wording in job advertisements and job descriptions and the effect of gender wording on job seekers. The researchers first established that women’s style of communication is more communal, using more emotional and social words than men’s style of speech.

The researchers linguistically coded job descriptions found in a U.S. Department of Labor database that were predominately populated for masculine-themed words such as active, ambitious, analytical, competitive, dominate, challenging, confident, decisive, determined, independent, leader, objective, etc., as well as feminine-themed words such as committed, connected, cooperative, dependable, interpersonal, loyal, responsible, supportive, trust, etc. The results confirmed that job descriptions for male-dominated jobs contained more masculine-themed words associated with male stereotypes than job descriptions from female-dominated jobs and vice versa.

Alarm bells ring in my mind when people talk about “a women’s style of communication”. As a number of commentators at the end of the article pointed out, many of the words and phrases the researchers identified as “gender-themed” could also be attributed to differing personality and behavioural styles.

Technical Authoring is a profession that has a roughly 50:50 gender split, requiring some so-called masculine traits (e.g. independent, analytical, active) and some so-called feminine traits (e.g. committed, connected, cooperative, dependable, responsible, supportive). However, there are some “masculine” traits you wouldn’t normally associate with the role and expect to see in a job advert - such as competitive, dominate, challenging, confident, decisive and determined.

We do receive, on occasions, job descriptions that don’t really reflect the attributes associated with successful technical communicators. Part of the value a specialist technical author recruitment agency provides is to reword job descriptions so that will attract the right type of candidates. I took a brief look at some of the recent job descriptions we’ve received from clients, and I couldn’t find any evidence of a dominance of “masculine” or “feminine” words in the job descriptions. From that perspective, there was no particular bias that needed to be mitigated.

I  looked at whether some of the “masculine” words appeared in job adverts for Technical Authors posted elsewhere on the Web. Again, there seemed to be no particular bias. Having said that, there were a few notable examples:

“As Technical/Training Author you must boast a great knowledge and experience in technical authoring, a demonstrable record of producing high-quality technical documentation and materials within a software product environment, and experience of training external clients and internal teams. … This role demands a confident, client facing Technical Author who is at with working in a software house.”

“As an exceptional Technical Author you will be adept at delivering reader-friendly, technically accurate and complete product documentation on time to demanding schedules…Our client is looking for only the most exceptional and talented candidates – true rockstars of their profession.”

I suspect these organisations will struggle to find suitable candidates.

What do you think? Have you seen inappropriately worded job descriptions for Technical Authors? Share your thoughts below.

RoboHelp 11 review (finally)

robohelp logoAdobe released its latest version of RoboHelp Version 11 (and Technical Communications Suite 5), a while back and asked if we could write a review. There have been a number of excellent reviews, so we’ve been wondering what extra we can say. We’ve decided to address some of the questions we’re often asked by organisations when they’re deciding which Help Authoring Tool to choose.

Continue reading