Back to Square One

It’s funny how the business cycle works. I’ve been working in the same office for five years, but thanks to acquisitions I’ve had four employers in that time, with the most recent change August 1. (Believe me, I’m not complaining!) For the purpose of this discussion it doesn’t matter what company it is; given its size and logo, let’s call it Big Red.

As technical writers, our value proposition is making the complex clear and explaining technical things to people. We aren’t subject-matter experts, but we know how to collect enough information, and present it effectively to let our audience use the technology to accomplish their goals. Rule One of user-interface design is to know the user, for the user is not you. It’s a key skill for us too: putting ourselves in the audience’s place and understanding what they already know, what they need to know, and how they approach the task.

Having more or less mastered the tools, technology, policies, and procedures of my previous employer, let me tell you that it’s a big shock going to the equivalents used at Big Red! To paraphrase Steve Martin, it’s like they have a different word for everything. All of us are back to square one, reset at a stroke from experts to new users. And we’re the worst kind of new users: we know how to do things, but not in the same way. Some of the most accomplished among us are now floundering the worst. I’m finding it a humbling experience, but valuable, too, because it’s a refresher course in how a new user feels, thinks, and approaches tasks.

What’s it like being a new user at Big Red? Because the company is so large and brings in so many people at once through hiring, mergers, and acquisitions, individual handholding is impractical; we are expected to rely on the technical and procedural documentation. (Hey, this is what we expect our audience to do.) And the environment is stressful, not through malice but simply because accomplishing certain tasks is now a job requirement or directly affects our lives. If I don’t complete this task I will lose my job; if I can’t accomplish that task I can’t log in; if I don’t do the other task my family will lose healthcare coverage. Mind you, it’s not as if we’re left without instructions. There’s actually plenty of information available. But it’s overwhelming. Today I followed a procedure that told me how to complete a procedure! A company with 1000 employees can grow a website with 25 links on the home page of its intranet, but a company with 100,000 employees can grow a website with 100. They can’t all stand out. Where is the one I need?

To make matters worse, in some cases, due to the sheer size of Big Red, I observe that Organization A refers to something on the Organization B website that has changed. We say we know the value of consistency and accuracy, but we sometimes get lazy about QA and don’t verify everything. When we’re writing and we spot a small inconsistency, it’s easy to convince ourselves that it doesn’t matter, because it’s obvious what to do. But in our current situation, we’re in no mood to be adventurous. If a procedure says to click the link that says X Y Z link, but all I can find is a link that says X Y Q, I’m not sure whether it’s the correct link or even if I’m on the right page. Have I really installed the XYZ collaboration suite if the desktop icon says XYZW? And if email directions specify a link that’s not there at all, which one is the closest match? I’m being forcibly reminded that when the stakes are high, tolerance for error and ambiguity is low.

As I said, we aren’t lacking for written procedures. Those procedures often contain plentiful step-by-step screenshots. Now, some on the creation side argue that screenshots are unnecessary because the user is already on the screen. And screenshots can be a pain to include. But such arguments miss the point. Screenshots can be vital user aids to consumers. These days I’m not sure where I’m going, and I’m finding anew that “you are here” screenshots reassure you that you’re on track.

When you start a procedure, how long will it take? Is it supposed to be that slow, or has the process hung? Engineering and product management hate to commit to performance figures, but it’s helpful to know, for example, that processing an email folder will take about twenty minutes per gigabyte.

And how do you recover if you do get off track? As technical communicators, we can easily fall into the bad habit of only taking our audience along the success path without considering troubleshooting. Let me tell you, even the simplest troubleshooting information can be as valuable as the procedure itself! Another useful aid is a “do not” admonishment, such as “do not click [similar-sounding link]; that is a different function.” Describing how to recognize and correct the top two or three possible errors in a procedure, even things you regard as obvious mistakes, will make the procedure more effective and increase customer satisfaction enormously.

Even something as simple as giving the end state of a procedure can be both helpful and reassuring. When I signed us up for healthcare benefits, I painstakingly followed the directions, but nothing happened. There was no message saying I was all set, no email confirmation of enrollment, and no medical cards in the postal mail. Our prescriptions began to run out. I worried that I’d missed some vital step. After a week I both emailed and telephoned the benefits office. That triggered one reply for each inquiry, and it turns out I had completed the procedure correctly. I can breathe easier (literally). But one extra statement in the procedure would have saved me misplaced anxiety and the benefits office two customer interactions. Multiply that by the number of new employees who have the same concern I did, and that extra statement seems like even more of a good idea!

So, what’s my closing statement? Know the user, for the user is not you. Don’t get jaded and assume everything is obvious. Don’t assume your audience is expert or won’t make mistakes. Attend to the details. Don’t ignore the value of screenshots. Include prerequisites at the beginning, troubleshooting tips in the middle, and closure at the end. Your readers will more often be successful, and grateful too!

[Updated 2/28/13]

Published by Steven Jong

I am a retired technical communicator, a Fellow of the Society for Technical Communication (STC), a former STC board member, and chair of the first STC Certification Commission. I occasionally blog about these and other topics.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: