All posts by Greg Pendlebury

Logan City Council commits to plain language

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 PlainLanguagePro certifier Judy Gregor helped council achieve the standards. Read how Judy helped move council towards communication excellence.


Readability – necessary but not sufficient

Readability refers to how easy it is to read text. It depends on how complex the ideas are and how they are expressed. (Readability is different to legibility. Legibility refers to how easy it is to see the letters that make up words.)

There are many tests that measure how readable a piece of text is.

I always use readability software

Readability tests quick and easy, and usually free. MS Word has the Flesch Reading Ease score and the Flesch-Kincaid Grade Level built in. Their are many other tests available on the web – all have value.

Other apps (like Grammarly) offer to check tone, spelling and grammatical errors. is one of my favourites – it provides lots of helpful information. I’m writing this blog using the Hemingway app.

Software can alert me to silly mistakes, things I can improve in my writing. Even when I think I’ve done a good job, running my text through a tool makes it better. There’s no such thing as good writing, only good re-writing.

I never rely on readability software

Readability and writing apps work by analysing words and sentences. They count up syllables, look for passive voice and do other analysis. It’s a mechanical review only.
It’s possible to write highly readable rubbish. That is, you can write useless text that scores well on readability tests.

Readability tests don’t consider other matters that are vital. Effective writing meets the needs of readers while achieving the writer’s purpose. Writers must structure content well – usually point first. Text must be relevant to readers and give information they can use.

Inbuilt limitations, yet valuable

Many tests were developed decades ago. They reference US grade levels, not Australian readers. There are many weaknesses in the tests.

Despite the weaknesses, readability test are valuable. They provide good, but not definitive, feedback. They are quick and easy to use – why wouldn’t you use them?

For a more comprehensive way of being confident your text will be effective, test and certify your documents.


UX writing vs plain language writing

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


Due diligence in public documents – test before publishing

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.

The PlainLanguagePro GOLD certification trademark requires writers to test documents before publishing. It is a sound way to prove you have used due diligence in your documentation project.PlainLanguagePro GOLD certified guarantees usable text.Facebooktwitterredditpinterestlinkedinmail

Procedures: how to write for business benefit

Most businesses define work activities in a written procedure. (If your business doesn’t, it really should.) Procedures, sometimes called Standard Operating Procedures (SOP), work instructions or safe work method statements, are the basis for a well controlled business.

But how do you write a procedure well? What makes a good SOP? You could mindlessly follow a template someone else has developed, or you could think about what you want to achieve, what would work best for your business. Some templates can be helpful, but they may not be best for your organisation. See some examples.

The elements of good work procedures

A purpose statement and a link to overall process

Workers need to know how the activity they perform fits into the big picture; how it contributes to the overall process and the purpose of the organisation.You could do this with a context statement, or locating the activity in a process map. Also give a thoughtful title to the procedure.

When working in the road surfacing industry, we changed a procedure title from ‘Drive the broom tractor’ to ‘Prepare the surface’. This had an immediate impact on how workers viewed the activity and lifted the self esteem of the broom driver.

Performance standards

Procedures should do more than merely provide a list of tasks to perform. They should include information about how to assess the quality of those tasks. Workers and supervisors then have some objective measures to judge performance.

The standards could be related to quality, performance or safety.

Grouped into sensible work chunks

Chunking work into steps and sub-steps provides helpful structure for workers. It avoids a long list of tasks, and fits well with the way workers think about the job.

For example, the work chunk ‘Find outstanding invoices’ could have sub-steps like Find the file, Search invoices by date range, Print report.

‘Thinking’ and ‘Doing’ sections

“Work is the exercise of discretion within boundaries.”
John Ralph, former CEO of CRA.

Procedures, SOPs, define the boundaries. They are the things workers must do. But to better engage workers, we want them thinking about their work too. That’s good for them and good for the business. So we might want to direct thinking about productivity, safety or environmental matters.

For example, include thinking prompts in the procedure like: ‘How could we reduce the paperwork?’ ‘Residents may be moving in and out of driveways as you inspect the footpath – take care.’

Standard resources

Include the equipment needed for the task, including safety related equipment. Describe the skills and competencies required. It may be appropriate to include the standard time taken for the task.

All this information allows you to cost the procedure and measure the impact of improvements and changes to business practice. For example, we discovered it takes 10 minutes to process and record payments into a law firm’s trust fund. If the firm offers clients a payment plan, increasing the number of payments, they may significantly increase their back office costs.

Plain language

All documents should be written in plain language.

When procedures are written plainly, workers can understand them quickly and implement them. If they are written in a style that workers find difficult, they may be confused and do the wrong thing, or waste time asking for clarification, or totally ignore the procedures and do what they think is best.

You can prove procedures, and all documents, have been written plainly with PlainLanguagePro certification.


You’ve written it with care, but will it be read, understood and acted on?

User testing is a must to increase the chance that a document is read, understood and acted on. (A document could be a printed process, fact sheet or report, or it could be web text.)

Effective business documents have an impact on the thinking, attitudes or behaviour of readers. If they don’t, the investment in researching, writing and reviewing is all wasted. Writing with care is vital; but care in crafting the document doesn’t guarantee success. Even well organised, plainly written documents can fail to achieve their purpose.

Testing documents with users before they are released is the best way to improve the likelihood of success. And it’s not difficult or expensive.

There are multiple ways to test a document, but one of the simplest is to design a set of questions to be used in a structured interview. Give the test subject the document or website to read. Then, ask them questions exploring what they understand and what they would do next.

You can get helpful insights with just a handful of tests.

Testing with real users, or people who represent real users, is far more powerful than passing the text around the office for your colleagues to review. Only real users have the perspectives and the constraints needed for a valid test.

User testing is required for a document to display the PlainLanguagePro GOLD trademark.

There is never enough time or money to do it right, but there is always enough time and money to do it again.


Superannuation PDS readability

The superannuation industry is in the news again today; described as an “unlucky lottery”.
Among other issues, poor information is still a problem – ” They’re bamboozled by poor disclosure …”
I thought I’d have a look at how easy it is to read some Product Disclosure Documents. I’ve looked at two dimensions across 10 popular funds.

1. Likely reading time

People are less likely to read longer documents. We all prefer to read short documents than long ones – we want information fast.

2. Readability

People need easy to read text to help them understand complex ideas. Readability indices are one way to measure how easy it is to read and understand text.
All these indices are higher than the Australian Government’s recommendation of between 3 & 4. link. My view is aiming at about 7 – 8 is OK for this type of content.

Why readability matters

The PDS is a functional document. People are supposed to use these to decide whether the fund is a right fit for them. Of course they need to read and understand the information in the PDS to be able to make this decision. And this is an important decision that can have impacts over a lifetime.
Many application forms ask potential members to declare that they have read and understood the PDS. A lengthy or difficult to read document discourages reading. It may encourage people to make a false declaration – to tick the box without reading or understanding.
And difficult to read documents are risky for funds too. The focus is shifting from ‘did you read the document’ (aimed at the reader) to ‘is the document readable’ (aimed at the writer).

Be careful with readability tools.

The readability tests I’ve used are mechanical tests that look at word and sentence complexity. They cannot be relied on by themselves, but a high grade index does indicate the text could be simpler.(The grade number refers to US school grade)
These tools do not consider document structure, meaning and the usefulness of content. It is possible to write highly readable rubbish.

The tests in detail

1. Reading time
I divided the total word count by 200. The avaerage reader reads at about 200 – 220 words per minute.
2. Readability
I used computerised versions of
  • Flesch Kincaid Grade Level
  • Gunning Fog Score
  • Coleman Liau Index
  • SMOG Index
  • Automated Readability
  • Index Spache Readability Score
  • Dale-Chall Readability Score

and calculated the aritmetic mean.

Documents were sourced on 29 May 2018 from:
Australian Super
Intrust Super
ANZ Smart Choice
Virgin Money Super
AMP MY North
ING Living Super


Why I am a plain language zealot

All business and government documents should be written in plain language. These are ‘functional documents’; people are expected to use these documents (information products) to do something.

Writing in plain language is important because:

Plain language builds a more just society

Writing plainly means more people will be able to read and understand your message.

If our audiences cannot follow legal documents, information leaflets or letters, there is the risk of their breaking the law, or failing to do what is expected of them or receiving what is rightfully theirs.” (Tasmanian Government)

Choosing not to write plainly can introduce social disadvantage. Excluding people from being able to easily understand contracts, laws and other information limits their choices. They can’t fully participate in society.

Plain language displays clear thinking

“If you can’t explain it simply, you don’t understand it well enough.” (attributed to Albert Einstein) No matter who said it, the idea is helpful.

When you have a deep understanding of an idea, you can find words, metaphors and images that help other people understand it too. You can explain the idea simply and with precision. If you only have a superficial understanding, you are likely to express the idea vaguely. It is unlikely to be written plainly.

If people understand more of what you’re saying, they will likely feel that you make sense.(Hoa Loranger)

Plain language aids effectiveness and efficiency

Business and government documents need to be both effective (achieve purpose) and efficient (read and understood quickly). Writing in plain language helps achieve both goals.

Complex, technical or pompous writing does not convey ideas quickly – readers have to battle to make sense of what is written. Writing plainly means using words and structures that your audience can quickly understand. (Knowing your audience is vital – when writing for technical readers you may use terms that lay people would call jargon.)

Writing plainly using familiar words and simple structures is not dumbing down. It helps less able readers to understand, and helps more able readers to read faster.Facebooktwitterredditpinterestlinkedinmail

Plain language vs Plain English – a subtle but important difference

When I first started in this industry nearly three decades ago, I thought the terms ‘plain language’ and ‘plain English’ were synonymous. Writing professionals from Canada often talked about ‘plain language’ because they dealt with both French and English, but in countries like Australia, New Zealand, USA and Britain the term ‘plain English’ was more common. (By the way, Canada has a long and rich history encouraging plain writing – since the 1920s the Royal Bank of Canada newsletter has provided helpful advice about writing clearly.)

But over the decades I’ve observed a subtle shift; a shift in emphasis or focus.

Plain English professionals tend to focus on features of the language. They aim to make documents clear and concise. They talk about helpful techniques like using familiar words, preferring the active voice, writing with more verbs than nouns, keeping sentences short and writing in a conversational style.

Plain language professionals tend to focus more on readers and the way they respond to a document. They aim to make documents clear, concise and effective. They consider how the reader will encounter the document and the desired response. Plain language professionals see documents as information products, and so often incorporate user testing before publishing, just as we would for any other product.

Plain English professionals often concentrate on correctness; plain language professionals focus on usefulness.

plain language focuses on usefulnessOf course, the overlap between the two groups of professionals is vast. There is more that unites than divides. Plain language writers will use all the plain English techniques, and plain English writers always consider their readers. However, in my view, the gradual shift in focus is real.

The Australian Office of Parliamentary Counsel has said:

We prefer to use the term “plain language” rather than “plain English” because we believe that it covers a wider range of techniques and practices. ( – link no longer active)

Even Wikipedia entries reflect this subtle difference in focus:

Plain English is language that is easy to understand, emphasizes clarity and brevity, and avoids overly complex vocabulary.

Plain language is writing designed to ensure the reader understands as quickly, easily, and completely as possible.

So what? Is this an artificial distinction and ‘splitting hairs’. I think not. The difference is important, especially when writing functional business documents. Writing clear and concise text is not the goal. Effective communication is the goal – and that requires a deliberate focus on readers and usability. Readers should both understand the content and know what to do with it. Functional documents are not just about informing; they aim to impact the way readers think, feel and act.

A PlainLanguagePro GOLD certification increases the likelihood readers can find, understand and use content.

Greg PendleburyFacebooktwitterredditpinterestlinkedinmail

Don’t accept a broken document

If you cannot easily read and understand a document or website, it is broken. Don’t accept it. Don’t be pressured to sign it, agree to it or use it.

A business or government document is an information product. You would not put up with a car that doesn’t run, or a chair that falls over. Neither should you accept an information product that does not perform its designed function.

Business and government documents and websites are designed to convey information that people need to act on. Fact sheets, contracts, agreements, advice letters all perform a function – they are designed to do something. So they need to work, and work well.

We should rightly expect information products to be easy to use, just like any other well designed product. You should be able to read the document easily and extract the information you need quickly. Do not think you are stupid if you can’t – it’s likely the fault of the document.

So what could you do when you encounter a difficult document? Ask the document owner to rework the information product so that it is easy to use. Push back. Demand to understand! is certifying documents, guaranteeing they are written plainly and easy to use.Facebooktwitterredditpinterestlinkedinmail