Into our reader’s world

You’ve parachuted onto a random stretch of road. You could be anywhere in the world. How quickly can you figure out where you are?

That’s the idea behind GeoGuessr, a web game that’s occupied some — ahem, too much — of my time lately. You might find yourself on a muddy road outside an Eastern European village, a lonely highway in West Texas, or a scenic drive on the Isle of Skye. (For that one, I guessed New Zealand — exactly halfway around the world. Zero points!)

Technical writers are used to this. We parachute into our reader’s world, and we do whatever we can to orient ourselves. We try to understand their work environment, their background, and anything else that helps us communicate with them.

A rocky coastline. A car driving on the right. Are you on Vancouver Island? Almost: you’re on the Olympic Peninsula, and that’s Vancouver Island in the distance. (Screen shot from GeoGuessr)

In GeoGuessr, you use whatever clues you can find. The game is based on Google Street view, so you can move back and forth, explore intersecting roads, and zoom in on your surroundings.

You’re looking for clues in topography, road signs (Do you recognize the language? Place names?), vegetation (Tropical? Subarctic?) — anything that would suggest or disqualify a particular location.

As technical writers, we look for clues to orient ourselves to the reader’s world.

Do we understand ourselves?

People don’t understand us. From the first time I met a technical writer, I’ve heard them — I’ve heard us — say that.

Our bosses don’t understand us. Subject-matter experts don’t understand us. Our audiences don’t understand us.

So, at long last, we have a chance to change that. A few days ago on Twitter, an app designer named Louie Mantia put this out to the world:

What‘s something that seems obvious within your profession, but the general public seems to misunderstand?

— Louie (@Mantia) July 1, 2018

As Louie’s tweet kept popping up in my timeline — with answers from journalists, lexicographers, and historians — I pondered how a technical writer might answer.

It was harder than I expected.

First take

First I thought of answering Louie’s question like this: Our top priority is writing directly to the people who use the instructions.

Then, in my imaginary dialog, I heard a resounding yawn from the general public: Of course you write for the people who use the instructions. For us. Who else would you write for?

Writing for the audience. While we technical writers trumpet it as a big deal, to our audience it’s so blindingly obvious that it goes without saying.

Second take

So I tried a different approach. Technical writers think in terms of how to use a product, not how the product works.

General public: We know that! It’s common sense, right? I don’t need to know how an internal-combustion engine works. I just want to change the oil.

Third take

Might the people understand us better than we think?

My third try: We work hard to tailor our information to our audience — in terms of both content and media.

GP: Hmm. The tailoring part, again, should go without saying. Maybe we don’t understand why you have to work so hard.

After all, when we get it right, it looks effortless. And when we get it wrong, it looks like we haven’t tried at all.

I began to realize that the skills we technical writers prize the most and discuss the most among ourselves, like audience analysis and media expertise, are things that — in the minds of our customers — ought to be second nature.

When we say that people don’t understand us, it’s not because they don’t grasp our skill set. It’s because they don’t realize how much energy we devote to honing those skills and to reminding each other how important they are.

Why do we need to remind each other of things that are so fundamental? Is it because our perspective is skewed from spending too much time with our work colleagues (especially Development) and not enough time with our customers?

Maybe it’s not that people understand us. Maybe we don’t understand ourselves.

Epilog

I finally did answer Louie’s question about what seems obvious to us but is misunderstood by the general public.

In the corporate hierarchy, technical writers see themselves as advocates for the people who use the product. #techcomm https://t.co/UK6rdysFdf

— Larry Kunz (@larry_kunz) July 3, 2018

What do you think of my answer? How would you have answered?

Do you think our customers would be surprised to learn how much time we spend talking about things that, to them, ought to be second nature?

 

 

 

 

 

 

 

Delighting in our language

Fellow technical writer Tom Johnson has entitled his blog I’d Rather Be Writing.

But lately it seems Tom wouldn’t rather be writing — at least, doing technical writing. In Tom’s words, the day-to-day job of technical writing, especially the plain language aspect, has “removed my ability to delight more in language and to express myself in more articulate, interesting ways.”

Tom describes the essays his wife writes as a student in a Master of Liberal Arts program. She gets to deploy phrases like erstwhile acolyte — phrases that would never find a place in technical writing. For Tom, the thrill is gone. Worse, he says, in both writing and reading he’s lost the delight of learning new words, playing with the language, and “enjoying the eloquence of an author.”

How do I respond to a brother writer in need?

First, by stating the obvious. Erstwhile Acolytes would be a great name for a rock band.

Second, with understanding. Early in my professional life I dreamed of making my living as a “creative” writer. I — and many of my young colleagues — looked at technical writing as a way to put food on the table until we sold that first novel or screenplay. Now, nearly 40 years later, here I am — still working as a technical writer.

But something happened along the way. I came to understand that all writing — including technical writing; maybe especially technical writing — is creative, because problem solving is a creative process. In our case the problem is how to communicate most effectively with the target audience.

Tom mentions the Simplified Technical English (STE) dictionary. Originally developed for the aerospace industry, it stipulates a set of writing rules and a vocabulary of about 900 words. Erstwhile isn’t one of those words, and neither is acolyte. Yet communicating effectively within the constraints of the dictionary is a creative activity. It’s like solving a puzzle.

(Granted, it’s a puzzle in which I reserve the right to change the rules. If I know that the precisely right word happens to be outside the 900-word canon, then dammit I’m going to use that word. Audience trumps guidelines every time.)

So, yes, I don’t get to write erstwhile acolyte in the Installation Manual for E4G Routers. But I get the satisfaction of knowing that I’ve met my audience’s needs. And I’ll shelve erstwhile acolyte until I’m writing for an audience it resonates with.

Which brings me to my last point. Vary your writing by finding different audiences. All technical writing and no play makes Johnny a dull boy. This blog, for example, gives me a platform for reaching a different audience — still professional, but more collegial — than I reach in my day job. Here I can write more expressively and have a little more fun.

So, if you want to recapture the joy of using our language, I’ll suggest to you, as I suggested to Tom, that you try writing for different audiences. Try writing essays or poetry. And each time you write, think of it as solving a puzzle: the puzzle of how to communicate effectively with the audience you’re addressing.

Do you ever find yourself losing your delight in our language? What ways have you found to recapture that delight?

Yes, and: Helping you communicate better

When actor Alan Alda signed on to host the PBS show Scientific American Frontiers, in which he talked with scientists about their work, he did what most good interviewers would do. He read up on his subjects and their research, and he prepared a list of questions.

As Alda tells it, the first interviews were dull, dull, dull.

Then he tried a different approach. He did only cursory background reading. He didn’t prepare a list of questions. Instead, he sat down to have a conversation instead of an interview.

In his new book, If I Understood You, Would I Have This Look on My Face?, Alda describes what happened. The scientists, realizing they were talking with an interested layperson, started connecting on a personal level rather than delivering lectures. Alda, able to sense the scientists’ thoughts and feelings in the moment, let the conversation flow naturally and comfortably.

Instead of playing the role of a lecturer to a student, or an interviewee to a reporter, the scientists connected with Alda — and, by extension, with the PBS audience — as people talking with people.

Empathy: the key to communication

Alda’s book bears out a lot of things that technical writers already know. Empathy, he writes, is “the fundamental ingredient without which real communication can’t happen.”

Empathy comes from knowing your audience — whether it’s the person across from you in a coffee shop, an audience in a lecture hall, or a datacenter manager who reads your web page. Empathy comes from knowing who they are, what they’re thinking, and what they’re feeling.

Alda writes, “My guess is that even in writing, respecting the other person’s experiences gives us our best shot at being clear and vivid, and our best shot, if not at being loved, at least at being understood.”

He’s right.

He’s also right when he talks about connecting with an audience: “You make a connection by evoking emotions. A great way to evoke emotions is by telling stories. Stories are most effective when you establish commonality with the listener.”

Alda backs up his experience on Scientific American Frontiers with some impressive scholarship. He talks with an array of experts. (It’s easy to get a meeting when you say, “Hi, I’m Alan Alda and I’d like to chat with you about your work.”) He reports on a number of research projects.

Some of the projects were Alda’s own handiwork. He was and continues to be a guiding force behind the Center for Communicating Science at Stony Brook University. His contributions to the science of interpersonal communication are such that STC (the Society for Technical Communication) named him an Honorary Fellow in 2014.

Inprov: new insights for technical writers

Still, despite all of his scholarship and all of his hard work, Alda’s conclusions come as no surprise to most technical writers. We already know about analyzing the audience, about connecting with readers, and about telling stories.

Where Alda adds real value for me is when brings his life’s work – acting – into the picture. Much of the book describes his experience with improvisation, in which actors create scenes together without a script and without any expectations as to the outcome.

A passage particularly fine

I’ve agreed to give a short speech at the STC Carolina chapter’s 50th anniversary celebration next week. It’s a special occasion, so I want the speech to be good.

Right now the speech is about twice as long as it needs to be. Which means that I’m right on schedule. It’s time for me to stop writing and start crossing things out.

I’m guided by this bit of wisdom from the great lexicographer Samuel Johnson (quoted by James Boswell):

Read over your compositions, and where ever you meet with a passage which you think is particularly fine, strike it out.

Samuel Johnson: not particularly noted for his sense of humor

I think I first encountered this quotation when I was in my twenties — perhaps even in college. That’s a good joke, I thought. That Dr. Johnson was quite the kidder.

He wasn’t kidding. But I wasn’t listening.

By the time I turned 40 I began to see wisdom in the doctor’s prescription. Stay vigilant, I took it to mean, lest your writing become flowery or overly ornamented. I was quick to deride those attributes in other people’s writing. Scoffing, I’d hand down my judgment: it’s overwritten.

Today, however, I’m a believer. Today when I write something cunningly clever, a phrase especially well turned — anything that’s particularly fine — I regard it with suspicion.

I don’t always strike it out, I confess. At least not right away. But l move it aside. Then I go back and see whether the piece is actually stronger with it gone. Almost every time, the piece is stronger.

It’s stronger because now, instead of pleasing me, it aims to please the people who’ll read (or hear) it.

You’re looking to be informed. It’s not my place to impress you.

Perhaps you’re looking to be amused or entertained. I’m more apt to do that if I write for your benefit rather than mine.

So (on a good day at least) I’ll furl my flowery phrases and instead deploy language that’s clear and direct. I’ll stop putting on a show and I’ll put you in the center of the story.

Many of us writers fell in love in our formative years with creative writing. It’s taken most of my life to understand that solving a puzzle — the puzzle of communicating effectively with my readers while keeping them engaged — is no less creative than making my prose dance on the head of a pin.

It’s no less creative, it’s no less fun, and it’s a lot more considerate of you, my audience.

(Update: Remember the speech I was writing? Here’s how it came out.)

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.

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.