Nokia’s David Black provided an excellent opening keynote presentation at the TCUK 2010 conference, where he described the documentation produced by Nokia and predicted a bleak outlook for all but the most technical of Technical Authors.

David’s team works mostly on developing information for developers and partners, rather than end users. He revealed that 50% of all reported defects were due to inappropriate use of code – code that wasn’t documented. He also explained that if the documents led to a reduction of just 1 in 10,000 defects, then it paid for his department’s budget for the year.

Although he felt no-one but Technical Authors had the answers to how to understand complexity and failure, he believed that products would become so intuitive, and people would be so technically adept, that there would be no need in the future for end-user documentation.

This idea of a product that is “so intuitive anyone can use it” is like the “product that sells itself” – a rare beast. Often, we need marketing and sales professionals to explain what a product means to us, and we need information to explain how to use something once we have it.

I argue there will still be a need to explain technical stuff to non-technical people. This may not be true for mobile phones, as they are used for hours on end every day. Where you are explaining technical stuff to technical people, then David is on the button. However, in most cases, there will still be a need to explain technical stuff to non-technical people. The popularity of “For dummies” and “missing manual” guides shows there’s an appetite for simple explanations.

Kevin Kelly wrote for the New York Times Magazine recently about achieving techno-literacy. Here are some quotes from his article:

“Every new technology will bite back. The more powerful its gifts, the more powerfully it can be abused. Look for its costs.

Before you can master a device, program or invention, it will be superseded; you will always be a beginner. Get good at it.

Every technology is biased by its embedded defaults: what does it assume?

The closing keynote presentation of TCUK 2010, made by J Haynes, Chairman of the Haynes Publishing Group, contained advice useful not only to those creating manuals but also to any organisation looking to communicate information to others. John went through the 50 year history of Haynes, publishers of the Haynes manuals, and explained the reason for the company’s successes and failures.

“Whatever the subject, all Haynes Manuals are ‘hands on’ and are based on the founding principle on which the first manual was created: we do the work, we take the photographs, we create the notes and we tell the truth about how hard or easy a task is. It is the clarity and honesty of this simple methodology, created to help anyone interested in undertaking a practical challenge, that has made Haynes an iconic brand trusted by millions.”

He also explained why many professional mechanics choose to use a Haynes manual over the manufacturers’ guides:

They are consistent in their structure. As all the manuals are structured in the same way, people know where to look for a particular piece of information.

They are consistent in the use of symbols and diagrams. A wiring diagram for a Ford uses the same symbols as the wiring diagram for a Volkswagen.

As there’s no common standard between manufacturers regarding how a manufacturer’s service manual should be designed, it’s difficult for mechanics to move from one type of car to the next, unless they use a Haynes manual.

This recipe for success – Clarity, Honesty, Findability and Consistency – is surely not only true for car manuals, but also for any business looking to communicate effectively.

In research for my presentation today on the emotion factor in technical documentation, I came across a recent case study in the US where changing the writing style had resulted in a 13% increase in readership. It took me a few days to realise that a 13% increase must have quite an impact on the business.

Let’s assume that results in an extra 10% reduction in support calls. That means you could demonstrate your work as a technical author will result in a 10% saving in support calls. That’s quite an improvement to be able to offer, particularly in the current economic climate.

TED’s Chris Anderson says the rise of Web video is driving a worldwide phenomenon he calls “Crowd Accelerated Innovation” – a self-fueling cycle of learning that could be as significant as the invention of print.

He claims

What Gutenberg did for writing, online video can now do for face-to-face communication…Information often can be taken in faster by reading it, but there is a necessary depth and richness that is often missing…In fact our brains are exquisitely wired for the medium of video.

But to tap into its power, he claims organisations will need to embrace radical openness.

Here is his 18 minute presentation:

If he is correct, what does that mean for technical authors and others who are writing instructional manuals?

His presentation is based on the assumption that video is available on demand, that we live in an ‘always on’ connected world. It also doesn’t take into account the fact that in Europe video chat on mobile phones never took off, yet text messaging has exploded.

Clearly video will play a role in technical communication, and this is something I’ll be covering in my TCUK conference presentation next week (on creating an emotional connection with users). It will also be the theme of my article on “The emotion factor” that’s due to be published in the November 2010 edition of the STC’s Intercom magazine.

What’s more likely is we’ll see a blend of both video and the written word – two mediums that require different skills to deliver effectively.

Health and safety is built around good practice. There are systems for getting things done and processes for carrying out the tasks required to make the organisation successful. The problems occur when the paperwork outweighs the operator’s willingness to read and digest it!

Standard practice in most organisations is that every time something new occurs policies must be developed and manuals need to be written in order to drive the process.

The senior management team have access to this weight of knowledge, but the front end workers either don’t want to (and don’t) read all that information or they’re forced to read it and don’t fully understand it. Worse still, they do their job in spite of, rather than because of, the bureaucracy that sits above them.

So the issue is how do you get people to do things right without expecting them to read manuals (which they probably won’t – and won’t remember) and still create a safe working environment? A folder of information may exist, but it doesn’t really help the operatives to know the specific gravity or flammability level of any substance they have to handle.

Rewriting the legislation as a ‘policy’ is unnecessary – regulations are about systems, not strategies.

First a strategy needs to be developed to form the base from which the systems and processes will be developed.

Then a system needs to be created and not by finding one that exists elsewhere and copying it. If you want a system to work you need to look at the current practices within the organisation in relation to specific regulations and identifying whether they are already compliant, need a bit of tweaking to meet the regulations or need to start from scratch.

For example: those people who handle hazardous substances need to know how to handle them safely and the consequences of not doing so. A card with the substance instructions for use is enough. It may be a list or a flow chart and may have specific warnings e.g. flammable, carcinogenic, irritant, but first and foremost should be simple, straightforward and practical.

Operatives don’t need the strategic documents, a simple basic process with critical information is all that is needed at the operational level.

The system should accommodate how your organisation operates – not be ‘one-size-fits-all’. Every process needs examination and existing processes may need tweaking to meet the regulations. However, there may be opportunities to ask ’do we need this material or could we use something better and safer?’

The operative needs both the simplicity of process and also to understand the impact of getting it wrong. This enables them to make intelligent decisions when things don’t go according to plan.

And the point of all this is that:

Senior management need to develop clear policies;

Supervisory levels need the practical information the underpins the systems and processes,

But the operatives simply need to know what exactly needs to be done, how and why.

As part of my prep for my presentation on user documentation as a more emotional experience for the user, I revisited this presentation by Kathy Sierra. This hasn’t ‘made the cut’ into my presentation due to lack of time, so I thought I’d post it here.