Just to be clear: why Devspeak needs to adopt Plain Language

Following the recent FP2P discussion on devspeak, Kate Murphy of Translators Without Borders got in touch and said she needed to vent. Be my guest.

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 TWB’s 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, TWB 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. According to Ellie:

“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 organisation 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).

Subscribe to our Newsletter

You can unsubscribe at any time by clicking the link in the footer of our emails. For information about our privacy practices, please see our .

We use MailChimp as our marketing platform. By subscribing, you acknowledge that your information will be transferred to MailChimp for processing. Learn more about MailChimp's privacy practices here.


12 Responses to “Just to be clear: why Devspeak needs to adopt Plain Language”
  1. This is in interesting subject, but to me the ‘aid workers should write in plain language’ advice is similar to ‘eat less meat’-nothing wrong with it, but also not the entry point for systemic change.
    I think that a lot of bad writing happens not because aid workers can’t or don’t want to write clearly, but because ‘the industry’ has lost touch with writing plainly and naturally. Basically every document has input from numerous persons, gets edited according to ‘house styles’ and other format and often needs to comply with donor guidelines/language etc. Most writing also happens under the stress of deadlines, so copy-pasting, taking inspiration from similar reports and writing under a ‘just get it out’ imperative all harm plain language principles. If you add careful legal considerations, broad guidelines to write for a ‘general’ audience that should not be offended in any way, you end up ironing out many natural elements of how people write. Many aid workers have also unlearned plain writing during their socialization through university, internships in ‘prestigious’ organizations or being forced into writing roles that don’t fit their technical profile.
    Better language is a task that needs to include donors demanding fewer ‘reports’ where quality is often determined by length rather than content; large organizations should scrap big ‘flagship reports’ and annual reports that will die a lonely death on the pdf graveyard. NGOs should probably take more risks as well: If you receive a ‘plain’ report from ‘the field’ (perhaps even written by local staff or ‘beneficiaries’!) send it to HQ! And donors: Don’t demand reports that you know will be unreadable! And start blogging ;)!

  2. Robin Stafford

    So true though to be fair, every sector tends to develop its own language – different business sectors, civil service, Parliament and others. Where perhaps Development is different, certainly in the UK, is the heavy influence of academia, more so than any other sector I’ve worked in. Discussed with a mixed group of Development folk only last night. My going back to study a Masters in Development later in life was partly driven by wanting to learn the language. I learnt to write in ‘development speak’ but it’s no way to communicate.
    I found a refreshing contrast with a Development organisation where many of the people have a media and advertising background. Now they do know how to communicate and it shows in their work.

  3. Heather Marquette

    I think the article conflates 2 separate problems that add up to one bigger problem, but they’re not the same.

    One is bad writing. Bad writing does have a particular impact on people who aren’t native speakers, and it should be taken more seriously. However, passive writing vs active writing is a thing, for example, but it’s hardly devspeak; nor is the use of large paragraphs rather than shorter sentences and, when needed, bullet points. I’ve spent a lot of time marking essays, commenting on grad student drafts, reviewing papers etc, and there’s good writing and bad writing everywhere.

    That’s something that organisations can support staff with (dropping a preposition there…), including training with some of top tips here, or just improvements to grammar, but it needs to be handled with kindness. No professional wants to be told that their writing could be improved.

    The other is jargon. It’s important to remember why we have jargon, and this article from Baden Eunson at Monash University is a great read on it – http://theconversation.com/a-call-to-arms-lets-get-rid-of-all-the-jargon-37165. Eunson points out 3 stages for jargon:

    “1. Jargon starts out as a simple technical sublanguage: users devise abbreviations and acronyms that help speed up processes. It also helps reinforce group solidarity in that it becomes a semi-private language, but with clarity its main aim.

    2. Jargon can go over to the dark side when it is so dense that “outsiders” have difficulty understanding it. Euphemisms and deception may creep into the discourse of the in-crowd’s private language. Organisations may become less transparent, crisis-prone and unable to communicate with external people.

    3. Jargon becomes an object of ridicule in some quarters, with counter-jargon springing up as a defence mechanism used by the out-group (i.e. the majority). Jargon may prevail, however, as a means of maintaining organisational and social control.”

    Clearly we’re in stage 3 when it comes to devspeak, but it does still serve an important purpose. For a global, multi-lingual, multi-disciplinary professional community, devspeak helps people in the field communicate more easily. It contributes to a sense of a shared history and experience and to being part of a professional community. That’s hardly unique to development; every profession has this.

    The problem is when devspeak finds its way into communication to non-development audiences. Then it because exclusionary and irritating. It’s like going to your GP and having to say, ‘What’s the bottom line, doc?’ This is something that, I’m sure, we could all improve.

    But getting rid of devspeak won’t improve writing and communication with non-development audiences if non-technical language remains badly written. For me, that’s the big takeaway here.

    • Jim Tanburn

      Heather, the most important problem highlighted in the article seems to me rather a third one: the ‘peak message’. What is the writer really trying to say? We are often not good at articulating a clear, simple message that says something new. There are many pressures not to do so – one not yet mentioned is the typical loading up of the message and the messenger with multiple priorities and required perspectives. But pressures to avoid offence, toe the line etc. can also be there. We should always keep asking ourselves: “what am I really trying to say?”

      • Heather Marquette

        Absolutely – but that’s good writing really. I think you’re spot on on saying that we’re under pressure to often consider multiple messages, perspectives and priorities, sometimes in the same piece of work. That doesn’t always happen though, in terms of facing this pressure in every piece of writing.

        The point on jargon is much harder to deal with. When David Hudson, Sam Waldock & I wrote ‘Everyday Political Analysis’, we knew we couldn’t avoid jargon entirely, but we worked really hard to avoid political science terms like ‘agency’ and ‘institutions’. It was incredibly hard to do… you can let me know if you’d like if you think we succeeded or not! http://publications.dlprog.org/EPA.pdf

      • Kate Murphy

        An excellent summary Jim. In my experience, defining a single peak message is confronting for many people, especially those in a hurry, and with the multiple priorities you mention. Yet taking the time to do it helps writers produce clearer, more focussed text, which in turn increases the chance that a reader will understand it on first pass (the ultimate goal of plain-language writing). It reminds me of the quote, attributed to Mark Twain: “I didn’t have time to write a short letter, so I wrote a long one instead”. In our case, perhaps it’s more appropriate to say “I didn’t have time to write a clear report, so I wrote a rambling one instead”.

  4. Excellent wake-up call! I do wish to add that many entities (NGOs, governments and companies) disperse various reports to diverse audiences in –whenever possible– language suitable to the particular audience. That’s not to imply that al reports are well written; but simply that there is an effort by certain organizations to tailor communication for improved understanding.

  5. Kate Murphy

    Great to see such thoughtful and thought-provoking responses to this blog. Interestingly, a couple of comments draw a link between good writing and plain language. It’s potentially misleading to assume they are the same thing.
    An assessment of “good” or “bad” writing, requires a subjective judgement. I receive plenty of material for editing that has been declared “good” by colleagues, but which complies with few plain-language principles. My suggested edits to that material have less to do with whether the author is a “good” or “bad” writer, and more to do with how quickly a reader is likely to understand the text. In editing, I reflect my understanding of certain well defined and objective principles of plain-language writing. The US Government, the UK Government, and the European Commission have all defined consistent views on the elements of plain-language writing. The Plain English Campaign assigns the Crystal Mark to documents written in clear English. The International Plain Language Federation is currently developing an international standard for writing documents in plain language.
    Plain language devspeak could be the next big thing!

  6. Sue Hasselbring

    A key aspect of writing in plain English which is not mentioned is knowing who my audience is and keeping my audience in mind as I write. When I write thinking about the people I most want to understand this message, I do much better at writing in plain English.
    A helpful tool is readable.io
    Using this link https://app.readable.io/text/
    You can paste in some text and it will analyze its reading level, mark passives, mark long sentences and long words.

  7. rv

    “Humanitarian interpreting” is not the same as “interpreting humanitarian action” – perhaps When used in the latter phrase, the word “interpreting” is not about interpreting from 1 language to another, but about helping someone understand the “humanitarian action”.