Where writing and customer service collide.

The Great Morale Reversal of 2009

2010-01-02T09:19:00.018-05:00

This holiday season, I found myself in a downward morale spiral - a combination of bad weather, crowded malls and a long shopping list. Thinking it would save me some time, I ordered a pair of boots from Zappos.com but, upon reading the shipping notice, I discovered that I had ordered the women's version of the boots and not the men's. So much for saving time. I picked up the phone, lowered my expectations and called Zappos.com. This is when the great morale reversal of 2009 began.

I called at around 8:00 in the morning. Someone answered the phone on the 1st ring. A real person. A real person who wasn't in a call center on the other side of the world. I explained to her my mistake and asked her how I go about fixing it. I would need the correct boots ordered and shipped and a return of the wrong boots which hadn't arrived yet.

The customer service rep then said, "the men's boots are actually more expensive than the women's, but I'll give you the lower price".

Then she said, "I'll ship these new ones to you overnight so you don't have to wait any longer to get them."

Let me remind you that this whole issue was my fault - I ordered the wrong pair of boots - I caused this.

Anyway, Zappos didn't have to go to these lengths to make me happy, but they did. And because of this, I tell other people to shop there and I plan to shop there again in the future. That means more revenue for Zappos, plain and simple.

This isn't a new story. We've all read about and maybe even experienced customer service like this (L.L. Bean comes to mind). But what surprises me is that it's still the exception rather than the rule. Maybe because it's difficult, companies don't pursue it. Maybe because it's hard to link good customer service with increased revenue, companies don't spend the money to make it happen.

And why am I writing about this? Because technical writers create what often represents the first customer service "touch-point" for a product. When one opens a toy, one must read the directions. When one buys software, one must read the manual.

That customer is my audience so I think about these things a lot. This isn't to say that technical writers can make software users as happy as Zappos made me but, if we acknowledge that Zappos has set the bar, and we aim for it, our readers will be glad we did. Plain and simple.

Happy New Year!

User Guide as a Guide

2009-11-24T11:20:00.001-05:00

I recently read an article by Michael Hughes called "Users as Decision Makers".

His article is here: http://www.divshare.com/download/6513696-0d8

Michael's Blog is here: http://user-assistance.blogspot.com/

The gist is that product documentation often fails in its lack of guidance. In other words, there's too much information on what one can do and not enough information on what one should do.

And it's a very good point.

Knowing that a software setting can go from 1-89 is important, but what are the implications of the different values? What should I set it to so that I achieve my desired outcome?

Maybe this is one of the reasons that product documentation gets a bad rap from user communities; why they hate being told to "consult the manual" before calling for support. Most users of software are very good at recognizing the various interface elements and how they work - drop-down menus, radio buttons, fields and forms - these things don't need to be explained, at least not as much as what users should do with them.

Instead of "Click the drop-down menu and select a value between 1 and 89", a manual should explain how the settings will affect the user's goal. The user guide should really be a guide.

Anyway, Michael's article makes a great point - one that all technical communicators should keep in mind. Read it and I think you'll agree.

What size are your blinders?

2009-02-01T20:45:00.000-05:00

I got a very friendly email recently informing me that my website contained a typo (Thank you again for that, emailer who will remain nameless).

And sure enough it did - a glaring one. Well, at least I'm not in the writing business. Wait... oh.

Here's the thing - we all have blinders on. We may not be born with them, but we develop them over years of doing the same tasks over and over again. Anyone who has ever poured juice into their cereal or tried to start a running car knows this.

For me, it's all about comfort zones. When you're in a comfort zone, your attentiveness sort of idles. When you're out of a comfort zone, your survival skills kick in, boosting your attention to things around you.

"So what?", you ask? So, be sure to exercise your attention to detail by leaving your comfort zone from time to time. It may not feel productive, but it will likely keep those blinders from growing into the side of your face.

The bigger picture

2008-10-15T15:00:00.004-04:00

Most enterprise software companies write up a special Release Notes document to accompany a new version of their product. The majority of Release Notes that I have come across are filled with the obligatory "fixed bugs" and "new features" lists.

I know for a fact that most customers do read Release Notes. They need to in order to check for bug fixes that impact their implementation or to learn about features that might help their users.

What a great opportunity to shine a spotlight on your application, regardless of what's new or fixed?

Who says the Release Notes have to be exclusively about that release? Why not emphasize new features in the context of existing ones? Or highlight fixed bugs and how they now allow for increased productivity in your product.

In other words, give the facts but don't miss an opportunity to show your customers the bigger picture.

Recipe for success

2008-10-01T08:00:00.002-04:00

I enjoy cooking and I wonder if it has anything to do with the documentation involved.

Documentation for cooking = RECIPE.

I can honestly say that, without the reliable format of the common recipe, I would neither excel at nor enjoy cooking.

According to my friendly neighborhood etymologist (http://www.etymonline.com), the word recipe was originally used by physicians who wrote it at the head of prescriptions. It meant "instructions for preparing food". So, there is no question that these instructions needed to be both precise and concise.

Look at any recipe today and you'll most likely find the following elements:

There is a title: what you will be cooking

There is a list of ingredients: what you will need in order to cook it

There are the steps of preparation: how you will cook it

Isn't simplicity delicious?

Hot off the presses

2008-09-26T11:00:00.005-04:00

I'm the proud owner (but not quite possessor) of the new G1 smart phone from T-Mobile. I get to wait a month before I get to actually have it so, in anticipation of my new toy, I got a hold of the Getting Started guide for the G1.

I did this for two reasons: 1) to learn about what I had actually bought and, 2) to see how T-Mobile approached this new user manual.

Aside from the unfortunate and glaring typo on page 18 (Goggle Mail), it's a nice piece of writing. It informs readers on the basic anatomy of the phone, how to turn it on, and other requisite details, but it succeeds particularly well for 2 reasons.

Layout The document is written primarily in landscape layout with 2 "pages" of content on each real page. This means that the writer didn't really expect people to print out the file - good assumption - and that, to maximize what a person will see on their computer screen, landscape was the way to go because computer screens are oriented in landscape themselves. Smart.

Just the Facts The sections of the document are very short and straight forward, instructing readers on how to accomplish simple tasks. There's little to no fluff. Good.

Add these characteristics together and you've got a very readable document. Maybe more importantly, you've got a document that's easy to skim - who's really going to read anything like this cover to cover anyway?

So, T-Mobile, you succeeded in knowing your audience and giving them a very friendly user manual. I am sorry though that today's modern spell-checkers can't catch it when you spell perhaps your most important business partner's name wrong. Call me - I do proofreading.

Don't build a closet for your skeletons.

2008-09-22T08:00:00.001-04:00

If the software you're selling is going to have a few skeletons - and most likely it will - then don't give them a closet to hide in.

It's difficult to design software that is 100% self informative and logical in its use, especially if that software is complex or has more "under the covers" than on top. And your customers know this - they most likely don't expect perfection.

So, if your product has some areas that might not make the most sense, or are downright confusing, say so. Don't pretend in your documentation that these areas are normal or logical if they aren't.

Now, I'm not suggesting you write a chapter called Where Our Product Sucks and Will Drive You Crazy, but you should include a section for Possible Problems where you can provide tips for navigating the tricky areas. Your customers will show their appreciation for this by a) not calling your help desk, b) training their colleague users, and c) not being annoyed with you.

Those are nice outcomes for such a simple thing, don't you think?

(Oh, and for your next release, maybe you can improve on those tricky areas and use the same Possible Problems section to brag about the improvements you've made.)

What matters most?

2008-09-18T05:31:00.009-04:00

I'm not an English major, so I know from experience that perfect grammar doesn't equate to perfect documentation. So what matters most?

Here're my top 5 writing priorities when it comes to helping your customers help themselves:

Know what you're writing: Do your customers need a reference document with organized lists and tables of data? Do they need a step-by-step cookbook for how to progress through a process? Or maybe they just need some well thought-out diagrams? If someone's expecting one type, and you give them another, you're wasting their time and they aren't likely to forgive you.

Know who you're writing for: Yes, I know I shouldn't end a phrase with a preposition, but I'm ok with it. I trust you'll be ok with it. See that? I know who I'm writing for. Seriously though, if you're writing for techies, then give them what they need. If you're writing for parents who need to know how to assemble a toy, give them what they need. Your audience should guide your writing almost as much as your product should.

Call it what it is: If it's a box, say so. If it's a button, say so. If it's a tab, well, you get the idea. So many products these days, especially in the software world, create their own interface elements and try to create new language for them. So, do your customers a favor and call the things what they are.

Don't create dead ends: Never allow your customers to get trapped in your product documentation. Make sure your writing always has a way out or a way sideways.

Let your product be heard: I've helped a number of companies write their product documentation and most of them feel inclined to write about every detail, option, variable and setting. But if the product informs the user about a certain feature, why waste time and space writing about it?

The best self-service option is the one that isn't needed. If you do this well enough, you won't even need product documentation.

Can you imagine that?