Better RFP Responses & Management
 
Impenetrable Text: Bug or Feature?

Impenetrable Text: Bug or Feature?

It’s a trick question, right? After all, any editor will tell you that impenetrable text is an all-too-common bug. Here’s an honest comment on scientific literature from a life-sciences PhD at the University of New Brunswick.

I will cheerfully admit to the “bug” half. Yes, much of our literature is poorly written. We write in complex sentences stuffed with the biggest words we can possibly find. We adore acronyms, seizing every opportunity to coin a new one, or seven if we can possibly manage it. We scrub any hint of personality from our writing, fetishizing the passive voice, avoiding informality like contractions, and ending up with colourless text that sounds just like everyone else’s. – Scientist Sees Squirrel

So, how could it possibly be a feature? Read on.

. . . like all writers everywhere, we write for a specific discourse community. A discourse community is a set of people who share background knowledge and context, vocabulary, and interests. Before you write anything – a scientific paper, a recipe, a piece of Star Trek erotic fanfiction – your first move should always be to think about the discourse community you’re aiming to be part of. Or, in simpler terms: ask yourself, who are your readers?

How does this apply to Proposal Land? Thusly. Many editors are not expert in the content they’re editing: They’re not airport operators or building managers or software developers or call-centre supervisors or management/PR/HR consultants or  tradespeople of any sort. But, boy, do they write good.

If we know that both non-experts and experts will be evaluating our proposal then our task is to take all the value that editors bring in clarifying and improving technical text without losing any part of the text’s communication value for any experts who are also aboard.

If we really don’t know who’s involved, then we’d better assume the presence of both.

One good approach is to start every section with a plain-language statement of the problem/target and the proposed solution/approach along with its benefits. That’s to convince the non-experts. Then get into as much detail as needed to convince the experts. It’s not either/or, it’s both/and.

Should it be easy to read? Simple sentences and bullets? Plainer words where possible? Few (or, at least, defined) acronyms? Active voice? Helpful graphics? Absolutely.

Should it have precise technical detail, appropriately expressed as per domain/discipline/industry norms? You bet.

 

2 Comments

  1. Jim Taylor

    I once edited a book for which we took your advice literally. We printed the straightforward text as usual, on white (sort of) paper. Where the author went into theological niceties, we printed those sections on grey background. Gray? For the little gray cells, of course.

    Jim T

    1. Isabel Gibson

      Jim – 🙂 I think that’s a great idea. When I did the layout for my technical manual on proposals, I did the straightforward text on white, and the illustrative stories with a shaded background. Not quite the same, but a similar result in separating two kinds of content for easier access.

Comments are closed.