The success of easy-to-read fonts and familiar sentences may have psychological reasons – and far-reaching consequences for professional writers.
The Boston Globe recently ran a piece by Drake Bennett called “Easy = True“: According to psychologists, people are more likely to perceive something as true when it’s familiar and hence easy to think about. The underlying measure is called “cognitive fluency”. (Now, I’ve never heard of that, and it seems so incomprehensible, I don’t think it’s true… 😉 ). It’s not so much the principle that’s the big news, but rather its effects.
Clear and Easy
For the written word, this means:
… when presenting people with a factual statement, manipulations that make the statement easier to mentally process – even totally nonsubstantive changes like writing it in a cleaner font or making it rhyme or simply repeating it – can alter people’s judgment of the truth of the statement, along with their evaluation of the intelligence of the statement’s author and their confidence in their own judgments and abilities.
Of course, writing that’s clear and easy to understand has long been a standard objective of technical writers. It’s simply more efficient and lets our users get on with their tasks.
But apparently, there are additional effects: Documentation can shape users’ opinion of a product and its manufacturer (my employer, that is). ‘Clear and easy’ documentation is seen as truthful, the product as reliable and the manufacturer as professional. The inverse seems true, too: As the medium is the message, readers struggling with obscure fonts “unwittingly transfer that sense of difficulty onto the topic they’re reading about.”
Confident and Alert
‘Clear and easy’ documentation can also increase user confidence in product which can in turn contribute to a product’s success. (For more on boosting user onfidence, check out Kathy Sierra’s brilliant “Kick Ass Curve” that shows how to overcome the “Suck Threshold”.)
Studies also make a case for texts that are not clear and easy: If you want readers to be alert and attentive and “to prevent them from making silly mistakes, make them work to process the question: make the font hard to read, the cadence awkward, and the wording unfamiliar.” – The example relies on answers to inconsequential test questions, so I’m not ready to apply this to writing obscure warning and danger notes just yet…
What do you think? Is this a new and applicable insight – or merely science catching up with industry practice?
Filed under: articles, usability | Tagged: boston globe, cognitive fluency, drake bennett |
Hi Kai,
On the web, graphic designers, programmers and others all contribute to the content.
Some are trained, others not.
and few really see & value the difference.
Ivan
Thanks for your comment, Ivan. I agree, in many cases it’s natural and efficient that other professions contribute, along with writers. And that’s fine.
Yet, those trained in writing – whether they’re writers or not – have a chance to raise the bar with their skills and their passion. And raising that bar can take all kinds of shapes: It can mean keeping an eye open for such studies, or helping users over the suck threshold.
If you perceive something as true, would you say that it’s also authoritative and trustworthy? Research has found that when it comes to getting information online, people trust the word of their peers—even someone they don’t know—before they trust the company or the official documentation, because they’re seen as having ulterior motives (that is, to make money from you). They give authority to their peers before giving it to the company.
So if we look beyond sentence structure and typefaces, conveying a familiarity as if we’re a peer of our users may lead to the “easy” and “true.” And then maybe we’ve achieved the users’ trust, and they’ll make use of the documentation on a regular basis. But coming across as trustworthy to users is another of the challenges of tech comm.
Ben, I’ve been wondering the same thing. I can see how you get from clear and easy-to-follow wording to “yeah, that makes sense” – which is some kind of trustworthy, I guess. But I wouldn’t call it authoritative just for that.
I don’t trust the manufacturer’s documentation less than those of my peers. I find I use it differently, though. I tend to think the manufacturer’s doc show me how I’m supposed to use stuff (if I’m lucky). I look to my peers to tell me what’s worked for them, when I’m thinking: “Dang! I can’t believe I’m the first one to have this problem.” And, search engines to the rescue, usually I’m not.
When I’m writing my own documentation, I usually strive for that balance: Being close enough to peer users to help them out and anticipate their tasks and questions. And conveying the intended use of the product and the manufacturer’s authority. In that, “easy” writing is only one of the challenges…