Category Archives: Plain language / Plain English

Plain language is a style of organising information and writing that focuses on the readers’ (or users’) needs. It considers the intent of the author and what the reader needs to do with the content provided, as well as making sure that information is worded in way that the reader can easily understand.

Write with verbs not nouns

Plain language / Plain English, writing tip, ,

It’s better to write ‘evaluate‘ rather than ‘make an evaluation‘; write ‘decide‘ rather than ‘make a decision‘. ‘Evaluation’ is a noun, ‘evaluate’ is a verb.

Use verbs (action words) to make your writing more lively.

When you write with verbs your writing becomes more engaging and energetic because you are using action words. And it can also help you reduce your word count.

Many noun forms end in …ion, …ent, so keep an eye out for them.

And I’d love to ban the word ‘undertake’- we only ever use that when we need it to accompany a noun.

So we write the wordy phrase ‘we will undertake an investigation’ rather than saying more simply ‘we will investigate’.

Choosing to write with verb forms rather than nouns is a simple change, but it can powerfully improve your text.

Personalise your writing

Plain language / Plain English, writing tip,

Your writing will be read by people, so write directly to them.

Organisations don’t read letters or other documents, people inside them do.

So it’s OK to use personal pronouns – words like you, me, I, us.

Using personal pronouns helps make contact with your readers and creates a more engaging, conversational tone. It helps them better understand how they should respond and what actions they need to take.

Write ‘you must …’ rather than the vague ‘the ratepayer must ….’. Writing directly makes your writing clearer, more accessible, and helps readers feel acknowledged and respected.

This simple shift from third person to second person can dramatically improve comprehension and response rates.

Impress with your thinking, not your language

Plain language / Plain English, Thinking & writing, writing tip,

Some writers deliberately write in a way that makes their text difficult to read.

They do this to create an air of mystique or superiority or to appear more ‘educated’ than their readers. They emphasise the supposed distance between their intelligence and that of the reader by using words that their readers may not know and putting it altogether in long and complex sentences.

This is a pretence! It always gets in the way of good, effective communication.

If you feel you need to impress you readers in some way, do it with the power and clarity of your thinking, not by showing off with your language or vocabulary skills.

And sometimes, difficult writing is simply a cover-up for a lack of clear and insightful thinking. Some writers use complex writing in an attempt to sound profound when they are not really saying anything worthwhile at all.

See related post

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.

Getting the timing right

Plain language / Plain English, Thinking & writing

When should you talk to people?

Timing your communication depends on
– your purpose, and
– the needs and interests of the people you are talking with.

For example, marketers and advertisers know that frequency is important. If you want people to remember your brand, product or service you need to present it to them frequently. Otherwise your competitors will crowd you out. Staying front of mind requires persistent effort. It also requires creativity so people don’t get bored and ignore your frequent communication.

But, if you are trying to get a new idea across, perhaps a new way to solve a complex problem or a change in corporate culture, simple repetition will not do the job. Your communication strategy needs to be designed to match the cognitive processes of your audience. It takes time for people to become comfortable with new ideas.

You could start by talking about your idea in broad terms, then a little later fill in some of the details, and a little later again explain how it will impact people. Introducing new ideas in this way allows your audience to grow their thinking gradually without having to get their head around an entire idea in a single bound.

Dumping your whole idea in a lump may be good for shock value, but it is unlikely to get people on side. In fact it could cause them to be more resistant to your idea, making repetition counter-productive.

Some basic principles:

  • Communication should move thinking –
    from the known to the unknown,
    from the simple to the complex,
    from the familiar to the unfamiliar
  • Take small steps – changes in attitude and thinking take time.
  • Allow people “soak time”, time to assimilate what you are saying. Give them time to ask questions and clarify.
  • Keep the frequency up. Repetition helps; but don’t become a nuisance.
  • Always respect your audience. Don’t dump undue complexity on them. Don’t irritate them with mindless repetition.

Action

Think
– what are you trying to achieve?
– what are your audience thinking now?

How can you build a communication strategy to bring about change?

Effective, less risky procedure documents

Plain language / Plain English, Thinking & writing, ,

Far too often policy manuals, standard operating procedures, work method statements sit on the shelf and are hardly ever used. They are read by quality system auditors every few years, but they are hardly ever used by people in the business.

This is a problem for two reasons:

  1. Developing these documents is costly in both direct writing costs and the time lost by people diverted from their normal work to provide the content. Manuals are an expensive asset – it is important to get a return on investment.
  2. There is often a mismatch between what is written and what is done. Over time small changes are made to processes that are not reflected in the manual. Whether by laziness or an over cumbersome approval system, the end result is a mismatch between what managers think and what workers do – a very risky situation for any organisation.

There is no magic bullet to solve the problem. However, one thing that can help is to change the way documents are written and formatted.

Make sure policy and procedure documents are useful.

Manuals must provide relevant information to those who will use them. They must contain information that is important for doing the job without lots of extra fluff.

Make sure policy and procedure documents are usable.

People must be able to find the information they need quickly. And once they find it, they must be able to extract meaning quickly. So, a few things that can help;

  • avoid pages of document control information at the start – the user is not interested
  • keep line lengths short to make them more readable
  • use consistent styles so that users easily recognise information types
  • use photos instead of always relying on text descriptions
  • try starting all action steps with a verb

Make policy and procedure documents attractive

Entice people to use manuals by making them pleasing to the eye. There is no reason why work documents should be ugly. Form and function should come together.

Action

  • Find out which documents are being used and which just sit on the shelf.
  • Find out who is using them and how they are being used.
  • Check the written practice against the actual practice.

Due diligence in public documents – test before publishing

Plain language / Plain English, ,

Due diligence: action that is considered reasonable for people to be expected to take in order to keep themselves or others and their property safe. (Cambridge English Dictionary – my emphasis)

Businesses and government agencies write public documents to inform people about products, services, obligations and opportunities. People may be harmed if they do not fully understand fact sheets, letters, contracts, websites and the like. They may not receive the product or service they expect, they may act in a damaging way, or they miss out on something due to them.

The impact of misunderstanding may be serious or trivial. If the document is about a work process, misunderstanding may result in death or injury. If it is about a financial product, misunderstanding may lead to poverty and disadvantage.

The development process for most public documents is something like

  1. a junior person writes a first draft
  2. a manager reviews and edits the draft
  3. the marketing people provide input
  4. the legal department review, to make sure there is no risk to the organisation
  5. final graphic design and publish.

Organisations may perform these steps with skill and care, but that is not due diligence. It is merely people internal to the organisation talking to each other about the document. They make untested assumptions about how the target audience will understand and react to the document.

Document testing is both reasonable and necessary for public documents

Testing helps keep other people safe. Document testing checks the information can be read, understood and acted on before it is published.

Choosing not to test is reckless.Reckless writing: not caring about readers Simply passing a document around the organisation and throwing it out to the public is not reasonable or responsible. We would never allow a physical product to enter the public arena that way – why do we tolerate it with information products?

Document testing is not difficult, expensive or time consuming. You can find most usability problems by testing with just a handful of potential users.

Logan City Council commits to plain language

Plain language / Plain English

Logan City Council found that its old website was not meeting the needs of its residents and rate payers.

A user-focused approach was employed to develop a far more effective website. This involved considerable user testing and re-ordering content. But it also meant re-writing content so that it was more easily understood. That is, content had to be written in plain language.

Brisbane based plain language certifier Judy Gregor helped council achieve the standards. Read how Judy helped move council towards communication excellence.

UX writing vs plain language writing

Plain language / Plain English

I’ve only recently come across the term ‘UX writing’; it may have been around for a while. My immediate internal skeptic said “This is just plain language writing dressed up in new clothes. UX is on trend – lots more dollars available for UX writing than plain language writing.”

I think my internal skeptic is partially correct. But I also think this new description puts a healthy and helpful focus on what is happening for the user. So I’m not against the term, nor totally cynical.

First, identifying a reader as a user is helpful, especially for functional documents. Functional documents aim to get people to think, feel or do something – web content, contracts, reports, advice, disclosures, fact sheets, policies, procedures, terms and conditions, letters. Most documents written by businesses and government agencies are functional documents.

Functional documents are information products that people need to use.

Second, acknowledging the user has an experience while reading is helpful. It acknowledges that functional documents are conversation; not mere blobs of text on paper or screen.

Third, UX methods involve the user. UX implies products are tested with real users before release. Testing has always been part of good plain language methods. Unfortunately it is often omitted.

Much plain language writing becomes unstuck at this point: testing. Often there is no real testing, just internal and legal review. When everybody says it’s OK, we publish and hope for the best. That’s arrogant, irresponsible and perhaps reckless. See Publishing a document without testing