A lot of my job is e-mail. Administrative e-mails from my boss, assertive e-mails to my boss, informative e-mails from my team, donut-centric e-mails to my team, questioning e-mails from other teams, advisory e-mails to other teams, sales e-mails from vendors, bug-report e-mails to vendors, furious and confused e-mails from users, reassuring e-mails to users, garbled e-mails from some other country, clarification-request e-mails to some other country, automated e-mails from software. Lots and lots of e-mails.

I just get too many damned e-mails, and so does everyone else. I get so many e-mails that I can't turn on my e-mail client's notification features, since I would be swamped otherwise. Likewise, I have to route automated status e-mails originating from some of our software to special directories and have them automatically marked as read so that I don't have them clogging up my inbox (which, ideally, should just contain real e-mails that I need to address). I only answer e-mails if I am not in the zone, so that I don't lose massive amounts of time dealing with something synchronously that is designed to be handled asynchronously.

I've seen other people's e-mail clients at the office and they too are swamped with e-mails. They all have various methods of organizing things, some of which work well for them and some of which don't. What's important is that they all recognize that there is a problem with the quantity of messages and they're trying to figure out how to best deal with it.

But I want to talk about two kinds of e-mails specifically today. Two kinds that I work with a lot that I find can be improved dramatically with a little bit of effort: educational, example e-mails. These are my terms and so I'll have to define them properly before we all get as confused as a Windows user's first attempt using a Mac.

An educational e-mail is a message that serves to inform a group of people about some new feature you just wrote into the code base that everyone can use to save a lot of time. It's the kind of thing that you want to bring to everyone's attention because it's really useful, but it's probably very technical and boring.

An example e-mail is when you're trying to describe some abstract concept about what your software does to a user who doesn't seem to have any idea what you're talking about. You have to hold their hand until you can figure out if they understand you yet or not.

Now, the first thing you should notice is that e-mail is suitable for neither of these scenarios. The first situation is best handled with you in front of a room full of sleepy people if they have the time, or a message board of some kind of message board or document repository where everyone both present and future can look up the information. The second situation is best handled face-to-face with your users, so that you can really watch how they're using the software you've written so that you can know for sure if your thinking lines up with theirs. But, not all companies have internal message boards, and not all users are accessible to developers (my users are often on the other side of the world). So we're left with the simplest communication method everyone has access to and that everyone can figure out: e-mail.

In this world of hundreds of e-mails a week, how can you make sure that the educational or explanatory material in your e-mail will actually be seen, read, understood and, most importantly, retained by people reading it?

In the beginning, you don't really have any way of making people read your e-mails. You can try using fancy subjects but, ultimately, what will get your e-mails read is your reputation for writing high-quality e-mails. If everything you send out is proofread, clear and memorable, people will want to read your writing solely because it was you who wrote it.

The next step is making sure your e-mail is understandable by your audience. Like any presentation you give, you'll have to tailor your e-mail to its audience. It doesn't have to be anything complicated. Just go the extra distance to lower the barriers of understanding in your recipients. If you're sending something to another company, use that company's terminology for things instead of yours. Don't use unnecessary technical jargon when talking with end users. Just don't be confusing. You're sending an e-mail out to communicate, not to prove how smart you are. (Or rather, prove how smart you are by never confusing anyone.)

Retainment is the hardest part. With all of the information developers and users are getting from various sources, you need to make sure that your recipients don't forget everything you've told them once they open up another message. Personally, I find humour and outlandishness to be the best aid to prevent people from forgetting information.

Are you more likely to remember a chart if it's in black and white, if it's in colour, or if someone comments on the fact that the chart sorta looks like a velociraptor eating a boat? The fact that a velociraptor has nothing to do with the topic is what will help make it memorable, because it's jarring and unexpected. It's not boring. You're not going to fall asleep or think about your weekend golf plans if everyone is talking about the giant-claw-end of the chart, or the devoured-boat-end of the chart. Your increased attentiveness alone will help retain the knowledge, even leaving aside the fact that you'll remember "that velociraptor presentation" for weeks if not longer.

If I have to explain some data flow process in an e-mail I'll dress it up with example data from something extraordinary. I work for a company that makes food. If I'm giving an example about the ingredients list in a food, I'll throw in curve balls like lasers and motor oil to liven things up. Or if need to talk about how some software communicates with some other system, depending on the technologies used, I might make up a quick diagram that personifies the systems involved as Batman and Robin, talking with each other to decide on how to punish the Riddler. (Note that it is important to not go too far with metaphors, as that will lead to an unnecessary confusion of ideas.)

I'm not even the only one here who is aware of this method of making sure e-mails are read, understood and remembered. For example, our local vending machines are populated by a friendly superhero, whose harrowing tales are chronicled in e-mails as he rescues us from high prices and spoiled snacks. That's the kind of e-mail I would read even if I didn't use the vending machines at all. This is exactly the kind of thing that makes dealing with the swamp that is my inbox my enjoyable.

This doesn't apply to merely e-mail! If you're giving a presentation in front of a room of sleepy people, if you're creating a document to upload to a developer message board, if you're talking face-to-face with a user, or if you've just met some friendly aliens and you're trying out their direct-to-brain interface for the first time to communicate with them, these same ideas apply.

When you're giving a presentation, make sure it's exciting. Make sure the people are engaged, and that the examples and metaphors are fun and memorable. When you're talking to a user, walk him through your software using funny examples that he won't be likely to forget. He may walk out of the room thinking you're a bit wacky (or worse), but if you did it right he won't come back to you for help because he'll remember your zany examples. In the end it saves you both an incalculable amount of time in the long run and it was fun in the process.