Tag Archives: usability

Making a difference, forever

Be careful what you post on the internet, they say, because once you do it’s out there forever.

I suppose that’s true. In fact, it’s been true since before we had an internet.

In the beginning….

In September 1980, about a year after I hired on at IBM in Kington, New York, a colleague and I started producing a little newsletter to help the technical writing staff master the intricacies of our computer system.

In those days before personal computers, even though we were writing books for datacenter professionals, most of the writers had received only rudimentary training in the practical aspects of using computers to do their work. Our system, the same one the engineers and programmers used, was complicated and not especially user-friendly. (The term user-friendly itself was shiny and new in 1980.)

I think it was my colleague, Susan, who came up with the idea of a newsletter. I eagerly agreed to help. I don’t remember who came up with the name, VM Voice. VM, then as now, stood for Virtual Machine and was the name of that intimidating computer system.

vmvoice

Our maiden issue: Starting with the basics

We started with the basics, gently introducing our readers to VM and its components. Over time we evolved to more complex and specialized topics, always targeting the technical writing staff and its particular needs. Each weekly issue ran to two or three pages — printed and then placed into everyone’s mailbox.

We did about 50 or 60 issues before the well of ideas dried up. Then time passed.

Fast forward to the present….

In March 2017 a longtime IBMer, preparing to retire, was cleaning out his desk. He found a stack of old papers and spotted a familiar name on the top sheet: the same last name as another guy in his office. “Know who this is?” he asked.

“Well, my mother worked at IBM. I’ll ask her.”

Soon the stack of papers was in the mail to Susan, herself long retired. She reached me through a common LinkedIn friend and asked if I remember VM Voice.

Of course I remember. It’s a wondeful memory.

I consider VM Voice to be one of my career’s biggest success stories.

  • We saw a need and we met it.
  • We had fun, especially trying to present complex, even daunting, subject matter in a way that our audience would find comfortable and reassuring.
  • We got instant feedback, and it was almost always positive.
  • We made a difference: the information in VM Voice — homespun as it was — made people better at their jobs.

Seeing those scanned copies of VM Voice reminded me that when you plant a seed, you never know precisely what will happen. When you publish something, either online or in the old-fashioned paper-and-ink way, you never know when and where you might see it again, or who might be affected by it.

The first moral of the story: In technical writing you have lots of chances to make a difference. Never lose sight of that, even when the work seems like drudgery.

The second moral: Before you publish something, make sure it’s good.

Because the internet has a long memory.

And because some people never clean out their desks.

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.