Category Archives: Uncategorized

The forgotten step of document design

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

The need for user testing

We’ve probably all come across documents that just don’t make sense to us. Text that is obscure, or forms that don’t flow logically or that ask questions we are not sure how to answer.

Believe it or not, these are not developed by people trying to make life difficult!. They are usually designed by people with good intentions, but who are not looking from the perspective of the user.

Only the user can truly evaluate a communication device. As far back as 320 BC Aristotle said:

One must consider also the audience … the reader is the judge.

If a reader or user thinks it is unclear or difficult, then it is. It doesn’t matter how much work you’ve put into it, or how good you think it is.

In document design, common sense and professional experience will only take you so far.

Discussing your work with a colleague (peer review) will further improve your work.

But there are some things you can only find out from the users. This requires real testing, with real users in real (or closely simulated) situations. It is only as you watch people use your document that you see some of its shortcomings. Things that seem obvious or logical to you may not be to users.

The cost of poor design can be huge. A poorly designed form may generate thousands of phone calls to clarify it, or you may not get the information you need.

Yet, the cost of testing is not great – you can find out the majority of problems by testing as few as half a dozen users. However, testing is often skipped, usually for budget reasons. As with many things, there is never enough time or money to do it right, but there is always enough to do it again.

Reckless writing

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.

The writer’s opinion doesn’t matter – the reader is the judge

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.

Reckless writing is risky

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.

Persuasive communication

A lesson from Aristotle: a message is more likely to persuade when these three components are in appropriate balance. *

Ethos

The character of the person delivering the message. It’s about your reputation – what you are known for. It involves your qualifications – are you credible on this matter?; are you worth listening to?.

Ethos establishes trust and confidence in your audience. This is probably an area of strength for many in business or government.

However, you may need to establish your credibility if your audience has not heard of you or your organisation. Or you may need to rebuild your reputation if it has been sullied in some way.

Logos

Logic, rational argument and reasoning. Following through an argument based on established scientific principles.

This is the work of the mind. Again, this is often an area of strength in written communication, particularly for those working in government.

Of course, the depth and type of logical argument will vary depending on your purpose and your audience.

Pathos

Passion. The commitment you have for the subject you are presenting.

Passion is the power that makes things happen. Anybody who has achieved anything really great has had a measure of passion. This is the work of the heart.

Passion is often hidden in business writing, particularly in documents by government agencies. Being objective does not mean you cannot be passionate. They are not mutually exclusive. Allowing a bit more passion in your writing will increase its power. (Some marketers, of course, could do with much less pathos and a bit more logos!)

If you have a good idea, or if you want to change the way things are done, inject some emotion. Back up your case with solid logic and rational argument. But it is passion that provides power in both the workplace and the marketplace.

No matter what message you are delivering, it’s important that it is believable, that it makes good sense and that it is attractive. But remember, it is ultimately the reader who makes these judgements, not the writer.

Action

Analyse your information products for ethos, logos and pathos. Are they in the best balance to achieve your objectives?

* adapted from Peter Thompson, Persuading Aristotle, Allen & Unwin 1998.

 

5 ways to make business writing more powerful

Do the letters, memos or reports have the impact you want? Try these pointers.

1. Get to the point quickly

Tell readers what you are saying in the first sentence, or perhaps in the heading. Business writing shouldn’t keep people in suspense. Aim to give your readers the main point in the minimum of reading.

 2. Use ‘no fuss’ language

Short words, short sentences and short paragraphs – usually. Don’t write to impress, write to persuade. Use simple words as much as possible – more people understand simple words than complex words. Long sentences, even ones that are grammatically correct, can be difficult to understand because readers have to grasp many ideas before coming to a full stop for breath. One sentence, one thought.

3. Organise in a logical structure

Divide your writing into bite-size chunks – small units of information that your readers can get their heads around. Around 5 to 7 sections works best. In longer documents use sub-sections, again 5 to 7 at each level.

4. Write for readers

Write to meet your readers’ needs, answer the questions they have. Don’t dump everything you know on them. Think about the benefit readers’ will receive from investing time reading your writing.

5. Know your purpose

Business writing always has a purpose, usually to impact the thinking or behaviour of people. Be sure you know what you want your readers to do as a result of reading your document. Without this clearly in mind, how will you ever know what to write?

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.

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!

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)

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.

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.

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.