We explain things

Danielle M. Villegas has just pointed us towards a five minute lightning talk by Rick Lippencott on the future of technical communication, and its value. Rick covers in five  minutes a great deal of the content I covered in my 45 minute presentation at the same conference – it’s worth watching.

He summarises the value of Technical Authors in three simple words :”We explain things”.

Rick added some notes to the description on YouTube:

The clay tablet “first example of tech documentation” is about ten thousand years old, not two thousand.
The odd photo at about the 4:50 mark (where I say any of us could have explained it better) was a hotel room layout map posted at the elevators. It gave room locations based on compass points, but there was no way for the reader to know which way was actually north. It was completely useless.
“All of this has happened before, and it will happen again” was originally from Peter Pan.

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 “Nine myths about technical writing”

UK General Medical Council’s solution for reducing prescription errors? More usable, better designed forms

The BBC News today has a great example of the impact procedures documents and usable forms can have upon people’s lives. It reports the General Medical Council is is calling for a UK-wide standard prescription chart as the best way to reduce the 9% of hospital prescriptions that contain a mistake. Against common opinion, the study found it wasn’t  doctors fresh out of medical school who were making the most mistakes – the causes were mostly down to poor forms and bad handwriting.  

The chairman of the GMC, Professor Peter Rubin, said:

 “Prescribing decisions in a hospital setting often have to be made quickly, so it is important that a procedure is as simple as possible to minimise the chance of an error being made.

To avoid confusion as doctors move between hospitals with very different prescribing forms – including paper and electronic – the GMC wants to see a standardised system across the UK.

A Department of Health spokesman said it would continue to look into the benefits of electronic prescribing systems,

 “taking into account the evidence gained where standardisation of the paper chart has been successfully implemented.”

Dr Hamish Meldrum, of the doctors’ union, the BMA, said:

“It would certainly help if there was greater uniformity in the prescription forms used in the NHS and the BMA would encourage prescribing procedures to be kept as simple as possible.”

 It’s good to see recognition, in such an important area, of the value of good procedures writing and form design.

BBC’s Rory “Read the manual? Never!” Cellan-Jones discovers the need for manuals

I wonder if the BBC’s Technology correspondent, Rory Cellan-Jones, is regretting posting an article in August called “Read the manual? Never!” . In it, he said:

It may be sad that we no longer seem to have that thirst for knowledge about how things work. But I’m afraid I’m just not going to start reading the manual.

I say this, because in his recent Blog post about Google Wave, he complained about the lack of user guides for the application:

We saw a lot of bugs that still need fixing, and no very clear guide as to how to do so.

Rory’s experiences with Google Wave – unfamiliar concepts, uncertainty between features and bugs, unfamiliar tasks – illustrate why it’s not always possible to do away with the need for user documentation and user assistance.

To his credit, when I pointed this inconsistency out to Rory, via Twitter, he said “it’s a fair cop!!!”.

Can you design your way to a “no user documentation” approach?

Chris Edwards has written an article on product design in the E&T magazine called “The art of avoiding lemons“, in which he looks at whether there is more to product design than simply getting your design to look good or your product to work. He shows there are many situations where brilliantly designed products still fail.

Managing customer expectations

Edwards quotes findings from Elke den Ouden and colleagues at Eindhoven University of Technology and Philips Applied Technologies, who found that half of the consumer electronics products returned to stores worked just fine: the customers simply had not been able to figure out how to get them to operate properly.

According to den Ouden:

For businesses today, the main risk with respect to quality and reliability of new products is not just technical failures, but also failures of a non-technical nature, that is, complaints due to the product not meeting the consumer’s expectations.

He also cited findings from a 2006 report by consultant Sara Bly and a team from Intel Research and the University of Washington, called “Broken Expectations in the Digital Home“. This report listed:

A litany of failure by consumer-electronics vendors to provide products that did what the users wanted. And yet each product surveyed did, at least nominally, what it was designed to do.

Connectivity – A series of unfortunate events

In addition to the broken expectations also mentioned by den Ouden, Bly stated the reasons for these failings were partly due to users being unable to connect one device to another. This complexity issue has also been highlighted by research into how small to medium sized enterprises use IT. Dr Alan Rae’s “Abandoned Heroes” report stated similar findings, where a single individual in the business often had to rely on their own self-taught expertise and felt ill-equipped to carry out the implementation tasks required of them.

Meaningless dialog boxes and error messages

Edwards also claims that users can be stumped by error messages. He quotes Don Norman:

(Product designers) assume perfection, a smoothly operating ticket machine, always performing smoothly and efficiently.

If we also consider Rachel Potts’s article, “3 good reasons software will always need help“, where she argues users may need key concepts and context explained to them, then we may come to understand why dialog boxes such as the one below may need some explaining:

No amount of good design will help you understand a “wiggle factor of 4”, if you have no understanding of the concept of “wiggle factors”.

Different users on the Rogers Technology Adoption Lifecycle Curve will have differing requirements

At last week’s UA Conference Europe 09, IBM’s Mike Hughes made the great point that the adoption of technology over time will have an impact on the effectiveness on your design.

He said that different types of users will have different expectations and needs for documentation. Sometimes, all you need to tell users what is a good choice. At other times, you need to explain how to do things, step by step.

My thoughts

For simple, commonly known actions in a closed environment, you probably can design your way to a “no user documentation” approach. Good design can also lead to less documentation. However, customers may expect to do more than that with a product and, in those situations, documentation can play a key role in meeting those expectations.

Technical authors, documents and getting lost

Via Twitter, someone responded to one of my messages with the statement, “maybe, if you need a manual, it’s a poor product”. I don’t think that’s the case, and my reply on Twitter was:

“A map is to a city, what a manual is to an application.”

Let me explain.

Imagine you need to visit a city. You can find your way around using the signposts, if you wish, or by “using your nose” to wander around. However, you may never discover the best way to get from A to B. You might also miss some really important points of interests. A map can help. A map can show you how to get to where you want to go in the most direct way. It can help you find places that are not easy to find. This is also how a manual works.

If you see a building, you might want to know if it’s worth visiting. In this case, a travel guide can help you make that decision. It can help you plan and prepare your journey. Again, a manual often serves a similar function. 

You can improve the signposting and make the navigation more intuitive. Many cities are laid out on a grid pattern, for this purpose. However, that doesn’t mean a map no longer serves a purpose. Similarly, you can improve the usability of an application, and still have a manual that adds value to the user.

I’m a Technical Writer – Dispelling the myths

Technical Writers (aka Technical Authors, Content Wranglers and Documentation Managers) have an unfair image as probably the last type of person you’d like to meet at a party. Fictional writers tend to portray them as agoraphobic social misfits.

We aim to challenge this image, by showing technical writers in a different light – by posting photos of technical communications professionals doing a variety of activities.

See www.imatechwriter.com or www.cherryleaf.com/imatechwriter.htm

If you are involved in technical writing and you’d like to be included, contact us and send us a photo, together with your name and location (only photos suitable for viewing at work please).