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.

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