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

Not so cool tools for Technical Authors – speech recognition software

Our method for creating online courses involves making an audio recording of the presenter, transcribing it, editing the script and then recording the final, video presentation. We’ve tried using speech recognition software to create the transcribed script, and it has been a deeply frustrating experience.

While speech recognition is proving successful for searching and issuing commands (using Siri, Google Voice and Amazon Echo), we’re not sure it will replace the keyboard as the way we create written content.

Continue reading

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?

Stenography for Technical Authors?

Steno keyboard

This tweet caught my eye:

It linked to an article The 100 Year Old Trick to Writing at 240 Words Per Minute:

About four years ago, stenographer Mirabai Knight came to the conclusion that stenography had been a walled garden for too long — controlled and marginalized by big companies. She set about creating her own affordable hardware and open source software designed to set stenography free to the masses…

Note that this keyboard does need to be able to recognize multiple simultaneous keystrokes, so gaming keyboards (starting at $50) are the norm.

This could really help us when we’re transcribing the scripts for our online training courses. We’re not aware of any Technical Authors who use stenography – is there anyone out there?

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

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

Topic-based authoring: The undiscovered country

NT Live Hamlet Many software companies, when they start out, provide user documentation as downloadable PDFs or as web pages. As they develop more products and versions, and as they expand into countries that use different English spellings, the amount of documents can grow until it becomes hard to keep all of these documents up to date.

It’s at this point that they tend to call a specialist technical writing company (such as Cherryleaf) to see if they can fix the problem for them. We find they’ve usually had a brief look at a Help Authoring tool, such as Flare or RoboHelp, and can see that it would solve a lot of their problems. However, they’re often not really sure how to use these tools in the best way.

Although topic-based authoring has been around for over twenty years, for many people it’s a completely new concept. It is, to quote from either Hamlet or Star Trek VI, an undiscovered country. Our meetings with them often end up focusing on the benefits of topic-based authoring.

Topic-based writing is an approach where you write a piece of text (or topics) that typically contains a paragraph or two about a single topic. These topics can be combined to create a page in a PDF document, and they can be organised in a sequence to create an online Help system ( See topic-based authoring page in Wikipedia). It’s a modular approach to creating content. The main advantage of this approach is the topics are often reusable; you can save time by reusing topics across different documents, and you can publish the same content to different media. For example, you could use a topic in training courseware, in a user guide and in marketing information.

As each topic is usually about a specific subject, and has an identifiable purpose, it can also help the writer write more clearly. If you need longer articles, you can build these up from the topics you’ve created.

It’s easy for professional Technical Authors to forget sometimes that many people have never come across this approach to writing before.

Getting information from Subject Matter Experts

Flickr photo an interview by illustirInterviews with Subject Matter Experts (SMEs) are some of the most useful sources for Technical Authors when they are gathering information about a product or procedure. This often involves asking a developer or departmental manager a series of questions focused on the types of questions end users are likely to ask.

Interviewing is one of those dark arts that Technical Authors pick up over time – techniques for getting SMEs to find the time to speak to you and review your drafts, ways to avoid conversations meandering away from what the user will want to know, tools for capturing the interview, and so on.

So what tools should you use?

Coming armed with biscuits (cookies in the USA) is probably the most effective tool! After that, the most useful tool to have is a voice recording device. If you have a smartphone, in effect, you have a digital voice recorder. There are many voice recording apps for both iOS and Android, but the one we like is Recordium.

Recordium

In addition to recording audio, Recordium also enables you annotate the voice recording. You can highlight and tag certain parts of audio recordings (for example: to indicate a new topic or to mark sections that relate to definitions of terms etc), and add attachments to those sections as well. You can use it, in effect, as an audio-orientated note clipping application, similar to Evernote.

Recordium also enables you to vary the playback speed. We’ve found this useful when SMEs are using specialist terminology – you can slow down the recording to check what it was they actually said. Listening at a faster speed is also a useful way of reviewing a recording quickly.

Technical Authors still need to transcribe sections of the interview, so it becomes text. Unfortunately, Text-to-Speech applications still have some way to go. Dragon Dictation is available for Apple devices, and ListNote offers similar functionality for Android. However, even if you are just a two fingered typist, you’re probably better off transcribing the audio yourself.

Are there any other apps you’d recommend? Let us know.