Tag Archives: Reckless writing

5 steps for effective document review

Plain language / Plain English, , ,

You’ve slaved away for weeks on an important document. You’ve researched and talked to people. You’ve worked hard to understand your audience, their needs and how they will use your work. You’ve carefully structured the content into sensible chunks and you’ve used plain language techniques as you’ve crafted the text.

But, will the document work? Will it achieve the goals you had in mind?

It’s time for the document review and test phase. Time to find out what other people think of your work. Or perhaps time to send it ‘upstairs’ for sign-off.

Too often authors simply e-mail the document around to colleagues in the office with a message like “I’ve written this. What do you think?” If they don’t hear anything back they assume it’s all OK. But a review process like this rarely provides confidence that the document will communicate effectively. In fact, such a sloppy document review process could be reckless writing. (Our writer training course can reduce costly review churn.)

All communication products should be tested well before release, just like any other product. (Why don’t we test information products?)

So, when you ask people to review a document focus on assessing how well the document will achieve purpose.

Try these 5 steps:

1. Develop thick skin.

People may suggest improvements to your writing (and, by implication, improvements to your thinking). It’s easy to become defensive about the structure and words you have used. Don’t be. If someone finds your message is unclear then you need to improve it.

2. State your purpose clearly; identify your audience.

People can only provide useful review comments when they know what the document is intending to do, and who it is aimed at. When asking for review, explain who the document is for, and how you would like people to respond to your document. Judge the feedback you receive in the light of your purpose and audience.

3. Identify real users.

Representatives of your target audience are the best people to tell you how well your document will work. Anybody else is guessing (although experienced reviewers usually guess well).

4. Prepare document review questions.

Questions help reviewers engage with the material. For example:

  • Does this document contain information or ideas that are important to you?
  • Can you easily find the information you need?
  • Once you find the information, can you understand it?
  • Does it tell you too much? Does it tell you too little?
  • Is the information correct? Could it be misleading?
  • Does it comply with the law (if relevant) and our internal standards (if they exist)?
  • Do you know what to do now that you have read this?

5. Make feedback easy

Tell people how to get their comments to you. Do you want them to talk to you about the document, email you some ideas, or insert their comments in your text? And tell reviewers when you expect their comments.

You don’t need to act on all the review comments. Exercise judgement – some comments will be helpful, some will not. Use feedback to improve your writing, but don’t be bullied by it. After all, it’s your document, so take ownership of it.

The risk of writing functional documents and web content

Plain language / Plain English,

A functional document (including web content) is a document that readers have to do something with. Functional documents include contracts, reports, advice, disclosures, fact sheets, policies, procedures, terms and conditions, letters. Most documents written by businesses and government agencies are functional documents.

Whenever you write a functional document you are taking on risk.

Whenever you write a document that people have to rely on in some way, there is a risk they may not understand, or may not get the full picture, and so act in a detrimental way.

A fundamental principle of plain language is that the writer takes prime responsibility for the communication. You can’t blame the reader if they don’t get it. You may not be able to blame the reader even if they don’t read the document. The question is shifting from “Did you read the document?”, aimed at the reader, to “Is the document readable?”, aimed at the writer.

We generally consider risk by thinking about likelihood and consequence; thinking about the likelihood a reader may misunderstand your document, or not read all of it; thinking about the consequence of a reader acting on missing or confused information.

You can probably predict likely consequences. For many documents, risk will be low because the consequences of misunderstanding are not that bad.

But you can only know about likelihood by testing the document. You can only appreciate how people are likely to read and understand your document when you run it past a sample of real users and observe their reactions and thoughts.

You can prove you have taken document risk seriously by having your document certified.

Has this insurance document been written recklessly?

Plain language / Plain English, Thinking & writing,

Reckless writing: Preparing a document without a deliberate and considered concern for readers, or a writer failing to apply their mind to consider how a document will be understood.

A friend read this statement in his Schedule of Insurance:

This Policy also covers your legal liability in respect to loss or damage to third parties’ goods caused by your negligence and whilst such goods are in your physical or legal care, custody or control.

“Sweet”, he thought, “I won’t need that extra insurance on my hire car. My liability policy will cover me if I have an accident.” – a reasonable conclusion, and something a reasonable person would expect to be covered in a business liability policy.

But the insurance company denied the claim after a minor accident in the hire car.

Buried deeply in the policy (page 15 of 22) was an exclusion clause – a ‘gotcha’. The exclusions started on page 10 with

This Policy does not cover any liability;

Five pages later, after wading through a poorly organised and long list of excluded items, processes and events is this:

23. Vehicles
for Personal Injury or Property Damage arising out of the ownership, possession or use by the Insured of any Vehicle:
(i) which is registered or which is required under any legislation to be registered,

There it is in black and white – a registered vehicle, in this case a hire car, is not covered under the policy. The insurance company blamed the policy holder, the reader, for this misunderstanding. The insurance company would likely claim this was a case of reckless reading, but I reckon it’s more likely a case of reckless writing.

A foundational principle of plain language is that the writer, not the reader, takes prime responsibility for effective communication. So, it is never OK to blame the reader.

Why I think this document may have been written recklessly:

  • I doubt the document was tested in any way with potential readers. If you don’t test a product (in this case, a document) how can you have any idea how it will perform?
  • It is unlikely the writer applied their mind to how the document would be understood – the writer likely did not consider what the reader expected the policy to cover.
  • There is no evidence the writer has a deliberate and considered concern for the reader – the policy is primarily designed to limit the liability of the insurance company.
  • The clause in the shorter document (the schedule), the document more likely to be read, does not mention any exclusions.
  • The content of the policy, especially the exclusions section, does not seem to have a logical, reader-based structure.
  • Basic Plain English techniques (familiar words, active voice, verbs, short sentences, conversational style) have not been used consistently.
  • Readability statistics on the policy are poor: Flesch reading ease: 23.0, Flesch-Kincaid Grade Level: 17.9, Passive sentences: 41%. (Readability statistics do not give a definitive measure of how well a document serves readers’ needs, but are a helpful indicator)

Ten tests to avoid reckless writing

Plain language / Plain English, Thinking & writing

Reckless writing: Preparing a document without a deliberate and considered concern for readers, or a writer failing to apply their mind to consider how a document will be understood.

The extent of your testing will be determined by the complexity of your document, your users and what they need to do with the document, and the risk of not understanding or acting on the document.

If you choose not to test, then you are relying solely on own judgement. That could be both arrogant and reckless.

You won’t use all these ideas for every document. Choose the ones most suitable for your purpose.

  1. Ask for comments about the document.
    Ask: What did you think? Did all that make sense?
    Sometimes general, unspecific questions can reveal useful insights about the document.
  2. Use readability formulae
    Tests like the Flesch-Kincaid grade level and the Flesch reading ease score are good basic indicators of the complexity of the text. But they are mechanical indicators only and don’t consider context.
  3. Conduct a structured interview
    Ask questions like: What do you think this means?Anything you are unsure about? What confused you? What did you expect to find? Any sentences you needed to read twice?
    Structure your questions around the document’s purpose.
  4. Devise a multiple choice test
    This will likely focus on testing understanding of the content.
    These tests are easy on participants. However, they may not pick up all the issues with the document, only those predicted by the questioner.
  5. Set some problems to solve
    Ask users to solve a real scenario to be solved by reading the document.
    For example, when testing understanding of a will, you could ask something like: ‘You, your wife and your second son dies. What happens to your house?’
  6. Set a full comprehension test
    This is an extension of a multiple choice test but may include free responses.
    Include questions like: How did you reach that conclusion? What did you find first before reaching your answer?
  7. Response time tests
    Set some comprehension or scenario questions or both.
    Measure the time it takes users to find the correct answer in the document.
  8. Fill in the gaps
    Remove every 5th or 6th word – users fill in missing word from the context.
    This tests overall understanding of the document.
  9. Paraphrase the document
    Ask users to tell the message of the document back to you, as though they were explaining it to a friend.
    This tests overall understanding and whether the document is likely to achieve its intended purpose.
  10. Think aloud
    Ask the user to read each sentence, one at a time, aloud. Ask them to explains their reactions or thoughts after each sentence.
    This will help you understand your users’ thought processes as they read the document.

Publishing a document without testing – is that always reckless?

Plain language / Plain English,

Reckless writing: Preparing a document without a deliberate and considered concern for readers, or a writer failing to apply their mind to consider how a document will be understood.

Any document published by business or government is a ‘product’. A document is the result of creative effort, designed to meet a particular need.

Nearly all physical products are tested before being released to the market. We couldn’t imagine an untested vehicle or drug being offered for sale – the risk is too great. We would not allow people to risk their lives just because an engineer or scientist says “I’ve worked hard and done my best.”; we insist they test their products in some way.

Yet so many information products, documents, are published without being tested, or released after only a low form of testing. They are published whenever the writer says “that’s good enough”. In many cases this amounts to recklessness – an indifference to whether the information is understood, a carelessness about how information is acted on.

Product testing is related to risk. I’ll only do minimal testing on this blog because the risk, both likelihood and consequence, of you not understanding what I am saying is small. But that’s not true of many other types of documents.

Many internal and external documents should be tested rigorously with end users. To not do so is reckless. For example:

  • Financial documents – loan agreements, insurance documents, financial advice and the like. Not thoroughly understanding these types of documents puts users at significant financial risk.
  • Medical information – misunderstanding this information can lead to poor decision making and lifelong consequences.
  • Any document written by government or a regulator – if a user does not understand these documents there is a risk they may break the law, or not receive things they are entitled to.
  • Legal documents and agreements – people must fully understand what they are agreeing to and what they are compelled to do.
  • Procedures, whether for an internal or external audience. Misunderstanding or ignoring procedures (because they are hard to read) can have significant impact.