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 plain language 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. Readable.com 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.