Tag Archives: bridge

It’s not your text

Hey, wow. I was looking on the internet and — what do you know? — I found a list.

Yes, I realize that the internet is full of lists. Many of them exist simply to entice us to click. A few might entertain or inform, and then I forget them in 5 minutes.

A very few are worth recommending. One such is this list of rules for editors, compiled by the Baltimore Sun‘s John McIntyre. If you’re in any part of the writing business, hurry on over to The Sun and take a look.

I lingered long over Rule 4: It’s not your text.

You are in the middle of things. You have a responsibility to assist the writer in achieving their purpose. You have a responsibility to the publication to maintain its standards and integrity. You have a responsibility to the reader, the party most commonly overlooked in these operations, to meet their needs of clarity and usefulness. Your personal preferences are subordinate to these responsibilities.

quill penSo it is with editors, and so it is with technical writers as well. We have a responsibility to the company we represent, to maintain its standards and integrity (to the extent it has them), and to present its products in such a way that our readers can use them effectively.

We also have a responsibility to the reader, to meet their needs of clarity and usefulness. This is our paramount responsibility, because this is the one we have to get right. We might get away without perfectly reflecting the company’s style or brand image, or without perfectly describing the product’s features. But if we don’t meet the reader’s needs, so that they stop reading and walk away (or dial tech support), we’ve failed completely.

stone bridgeI’ve heard the technical writer described as the bridge between subject-matter expert and reader. I used to bristle at that metaphor: I thought it implied a passivity on the part of the technical writer, as if we were nothing more than a conduit carrying information from one actor to another. “People walk on bridges,” I remember complaining.

Now, in my old age, I’m more comfortable with the bridge metaphor. Maybe I have a higher opinion of bridges: some of them are engineering marvels, and even the simplest ones are mighty useful. But mostly, I think, I better understand that it’s not my text.

Yes, I play an important role in the transaction between expert and reader. But it’s not about my personal preferences. If I want my name on something, I should write a novel.

My job is to make the information good, and that’s nothing to sneeze at. But it’s not my text.

Advertisements

Watch out for Survey McSurvface

If you want to improve your product’s documentation — or the whole user experience — there’s a tried and true technique: do a survey. At least that’s what we’ve always been told.

Let me tell you a couple of stories.

The boat

boaty

Come to think of it, “HMS Coke Can” might be a more suitable name. (Source: Natural Environment Research Council)

Earlier this week the British government, in the person of Science Minister Jo Johnson, announced that its new research vessel will not be christened Boaty McBoatface, even though that name won an Internet poll with 4 times as many votes as the runner-up.

Evoking memories of Graham Chapman’s Colonel, Johnson declared that the winning name was simply too silly and that a more “suitable” name will be chosen instead.

The bridge

Much the same thing happened in 2006 when Stephen Colbert, in his Comedy Central days, encouraged his viewers to vote in an online contest to name a bridge in Hungary.

megyeri.jpg

The Almost-Colbert Bridge (Source: Wikimedia Commons / Civertan)

Stephen Colbert Bridge won, garnering more votes than there are people in Hungary. Things hit a snag when Hungary’s ambassador to the U.S. good-naturedly informed Colbert that in order to be honored, he would need to be (a) fluent in Hungarian and (b) dead.

Today the bridge is known as Megyeri Bridge because it connects two towns whose names end in -megyer. I’m not sure that’s better than Colbert Bridge. But I’m not Hungarian so I guess it’s none of my business.

The moral of both stories? Surveys and polls can be entertaining. But their results aren’t always useful.

Your customers

Now I know that nobody is going to turn your customer survey into a prank. Still, when you ask your customers what they want, they don’t always know. Their responses likely will be knee-jerk, not reflective of careful thought.

Want a better index? Sure, that sounds good. Bigger icons? Why not? Soon you’ve got a lot of “results” that you can turn into action plans. Yet you’ve missed the issues that truly affect the UX.

The solution? Don’t ask your customers what they want. Instead, ask them how they actually use the product, and ask them what things give them trouble. Do they have difficulty finding the instructions they need? Are the instructions relevant to their work situations? Are there product features that go unused because they’re hard to set up and maintain?

When you ask your customers how they really use your product, then you can use your own know-how to decide how best to make their lives easier.

There’s an even better way, although it’s harder than administering a survey. If you can observe your customers at work, if you can see for yourself where they succeed and where they struggle, then you’ll know exactly where to focus your efforts at improving both the documentation and the rest of the product.

So there you have it.

Surveys that ask customers what they want: too silly.

Surveys that measure the way customers actually use the product: much better.

In-person observation (including usability tests): harder, but best of all.

Tell me about experiences you’ve had improving your products by gathering information from your customers.