Category Archives: Uncategorized

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’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.

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:
Hostplus https://hostplus.com.au/financial-services-guide
Australian Super https://www.australiansuper.com/tools-and-advice/learn/product-disclosure-statements
Intrust Super http://www.intrustsuper.com.au/wp-content/uploads/Core-PDS.pdf
CareSuper https://www.caresuper.com.au/super/forms-publications/pds
Cbus https://www.cbussuper.com.au/content/dam/cbus/files/forms-publications/general-information/Cbus-Industry-Super-PDS.pdf
BUSSQ https://www.bussq.com.au/disclosure
ANZ Smart Choice https://www.wealth.anz.com/content/dam/anzwealth/pdfs/superannuation/Smart-Choice-Super-Pension-PDS.pdf
Virgin Money Super https://virginmoney.com.au/content/dam/virginmoney/vma-downloads/superannuation/Virgin-Money-Super-Product-Disclosure-Statement.pdf
AMP MY North https://www.amp.com.au/content/dam/product/mynorth/MyNorth_SuperPension_PDS.pdf
ING Living Super https://www.ing.com.au/pdf/ING_DIRECT_Living_Super_PDS.pdf

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.

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.

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. (http://www.opc.gov.au/PLAIN/index.htm – 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.
(https://en.wikipedia.org/wiki/Plain_English)

Plain language is writing designed to ensure the reader understands as quickly, easily, and completely as possible.
(https://en.wikipedia.org/wiki/Plain_language)

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.

Greg Pendlebury

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!

Banking Royal Commission – write plainly to treat people fairly

The terms of reference of the Royal Commission into Misconduct in the Banking, Superannuation and Financial Services Industry states

All Australians have the right to be treated honestly and fairly in their dealings with banking, superannuation and financial services providers.

People are not treated fairly when information about financial products is written poorly. People cannot make good decisions when they cannot easily read and understand Financial Services Guides, contracts and other documents.

Difficult writing disadvantages people.

It would be useful for the commission to look at the role poor documentation plays in disadvantage. It is well within their remit as it considers:

Whether any conduct, practices, behaviour or business activities by financial services entities fall below community standards and expectations.

Corporations law says that Financial Services Guides and other documents must be written so that they are ‘clear, concise and effective’. Many documents in the financial services space fail to meet this basic requirement.

Service providers can develop documents with the best intent in the world; but if they judge suitability from their own perspective they will come up short. The suitability of a document can only truly be judged from the readers’ perspective.

The best way write any document about financial products is to write it in plain language. This way of writing presents information so that most readers can understand. It avoids jargon, unfamiliar words and complex sentence structure. It simply talks about the topic in a straightforward manner.

Why don’t we test information products?

No one would consider releasing a physical product to the market without testing it first. From motor vehicles to pencils, it’s hard to think of a product that has not been tested throughout its design and production.

To not test would be reckless. The product could fail in some way, perhaps harming consumers or damaging the organisation’s reputation in some way.

But when it comes to information products, printed or web documents, many are released with only minimal review. Rarely do organisations rigorously test their documents to check comprehension and impact. Usually, documents are reviewed by a handful of managers and then sent out.

The underlying arrogance says ‘If we think it is OK, it must be.’ To release an information product in that way, to release any product like that, is reckless.

  • An untested document may not be read. For a document to be effective, it must be read (thank you Captain Obvious). If you can’t get people to read your document, all is lost.
  • An untested document may not be understood. A good document conveys ideas, quickly and easily, . from one person to another. It’s vital to test ideas are being received properly.
  • An untested document may not be acted on. Test the impact on the thinking, attitudes, behaviour of readers. How else will you know whether all the writing and review effort has been worthwhile?

Claiming something is written plainly does not make it so

I came across this sentence recently:

The text provides, in plain English, an overview of what is necessary to give effect to a valid advanced care directive, and through illustrative and contemporary examples, enhances our understanding of the importance of “planning ahead”.

I don’t think many plain language professionals would say this is plainly written, despite the claim. When you have written plainly, you do not need to tell people you have done so – it will be obvious to your readers. They will be engaging with your ideas, not your writing. (reminds me of one of my other guiding principles: Never trust anyone who has to say “Trust me”.)

Some particular problems:

  • ‘to give effect to’: This is an uncommon and somewhat pretentious phrase, likely to put many readers off. Its use is unclear – it has the immediate sense of ‘how to write an advanced care directive’, but the literal meaning is ‘when your advanced care directive becomes operational’.
  • ‘an overview of what is necessary’: Too wordy.
  • ‘enhances our understanding of the importance of’: Too wordy.
  • ‘illustrative and contemporary’: Big words where small ones will do.
  • Many ideas in a sentence that is too long. As a rule of thumb: one point, one sentence.

A possible rewrite:

This booklet explains how to make an advanced care directive. The examples show how planning ahead is very important.

Can you provide a better rewrite? I’ll leave this post open for comments for a while.

The risk of writing functional documents and web content

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.

Ten tests to avoid reckless 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?

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.

Has this insurance document been written recklessly?

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)

User centred communication – is it worth the trouble?

User centred communication has at its core a desire to make information easy to find, easy to understand and easy to act on.

If users cannot find the information they need quickly, or if they cannot easily understand what they read, they will likely give up. Potential customers could go to information provided by your competitor. Workers may make up procedures themselves, making work instructions worthless and destroying quality assurance.

Organising information in a way that makes sense to the user is essential. Expressing your thoughts clearly and in familiar language makes contact with your reader.

User based communication is very different to the information dump approach — “I’ll tell you all that I know and you figure out what you need from that.” Surprisingly, such a cumbersome approach is still common, particularly in internal documents.

Writing for the user increases the likelihood that the material will be read, understood and acted on. It’s worth the extra effort.

Write for your reader

  • How will the reader discover this information?
  • Will they be looking for an answer to a specific question they have, or just reading for interest?
  • What are they likely to be doing when they go looking for information?
  • What will the reader do with the information?
  • Do they need to follow a procedure you are describing?
  • Do they need to combine this information with other information? Where will they get this from?
  • How can you organise this in a way that makes sense to your reader?
  • How are the ideas related? (In general, it is best to start with the ‘big picture’ before moving into detail. )
  • What do your readers already know about this topic?
  • How can you organise this into chunks? (Use headings to separate the chunks, use paragraphs to further organise the chunks.)
  • What can you safely leave out? (Readers find it tiresome to wade through text that has no relevance to their interest or needs.)

When you start writing:

  • Get straight to the point.
  • Use words familiar to your reader.
  • Keep sentences short and simple. Each sentence should usually cover only one point.
  • Use the active voice and avoid the passive voice.
  • Write directly to your audience i.e. use ‘we’ and ‘you’.
  • Use verbs (action words), not nouns made from verbs.
  • Use simple, short words.

 

How good writing drives good thinking (with a down-side)

There is a very close relationship between writing well and thinking well. You cannot write well until you think well.

The relationship with thinking is what excites me about writing.

When we write (and this could be a few words or even a diagram) we take the fuzzy, unformed ideas sitting in the back of our heads and make them explicit. We put them on a page or a screen. When we see our thoughts on paper, we are better able to interact with ideas, and thinking becomes richer and clearer.

The think-write-think process helps us figure out the best way of explaining ideas to others – we talk to ourselves and other people with greater clarity.

Poor writing is often the result of poor thinking. Ideas may be there, but if they haven’t been worked over and refined by writing and re-writing, they are unlikely to be understood by people other than the writer.

The down-side

The close relationship between writing and thinking means that every time you write something, you are exposing your thinking. That may be an uncomfortable thought. People may make judgements about your thinking capability based on the text you generate.

It’s all the more reason to strive to write plainly and clearly, so that readers can see through your words to interact with your ideas.

Clear, concise and effective: what ASIC says about disclosure documents

It’s the law. Many types of disclosure documents – prospectuses, financial services guides, statements of advice and the like – must be written in a way that is clear, concise and effective.

Too often disclosure documents are complete and accurate, but they don’t communicate well. They don’t help readers fully understand the issues so they can make an informed investment decision.

But what does it mean to be clear, concise and effective? ASIC’s recent update (Nov 16) to Regulatory Guide RG 228 ‘Prospectuses: Effective disclosure for retail investors’ unpacks this phrase. In short it recommends using the principles of plain language when writing a prospectus and other disclosure documents.

The guidance ASIC provides comes as no surprise to Plain Language Professionals – we’ve been advocating using plain language and a deliberate focus on the needs of users in all sorts of documents for years. It’s the best way to get your message across.

Ignoring these guidelines, just writing the way disclosure documents have always been written, is risky. The consequences of a disclosure document being found to not be clear, concise and effective could be very costly. RG 228 provides some ways to judge a disclosure document, but ASIC says the guide will not be used as a simple checklist.

The foundational principle of plain language is to focus on the user or reader of the document. RG 228 says that when writing a prospectus to focus on your readers’ need to understand the content and use the information to make an informed decision.

The guide lists a number of writing techniques that help; things like using the active voice, talking directly to the reader, using verbs rather than nouns, avoiding jargon, writing with short sentences.

Plain Language Professionals have been using these ideas for decades, but this writing style is rare in disclosure documents. I guess that’s not surprising: most disclosure documents are written by people with financial and legal expertise rather than by expert communicators.

Writing in plain language is no longer a ‘nice to have’; it’s essential. See plainlanguage.site for a list of Plain Language Professionals who can help write clear, concise and effective disclosure documents.

Effective, less risky procedure documents

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 recognize 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.

Building the best structure for your document

Placing your content in the correct order makes a big impact on the effectiveness of your document.

Before designing a structure for your document

  1. define the purpose of your document – what you want to achieve
  2. understand your readers – what they want and need

If your purpose is to persuade or share information and your readers are likely to give you a fair hearing, then a ‘point first’ structure is often the best. (sometimes called a pyramid or telescoping structure.)

A ‘point first’ structure starts with your key point. You follow this with explanation, reasoning and detail that justifies and expands the point.

Readers find this structure easy to follow; it’s always easier to grasp an argument when you are told the conclusion first. It also allows readers to stop reading when they have had enough without missing your main point.

But if your readers are likely to resist your message, then you may need to walk them through your reasoning and research before telling them your conclusion.

Documents aimed to persuade, a business case for example, are often structured by talking about the problem or opportunity first. This highlights the motivation for change and sets the scene for your solution.

When writing procedures, consider starting with the overall aim or intent of the procedure (to give clear context and purpose) and then present the steps in chronological order.

An effective document structure is one where readers can quickly understand and use the information you provide.

Financial disclosure – being clear, concise and effective

financial disclosureThe law says that financial disclosure documents must be worded and presented in a clear, concise and effective manner. This is a requirement of the Corporations Act 2001:

  • Financial Services Guides – Sect 942A (6a)
  • Product Disclosure Statements – Sect 1013C (3)
  • Statements of Advice – Sect 947C (6)

My observation is that many disclosure documents do not meet the standard of ‘clear, concise and effective’. Writers seem to focus on complying with other aspects of the law – having  the correct content. They assume that being complete and accurate is enough. That’s a very risky position to take, and it may break the law.

These standards of ‘clear, concise and effective’ are tough to meet because they can only be judged with reference to the reader, or user, of the document.

An effective document is one that achieves purpose. The general purpose of disclosure documents, as described in the law, is to help people make a decision about whether to buy financial services or products, or follow advice. To be effective, disclosure documents must work to achieve that purpose. That means you must know something about your readers and their decision making process, and use that knowledge to inform your writing. It may mean including additional content not required by the law, but that is helpful for your readers.

Being concise means not including unnecessary material, not saying the same thing multiple times (removing redundancy) and not using more words than is needed to express an idea. It means you should not blindly use a boiler-plate template that includes material that is irrelevant to some readers.

Being clear is a matter of

  1. organising content in a way that makes sense to your readers
  2. using words, sentence structure and a style that can be understood easily.

In short, all financial disclosure documents must be written using the principles of plain language, with a deliberate focus on the needs of users.

Reckless writing

reckless

Reckless writing is when writers just float a document ‘out there’ without any serious thought about their readers. Like reckless driving, it’s just doing what you think is OK without properly considering the consequences.

Even if your document is complete and accurate, not considering your readers is reckless. Not considering how they will understand and what they will do as a result of reading is both arrogant and careless. Not taking the time to structure your document in a way that makes sense, and not writing plainly in language readers can understand, is irresponsible.

It is never enough just to write what you think is good enough – the reader is the sole judge of effective communication.

Unfortunately, reckless writing is common. It’s unusual for authors to carefully articulate the purpose of the document and the needs of their users before they start writing. Proper user (reader) testing is rare. And document reviews don’t always fix the problem – they can end up being group recklessness.

But reckless writing is very risky behaviour for government agencies and businesses. It’s especially risky if you write documents that people use when making decisions.

Sometimes the risk is that the document is ignored. In that case, all that has been lost is

  • research effort in defining the content
  • writing effort, as authors struggle to find words to convey ideas
  • design effort when graphic elements are sourced to supplement the words
  • review effort as the document passes through various levels of approval
  • publishing cost, perhaps printing or placing it online
  • archival and governance effort to keep proper records of the document
  • the opportunity – the document was intended to achieve some outcome but didn’t.

Other times the risk is that users (readers) misunderstand the document and take an action that they shouldn’t, or that they would not have if they had understood it properly. When that happens, the cost to you and to them can be huge and may potentially involve legal action.

Consider your users when you write and what they need to do with the information. Test to make sure you are communicating effectively.

Outline of an effective business case – IT example

This example outline uses the familiar Situation, Complication, Question, Answer structure for business proposals.

The context is a large company in the finance industry implementing cloud technology for software development (referred to as virtual environments).

Note the power of ‘talking headings‘ – you’ll get the gist of the proposal just by reading these headings.

Executive summary

‘Virtual Environments’ open new opportunities

A transformational change plus tangible benefits

1 Situation: Solid technology underpins the business

1.1 Supporting a business with purposeful intent

1.2 Robust technology base

1.3 Sound controlled change methodology

2 Complication: Changing our technology is cumbersome

2.1 Shared and limited number of traditional environments

Development must be completed within a fixed window

Delays in one release impact future releases

Changes to one project impacts all other projects in the release

Production support is disrupted every release

Drives inflexible training schedules

2.2 Limited test data

Limited capability to back-up and restore test data

Old and unrealistic data compromises test confidence

2.3 Dependence on legacy platforms

Manual configuration results in delayed changes and increased variance

High costs of environments

3 Focusing question: How can we have rapid, yet robust, change?

3.1 How can we introduce change rapidly without losing control?

3.2 How can we provide data so that changes can be tested quickly and confidently?

3.3 Is there a way to allow projects to work at different rates?

3.4 How can we transform so that rapid change becomes ‘business as usual’?

4 Proposal: Modernise our IT environments and processes

4.1 Extend virtualised environments

Extend the application coverage to cover all organisational requirements

Decommission all traditional environments

Provide dedicated VEs for minor releases and production support

Provide dedicated VEs for training

4.2 Provide better test data management

Provide capability to backup and restore test data in non-production environments

Provide masked production type data

5 Cost/benefit: IRR of xx% and a payback period of yy years

5.1 Some benefits realised immediately, others gradually ramp up

5.2 If we ignore this opportunity, we’ll lose momentum

5.3 Strategically aligned to corporate objectives

6 Costs

6.1 Costs that can be estimated well

Data solution and extension of VEs across the organisation

6.2 Costs that cannot be estimated well

Extend VEs to include partner organisations

Impacts on the change delivery teams

7 Benefits

7.1 Benefits that cannot be estimated well

Improved business flexibility

Improved project quality and efficiency

Reduced reputation risk

Foundational build to support future delivery

Strategic capabilities for test data management

Reduced hardware spend

7.2 Benefits that can be estimated well

Avoiding the cost of provisioning new traditional environments

Avoiding the cost of new traditional environments to support large scale programs

Eliminating lost productivity and migration effort resulting from de-scoping

Decommission traditional environments

Eliminating minor release environment migration and lost productivity

Reduced retrofitting effort

8 What might raise costs or limit benefits?

8.1 Sensitivity analyses

Changes in cost estimates

Slow project progress

Limited project funding

Variable test data solution costs

8.2 Dependencies

Benefits are only realised if test data solution provided

Full realisation of benefits requires changing the way we work

8.3 Constraints

Satisfaction with current performance

8.4 Project risks

No change in mindset, so no organisational transformation

Partial implementation will reduce benefits and lead to ‘slip back’

Applications may require re-architecture

Additional non-functional re-architecture may be required

Hardware or software is procured unnecessarily by teams external to project

9 Appendices

9.1 Alternative solutions considered

9.2 How the project will be organised

9.3 How we gathered information

Bottom-up

Top-down

9.4 Industry trends

The curse of knowledge

curse of knowledgeSometimes poor writing is not the result of laziness or a desire to be obscure, it’s just because we know the content too well.

When you know something really well it is extremely difficult to imagine not knowing it. That makes it hard to share knowledge with others because you can’t easily put yourself in your readers’ shoes. It’s like trying to un-see or un-hear something.

The first principle of writing clearly is to understand your users or readers; to understand their needs, wants, interests and mind set. But that is really hard to do if you are an expert trying to communicate with non-experts.

Experts immerse themselves in the subject for years. They end up speaking and writing using abstract terms to summarise all the concrete data in their heads. They describe ‘replacing the bolt’ as ‘taking corrective measures’, or ‘wind and rain’ as ‘unfavourable weather’, or ‘stopping pollution’ as ’emissions reduction’. But novices don’t get it. They only hear vague phrases.

Experts forget how difficult it has been to acquire knowledge. They now see much of their knowledge as ‘obvious’ or ‘common sense’.

Elizabeth Newton illustrated the curse of knowledge in a simple game. A “tapper” was asked to tap out the rhythm of a well-known song, such as “Happy Birthday”. The listener’s job was to guess the song. Newton asked the tappers to predict the probability that listeners would guess correctly. They predicted 50%, but listeners actual success rate was 2.5%. The reason for such a difference? The tapper can’t avoid hearing the tune in their head playing with the taps, but all the listener can hear is a kind of Morse code.

Deliberately working to put yourself in the users’ shoes is a start, but doesn’t really solve the problem. The only solution is to test what you have written. Ask your user, or a surrogate user, what they understand from your writing.

(inspired by reading Steven Pinker’s book, The Sense of Style)

Think before you consult when writing policies

Top view of co-workers planning a strategy Free Photo
Business photograph designed by Pressfoto – Freepik.com

Employee consultation has become a ‘sacred cow’ when writing policies and procedures. There’s a tendency for organisations to involve all possible stakeholders so that everyone can have their say when defining how things work in an organisation. It’s promoted as a way to create an engaged and empowered workforce; an antidote to a command and control culture.

But consultation takes time and can be counter productive. Countless hours can be lost in document reviews and meetings, sometimes with little benefit.

Yet consultation communicates that you and your organisation value people and respect their point of view, knowledge and experience.

So, think before you run every policy through the same consultation process. Discern which documents will benefit from consultation, and who should be involved.

Consider policies in three broad groups:

1. Policies where consultation is pointless

If you are developing policies or procedure to implement a non-negotiable directive from the board, or a piece of legislation, consultation may not be helpful. Just write the document and get on with it. Consultation in this situation may even be harmful – it can raise the expectation of negotiation and input when there is none. You could lose credibility.

2. Policies where input from others is essential

Sometimes subject matter expertise resides in a number of people. You’ll need to consult to find out what is happening, or the best way of doing something. Find the right people and involve them in every stage of drafting and review. You’ll end up with a richer outcome by listening to appropriate stakeholders.

3. Policies where people just want to have their say

There are some policies in an organisation that stir the passions – like the ‘car policy’. People want to be heard but full consultation is not mission critical. When developing policies like this, I often invite comment but don’t run a full consultation process. Of course, if you invite comment you need to consider it – revise the policy or provide other feedback.

(this blog inspired by a conversation with Adam Leonard, General Manager Human Resources, Anglicare)

Purposeful communication – beyond shared understanding

Functional documents demand purposeful communication.

Traditional models of communication have understanding as the goal of communication. A person constructs an idea, codes into media (speech, text, images) transmits it. The receiver decodes and reconstructs as a new idea. Feedback and re-transmitting continues until both the sender and the receiver have the same idea. That is, the aim is a shared understanding. But that is not good enough for functional documents.

Purposeful communication starts by asking ‘Why?”.

The purpose of all business communication is to impact the thinking, attitudes or behaviour of readers in some way. We write to achieve a business purpose.

For example, marketing communication aims, ultimately, to get people to buy from you. Policies and procedures aimed to cause people to act in a particular way.

Purposeful communication goes beyond understanding and effectively transmitting ideas. It is more about influence.

So, the simplest way of testing any communication piece is to look at your audience. Are they doing what you wanted them to do? Are they moving towards doing what you want? Is your document achieving purpose?

Define purpose before you write

It’s best to know what you are trying to achieve before starting any activity. Your purpose in writing depends on the type of organisation you are.

For a business, its ultimate purpose is probably to make a profit. (But there will be other important things like ensuring its employees work safely, protecting the environment and the like.) A business will have other aims and objectives related to its purpose like increasing market share, keeping quality on track, or improving the skills of its employees. Effective purposeful communication will work to support these aims and objectives.

For a government agency or some other type of organisation, its purpose will be  related to fulfilling its mission. That mission may be to provide good roads or to administer taxes fairly or to provide care services to a part of the community. These organisations also have lower aims and objectives that are related to their higher purpose.

Workplace communication aims to enhance the business performance of the organisation. Purposeful communication enables and energises employees to carry out strategic intent. Communication is a means, not an end.

Can you know a document will achieve purpose before it is published?

Sensible user testing gives good insights and can help you avoid reckless writing. Communication products, like all products, should be tested before being released.

Can you always define purpose up front?

Purpose sometimes changes as you get into a project. Often you start with something particular in mind but it changes as you become more familiar with the needs of the user and the evolving environment.

I’ve told them – isn’t that good enough?

Never! – unless all you want to do is meet some legal obligation. In that case, who cares if no-one reads or understands? But if you want people to read, understand and act on your message, you must do more than merely tell. You must tell in a way that makes sense to your readers and makes contact with them.

We’ve probably all seen “I’ve told you” messages. It’s clear that the writer doesn’t really care too much about their reader. These pompous writers force the reader to work hard unscrambling thoughts and making sense of poorly structured, poorly worded text. Often they deliberately use jargon, cumbersome expressions or lofty words in an effort to impress the reader. Sometimes these writers are deliberately obscure, so that they can say “gotcha” when the reader misunderstands.

You are probably reading text like this whenever you feel you are getting lost, whenever you have to re-read sentences and paragraphs to extract meaning.

Good writers make life easy for the reader. They work hard to help people read, understand and act on information.

Effective communicators take on the responsibility for helping others understand. They don’t shove this responsibility on the reader.

To do this they work hard to see things from the readers’ perspective. They put themselves in the readers’ shoes, asking searching questions before they put finger to keyboard. They ask things like:

  • why should the reader read this?
  • what information are they most interested in?
  • how will this message link with what readers already know?
  • what words and sentence structures are my readers familiar with?
  • what do readers need to do with this information? what actions or decisions will follow?

They then write from the readers’ point of view.

 “Writing is not about you, it’s about your reader. The sooner you can take yourself out of the picture and focus on doing good for your reader, the quicker you’ll be a good writer.” Michael Masterton

 

5 steps for effective document review

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 five 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; explain 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 helps 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.

3 Ps of writing effective marketing material

We often need to write a document that sells an idea, product or service – perhaps a brochure, funding submission or proposal to work in a new way. Keep these 3 Ps in mind.

1. Purpose

Be sure you know what you expect your document to do.

In most businesses it is highly unusual for someone to say “I’ve read your brochure, here’s my credit card.”

In most cases your document is a part of the sales or influence process. The best it can usually do is to move someone to the next step – perhaps to make an enquiry or to get further information.

The content of your document should be designed just to move them that step. Usually it should not be filled with lots of detail – leave that for later.

A clear purpose is the starting point of clear communication.

2. Promise

Make your reader a promise. A promise that captures their imagination or that scratches where they itch.

For example: buy my widget and I promise to triple your income; or halve your operating costs; or drop 3 dress sizes. Your reader must be clear about what your product or service or idea can do for them, and it must do something that they are interested in, and that they value.

There are many ways of making a promise; you don’t have to say the words ‘I promise’, but you can. You could say “9 out of 10 business grow when they xyz”, by implication yours will too. Or use a bold statement like “The 3 Ps of effective brochures” – a promise that if you put my ideas to work your brochures will generate more sales.

Choosing the right way to phrase your promise depends on a good knowledge of your audience.

3. Proof

Anybody can make a promise, but readers are interested in knowing that you can deliver on what you say. We’ve all been let down and disappointed by broken promises.

So spend some time in your document proving you can deliver on your promises. You could:

  • explain your product and how it works
  • quote from scientific studies
  • talk about your experience and expertise
  • provide testimonials from satisfied customers
  • compare your idea with alternatives

But don’t overdo proof. Provide just enough to show you are credible.

When writing documents intended to influence people’s thinking or behaviour, remember and use the three Ps.

And one R – respect.

Never bully your audience or treat them as fools. Write in language they can understand, address issues that concern them and view your communication from their perspective.