The future of technical documentation is more about psychology than technology

In the quest to offer better forms of user assistance, most experts in the technical communications profession propose technological solutions: using XML, intelligent and adaptive content etc. to present essentially the same type of guidance as has been provided for the past 20 years.

We believe there has been a change in the relationship between people and technology, and there needs to be a corresponding change in the relationship between people and the user documentation.

In the past, a lot of technology was unfamiliar, idiosyncratic, expensive and complex; users often became anxious when they used a product. As technology has become part of everyone’s daily lives (particularly Web and mobile applications), people’s relationship with a great deal of technology has changed.

As a consequence, for some types of products and for some types of documents, the traditional approach for technical writing is no longer appropriate.

This means Technical Authors need a better understanding of this relationship – the psychology of users – and understand how they can relate and communicate to users in context.

We are not suggesting that the traditional approach to technical writing should go away completely. We’re also not arguing against technology such as XML and DITA – these are vehicles for delivering content. We’ll still be writing user documentation for scientific equipment and financial systems in the traditional way, as these types of products fit the traditional model. However, even the documentation for these types of products can benefit from the inclusion of some psychological techniques.

Web sites such as voiceandtone.com indicate some of the changes that we are likely to see in technical documentation, but we disagree with some of the approaches suggested on this site for some types of documents, and we feel this site only scratches the surface.

There is evidence from randomised control trials that these new approaches work, although we recommend you carry out your own testing to double check it works for your users.

So having come to be belief that Technical Authors need to incorporate some new techniques into their documentation, what should happen next? One approach is to engage Cherryleaf to provide advice or write documents. In addition, you’re able to discover these techniques through our new advanced technical writing training course. However, the starting point is to recognize the change in the relationship between users and many products, and to recognize the need to change the approach to technical writing so that it’s appropriate to the situation.

The question is, do you agree?

The over optimistic user

On Dara O’Brien’s Science Club (BBC 2) this week, neuroscientist Dr Tali Sharot explained “Optimism Bias”, suggesting that our brains may be hard-wired to look on the bright side.

Here is her TED presentation on the Optimism Bias:

Nearly everyone is optimistic they will never get divorced, and they are an above average driver, when statistically that’s just not possible. It seems reasonable to infer that users of software are  also over optimistic, believing they are an average or above average user in their ability to use an application.

This has an implication for those developing user documentation and training. It seems likely that most people will believe they don’t need to read the documentation (or receive training) when they actually do.

Is it time for a new writing style in technical communication?

While there have been huge leaps in the technology used to create and publish user documentation, it’s been quite a while since there were any serious changes to the writing style in technical communication.

Here is a rough timeline for technical communications standards, according to xml.org:

  • 1961 Quick Reader Comprehension (QRC)
  • 1963 Hughes STOP – (Sequential Thematic Organization of Publications)
  • 1967 Information Mapping
  • 1974 SGML
  • 1982 Information Types
  • 1990 Minimalism and task orientated instructions

See also History of technical communication in 7 minutes video.

The writing style has essentially remained the same for at least 20 years.

So what about DITA – isn’t that new? DITA was introduced around 2002 (and approved as a standard in 2005), but it’s more about structuring and organising information around Information Types such as task, concept and reference. Is the style of writing for DITA any different from the writing style for minimalism?

With the new insights we can gain from web analytics, psychology and other data, is it time to see if we can make improvements to the writing style used by most technical communicators?

See also:

Webinar – Planning user documentation when you’re a startup business

We’re currently working on 40 minute webinar on:

  • Planning user documentation when you’re a startup business

If you have any questions on this topic, you can email these to us prior to the event. We’ll do our best to make sure we address them in the webinar.

Send us an email with your question

Details on the date for this webinar will be published in the Events section of the Cherryleaf Web site.

 

How much content can you actually re-use when you move to single sourcing?

One of the challenges when considering moving to a single sourcing authoring environment, such as DITA, is determining the Return on Investment. This often boils down to a key question: how much content can you actually re-use?

Organisations typically attempt to answer this question in a number of ways:

  • Conducting a semi-manual information audit of the existing content to identify the number of times the same chunks of information is repeated. Unfortunately, this can be a large and lengthly exercise.
  • If the content is translated, getting reports from Translation Memory tools indicating where content might be repeated. Unfortunately, if you’re not translating your content, you won’t have this information.
  • Using benchmark industry measures. Unfortunately, these can vary enormously (from 25% to 75% content re-use), and your situation may be totally different.

In an ideal world, you’d be able use an application that could look at all your content and give you a report telling you the where content is repeated. It could do the “heavy lifting” in the information audit automatically for you. This programmatic analysis of reuse within existing content, at an affordable cost, is now starting to become possible.

Continue reading

Need content written? Need a Technical Author?

Need content written?  Cherryleaf’s Content Development Services team can help: clear information, written for you, simply and efficiently:

Need a Technical Author? Cherryleaf’s Recruitment Services team can help: the specialist recruitment service for permanent and contract Technical Authors.

Call +44 (0)208 13 31 301 or send us an email.

 

Nine myths about technical writing

“We can design away the need for a user manual and online Help”

The idea of a product that totally is intuitive to use, the product that sells itself, sounds terribly attractive. Often these are called commodities, and consumers tend to go for the cheapest one, or the one with the best brand image.

There are situations where good intuitive design can sell successfully, and the Apple iPad is probably the most well known example. However, even iPad users seek Help and want user guides.

iPad books at Heathrow Airport

iPad books at Heathrow Airport

Continue reading

Technical Authors and the reverse classroom movement

It’s “back to school” time, and, in the UK, it’s a time when the way schools teach and test students is being debated to a great extent.

The “reverse classroom” or “flip teaching” is a new approach that is being promoted as a way to teach in this Web-savvy, “always on” age. According to Wikipedia, the reverse classroom is:

a form of blended learning which encompasses any use of Internet technology to leverage the learning in a classroom, so a teacher can spend more time interacting with students instead of lecturing.

Instead of lectures and then homework, the idea is that students self-study and then use the teacher to help them solve problems.

This is essentially the Help and Support model used in the software sector: the users self-study, using online Help, “For dummies” books, user manuals and screencasts. If they cannot solve the problem themselves, they then ask an expert to assist them in finding the answer.

What this means for Technical Authors is there is a lot of research and debate being carried out into establishing the best methods for people studying and helping themselves. Indeed, teachers are using technical communication tools such as Camtasia to deliver the learning materials.

It will be interesting to see if Technical Authors can apply any of ideas and techniques that emerge from the reverse classroom movement to give users better forms of User Assistance in the future.

Measuring the value of Help in desktop applications

One of the challenges for Technical Authors is quantifying the value of what they produce. For example, how can you tell how many people are reading online Help when the software is installed on someone’s desktop computer? One application mentioned in passing as last week’s UAEurope conference, ApplicationMetrics, might be able to provide the answer.

ApplicationMetrics collects usage and platform data, behind the scenes. It’s a product that is no longer being developed any more, but you can still download it. It may enable you to collect “operational funnel” data that’s similar marketing funnel data – test and track whether users are going to the help and resolving their issues.

 

Why Technical Authors make the best Project Managers for Agile projects

Red Gate Software’s Dominic Smith mentioned in his presentation at UAEurope conference that the company had found Technical Authors were ideally suited to take on the role of Project Manager for small Agile software development projects. In fact, Red Gate had morphed most of its Technical Authors into to a hybrid Project Manager role.

Dominic made a strong case why Technical Authors made good Agile software project managers:

  • They are focused on the user
  • They understand the user
  • They understand a lot of the technological aspects
  • They are used to delivering projects on time
  • They are more extravert and people-orientated than programmers (yes, this is broad generalisation)
  • They ensure User Assistance isn’t forgotten in the project plan, and that it is considered from the very start
  • They can provide a business focus to the project, and are able to kill projects that don’t make business sense any more.

Do you agree?

Disclosure: Red Gate is a client of ours.