Tag: devspeak

If the aid sector is to communicate more effectively, we must do more than tame the rampant devspeak that Duncan highlighted in his recent blog. Instead we should focus on presenting a clear and consistent message using plain language principles, which cover so much more than the individual words that we choose.

I’m the Plain Language Editor for Translators without Borders so devspeak is my constant companion. Much of my working day is spent deciphering terms and encouraging writers to use simpler alternatives. I’m aware of the chaos and confusion that devspeak can cause. But I think the bigger communication challenge facing our sector is a general lack of clarity and focus in our writing, and an inexplicable resistance to plain-language writing.

All aid workers should write in plain language

Whether we write for colleagues, government ministers, or refugees, plain language makes exchanging information a more efficient process. We operate in a multilingual environment that is full of linguistic tripwires and pitfalls. Native and non-native English writers of varying competencies communicate with native and non-native English readers of varying competencies. All of us face conflicting demands on our limited writing and reading time.

Ellie Kemp oversees Translators without Borders’ humanitarian work in Nigeria and in the Rohingya refugee response in Bangladesh. She believes that plain language is an overlooked factor in many humanitarian responses.

“Humanitarians can’t promote two-way engagement, empower affected people, or stimulate informed debate if we write in a convoluted way,” she says. “In Bangladesh, the response uses five languages; if the original English is unclear, the consequences are amplified across the other four.”

Earlier this year, Translators without Borders interviewed 52 humanitarian field workers responsible for surveying internally displaced people in north-east Nigeria. The findings highlight potential data quality issues stemming from a failure to use plain language.

“We tested the field workers’ comprehension of 27 terms that they regularly use in survey questions and responses,” Ellie explains. “We identified misunderstandings and misinterpretations at every stage of the data collection process.”

Plain-language writing can help navigate our multilingual environment, yet native-English writers in particular are oblivious to the confusion we cause as we extrude our un-plain language onto the page.

So what are the characteristics of plain-language writing? Here are the ones that I think have the biggest impact on readability.

Define your peak message and state it early

Plain language requires writers to define the most critical aspect of their content and to communicate that consistently. Before I edit any content, I ask the writer to define the “peak message,” or the message that must stand out. In a move that makes me one of the most annoying people in our organization I insist that the peak message is fewer than 20 words.

But to win back the affections of my colleagues, I apply the same rule to myself. So before I drafted this blog, I defined my 16-word peak message as, “Plain-language writing is not only about avoiding devspeak; it’s about presenting a clear and consistent point.”

Create a logical structure and layout

The inverted pyramid model helps to arrange content logically and keep the reader focused on the peak message. It requires writers to arrange paragraphs in order of importance, and to arrange the sentences within them in order of importance too.

The next step in plain-language writing is to make the content physically clear. Four basic formatting principles that improve clarity are:

• limit paragraphs to five sentences;
• maintain an average sentence length of 15-20 words, and a maximum of 25;
• use informative headings every four or five paragraphs; and
• use graphics, but only if they make your message clearer.

Then worry about individual words.

Favour bold, direct verbs in the active voice

Verbs are powerful tools for clarifying your message. As with so many of life’s big choices, favour the strong, confident, single type. “It is recommended that writers give consideration to selecting verbs that might be more bold,” is only a slight exaggeration of the evasive verb structures that I regularly encounter. I’d change that to “Use bold verbs.”

And in choosing your bold verb, remember that passive voice is one of the last refuges of the uncertain writer. Consider the following passive voice construction:

“It is thought [by unnamed and unaccountable people] that the active voice should be used [by unnamed and unaccountable people].” This sentence provides little clarity for the reader. Compare it to “The Plain Language Editor wants writers in the humanitarian sector to use the active voice.”

Use the simplest tense

Some tenses require less cognitive processing than others. For non-native speakers the simple present and simple past tenses are typically the clearest. For example, “we write” or “we wrote.”

Continuous tenses (“we are writing” or “we were writing” or “we will be writing”) are less clear. So are future tenses (“we will write”, “we will have written”).

Use pronouns carefully

Pronouns can make a sentence ambiguous, so use them sparingly. “When communicating with refugees, humanitarians should provide information in their own language,” leaves the reader wondering whether to use the refugees’ or the humanitarians’ language. A confident English speaker might assume they know, but plain language relies on clarity, not assumptions.

Rethinking devspeak

From a plain-language perspective most devspeak is merely pretentious and annoying. Readers typically understand a sentence even if it contains an unexpected neologism. Few editors care if readers need to use a dictionary occasionally; most of us pretentiously and annoyingly believe that an extended vocabulary is a thing to aspire to. But confusion and ambiguity is not something to aspire to, so before you use devspeak, look for a simpler alternative.

You’ll probably find that if your peak message is solid, and the flow and format is logical, you won’t need devspeak after all. Clearly, it’s not essential.

You can stop reading here if you like, but I thought I’d add a worked example of how all this works….

A practical illustration

Here’s an example of applying plain-language principles to a donor report earlier this year.

The paragraph on the left is the original. What opportunities can you see for applying plain-language principles to that version? I saw several, so the author and I worked together to improve the original. We agreed to replace it with the paragraph on the right.

This short training course was designed to enhance [name removed] and other humanitarian organisation staff’s capacity to act as interpreters in the course of their work, often in the context of sensitization sessions, case management or household surveys. The content focused on the role of interpreting for humanitarian action, while also shedding light on broadly applicable modes and principles of interpreting. Learning methods combined exposition with interactive sessions, including group work and simple role play exercises that were not only meant to illustrate how to interpret effectively but also laid an emphasis on key ethical issues to be considered while interpreting. Topics covered included interpreting for children and vulnerable populations, and developing multilingual terminology for humanitarian interpreting. (116 words)

Bilingual staff at [name removed] and other humanitarian organisations often interpret informally during sensitization sessions, case management activities or household surveys. We designed this course to help them interpret more effectively.  The course covered: ●     the role of humanitarian interpreting; ●     broad interpreting principles; ●     interpreting modes; ●     interpreting for children and vulnerable populations; and ●     developing multilingual glossaries. Trainers combined instructional with interactive learning methods such as group work and role play exercises. The interactive exercises illustrated effective interpreting techniques and emphasised key ethical issues related to interpreting.  (83 words, or a reduction of 28 percent. Now imagine that reduction extrapolated across an entire report).

Here’s what I saw. From a plain-language perspective, there were several issues:

• Long sentences (average 29 words, maximum 40 words).
• Passive voice (“the course was designed”).
• Uncommon words (“exposition”).
• Complex terms (“multilingual terminology for humanitarian interpreting”).
• Related ideas were separated in the text.

Did you get them all? Did I miss anything? Which version do you think is clearer? What techniques do you use to make your own writing as clear as possible? Let us know (in plain language, of course).

This blog post is adapted from the original, published on the ‘From poverty to power’ blog. It is a response to ‘Which awful Devspeak words would you most like to ban?’ by Duncan Green, Strategic Adviser for Oxfam GB. 

Written by Kate Murphy, Plain Language Editor for Translators without Borders.