A word nobody defined
We are hired to know the things a client should not have to: what a DNS record does, why a certificate expires, which of two caching strategies will show somebody yesterday's price. Knowing it is the job. Translating it is also the job, and it is the half that gets skipped - usually because the person doing the translating stopped noticing which words are ordinary to them and which are not.
In 2023, Rolls-Royce and a software supplier ended up in the High Court over a system for configuring cars. The contract was reported at about fifteen million euros, and the argument came down to two words: "technical acceptance". Nobody had written down what they meant - not in a way that settled anything - so a judge had to decide for them, and read them as meaning the customer's own testing rather than the supplier's.
The supplier said the scope had crept. The court noted that no formal change requests had been raised, which was the mechanism the contract had for exactly that, and put the delay down to the supplier's own resourcing. Two businesses, a lot of money, and a phrase that had been doing a job nobody had checked it could do.
Every studio has a smaller version of that meeting. In ours, somebody says "we just need it to be responsive". The designer hears "it works on a phone". The developer hears "the layout reflows". The client hears "it looks right on my iPad". Three people nod, agree warmly, and discover in month three that they agreed to three different things. The word was never the problem. Leaving it undefined was.
Jargon is not evidence of expertise
In 2000, Luton Council described go-karting lessons for excluded children as "a multi-agency project catering for holistic diversionary provision to young people for positive action linked to the community safety strategy and the pupil referral unit". It won a Plain English Campaign Golden Bull, which is the award for exactly this. Somewhere in that sentence is a good scheme for children. It is not the part a parent can find.
The Met Office collected one in 2011 for "probabilities of precipitation" when people wanted to know whether to take a coat. Its defence was fair, and worth hearing: precipitation covers rain, sleet, snow and hail, so the word was more precise. That is the whole trade in one example. Precision and clarity are different jobs, and the writer - not the reader - is the one who has to do both. You can keep the precise word and add the sentence: "chance of rain, sleet or snow".
We have the same instinct, and it is a strong one, because sounding like an expert is how you get hired. It is also how you end up with a client nodding at a word they will not be able to explain to their own board.
What the vague version costs
In 2013 the National Audit Office reported on Universal Credit and identified, as a source of many of its problems, the department's "absence of a detailed view of how Universal Credit is meant to work". By then it had spent £425m, more than 70% of it on IT, and written off £34m of systems. The words "we know what we mean" are not a specification; the gap between them and one is expensive.
It is not only Whitehall. A 2005 study of four NHS acute trusts found that senior managers and clinicians were unclear about what systems the national programme would deliver, and when. Some trusts held back their own IT work while they waited to be told. A project does not have to fail to do damage; it only has to stay vague long enough for everyone to stop making decisions.
Why plain English is not dumbing down
There is a study worth knowing about, on which version of a contract people actually understand. Researchers tested 105 practising lawyers on contracts in the original legalese and in plain English with the same meaning, then compared them with 108 laypeople who had taken the same test in an earlier study. Both groups understood and remembered the plain versions better. The lawyers also rated the plain ones as higher quality, no less enforceable, and their authors as more hireable.
The people who write contracts for a living preferred the plain one, which settles it. Precision is not the same as complication, and a sentence a client has to read three times is not a more serious sentence.
What we do instead
- The consequence first, the term second. "Pages will open in about a second on a phone, because we are serving the images from somewhere closer to the visitor" - and then, if it helps, the word CDN.
- Define it once, or don't use it. If a term changes a decision, it gets a plain sentence in the same email. If it does not change a decision, it gets cut.
- A decision is a decision when it is written down. In your words, dated, in a place you can find without asking us. A conversation is how a decision is made; it is not where one is kept.
- One named person, not a queue. Somebody who knows the history and can say yes - so you are never explaining your own project to a stranger.
- Draw the thing. Where the data goes, what happens after a form is sent, which of the three systems owns the customer record. A drawing survives a meeting better than an analogy about plumbing.
- Read it back. Every meeting opens with our summary of what you decided last time. If we have it wrong, you find out for the price of a sentence rather than a fortnight.
What it buys you
Fewer rebuilds, because the expensive misunderstandings happen before anything is built. Decisions you can defend to whoever signs the invoice, without a translator. A handover you could actually use, and code you could take somewhere else.
That last one is the real test. If you ever want to sack us, you should be able to do it without hiring someone to explain what we did. Consumer law already demands plain terms when you sell to a consumer; between two businesses, nobody is making us write this way - which is exactly why it is worth asking for.
We still use the technical words. They are the tools. We just do not hand you the toolbox and ask you to build it.