Emotionally Intelligent Tech Writing?

I recently watched Dan Pink's pecha kucha presentation about emotional intelligence in signs. An emotionally intelligent sign is one that expresses empathy toward the reader. It made me wonder if we could have emotionally intelligent technical writing—writing that expressed empathy toward the user.

This might be easiest to imagine in the interface itself, maybe in an error message. When Word crashes, perhaps the message could say, "We're sorry, we made a mistake in our code and you've just stumbled into it. Word will have to close, but we'll do everything we can to protect your data. We'd like to fix this so it doesn't happen again, and it would help a lot if you could send the data Word captured just before it crashed." That's probably too long, but maybe that's what it would look like, more or less. It feels refreshingly honest, doesn't it?

What about in a message that isn't an error? Take empty search results. Usually we write something like "No files [or records or web sites or whatever] match your search criteria." That's fine—it's clear and polite, and that's what we usually strive for—but it isn't very helpful. If I'm looking for something, and whatever criteria I use don't turn up any results, I'm probably frustrated. Getting a "no results available" message is like getting a Game Over in the arcade. Drop in another quarter and try again. What if the message said "We can't find any files that match all of your search criteria, but there are 12 files of other types that match and 23 files without the word vacation." Maybe that would show some empathy with my situation by trying to offer help and also showing me that I might be close to finding what I want. It's also closer to what I would expect from a helpful librarian if I asked whether her collection contained any items that matched a certain description.

(Writing this message also lead me to think of providing extra functionality in the form of search results for similar queries. As is often the case, the writing and the design can help one another.)

What about external documentation, like an installation guide or user guide? I've mentioned my Seagate external hard drive previously; the package contains one short setup guide with just four words on the cover: "This won't take long." That's empathy. Think about it, by the time I get my new piece of hardware home and unpacked, my biggest anxiety is will I be able to get this working and if so how long am I going to have to spend on it? The cover puts me immediately at ease.

But it's probably too cute for most situations. What about something like Word's help for using Styles? The help system for my copy of Word XP has a topic called About formatting text by using styles that begins, "A style is a set of formatting characteristics that you can apply to text, tables, and lists in your document to quickly change their appearance." That seems okay, but it doesn't really express any empathy with how I might be feeling. I'm probably feeling frustrated, strapped for time, and anxious to know whether what I'm reading about is worth my time and whether it will solve my problem. Maybe an opening like this would work better, "If you haven't worked with Styles before, it will seem counter intuitive and it will take some time to learn. It will also take time to set up the Styles you want to use. But if you regularly create documents that share the same formatting and you want to make sure a document's formatting is consistent throughout, styles will do the trick and save you time in the long run."

Again it feels cutesy and it's longer, but maybe it has more warmth and maybe readers would respond well to that.

There's one other situation where we could express empathy: where we're forced to describe a feature that is awkward or obviously compromised. As technical writers writing on behalf of a company, we generally think we have to put the best face on a feature as though it made perfect sense and worked just how the user wanted it to. But maybe we lose credibility that way. Maybe we should just say, "It would be cool if you could save your search criteria. For now the best way to do that is to copy the text from the search field and save it in a text file. That's why the search field supports copying. It's not elegant, but it gets the job done for now."

Would that be so bad? What's wrong with a user guide—or a company—that sounds like a human being?