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?

Handling Suggestions

I'm the sort of person who always has ideas about how things could be better—or at least different. Most of them I can't do anything about, except to pass them along to someone else in a position to consider them.

On the flip side, as a technical writer, many of the best suggestions for how to improve the work I'm doing come from other people. I lose sleep at night sometimes thinking about the suggestions that go unsaid, the great ideas that never make it to my inbox.

So I think the way we handle the suggestions we do receive is tremendously important. And from what I've seen, as someone who makes a lot of suggestions, most people don't know how to handle them.

Think of it from the perspective of someone offering a suggestion. When you pass along a suggestion to someone (something you don't have to do, and there are always other things you could be doing), what do you want?

• Validation – the sense that your idea wasn't completely silly
• Appreciation – a little thank you or some recognition that you didn't have to take the time to articulate the idea and pass it along
• A clear hand off – the feeling that you've done your duty and got the idea into the right hands so you can forget about it and get back to your own work

What does it take, then, to reward someone for passing along their suggestion and to encourage them to do so again? Just a simple thank you with some indication that the idea's worth considering and that you will in fact give it consideration. "Thanks Bob, what a great idea! I'll bring that up at the next team meeting."

Simple, right? But hardly anyone does this. Some people respond quickly with a detailed explanation of why the idea won't work. Ouch! If the explanation's correct, you've basically just told the person their idea sucked and thanks for wasting your time. But if the explanation's not correct, and you've missed the point of the suggestion by dismissing it too quickly, then the other person will either get drawn into a debate about the merit of their idea or they'll believe that you're incompetent. In any case, you're not likely to hear from them next time.

Some people respond with detailed instructions about how these sorts of suggestions are supposed to be filed—forms to be filled out, additional information to be provided, process to be followed. Hey, wait a minute, I'm doing you a favor here and you want me to invest a bunch of extra time? Like I'm not busy? No thanks.

Some people don't respond at all, or they say "Hey great idea" but you know they don't know what to do about it. In any case you feel like you've just tossed your suggestion into a bottomless well.

Finally, some people follow up diligently but continue to involve you in the process because it was your idea. They send updates and ask if they've understood correctly and ask what you think of the result. How are you supposed to know? If you had the skills or expertise to implement the idea, why would you have passed it on in the first place?

So next time you get an unsolicited suggestion from someone, thank them for taking the time out of their schedule to pass it along, show some appreciation for it, and let them know (firmly but politely) that you'll take it from here because you've got a system for handling these sorts of ideas.

And if you don't have a system for setting aside new ideas and reviewing them regularly, you need to make one. You're missing a hell of an opportunity.