A (Re)Fresh Perspective on Practicing Technical Communication

An Interview with Leah Guren

Before I sat down to talk to Leah Guren, I knew her name and reputation because of her history and recognition in the technical communication industry and with the Society for Technical Communication (STC). I thought she was a pioneer in technical communication, having started in the field in 1980 at a software company. However, Guren stated that the profession is actually more than a hundred years old, and had foundations in academia in the 1970s.

Like many of us, she stepped into documentation while working and completing a degree in a different area. She continued working in technical publications for other companies until she moved to Israel. There, Guren started working in training and eventually opened her own consulting, public speaking and coaching company, Cow TC . Knowing of her numerous speaking engagements and consulting work in other countries, I asked Guren what she does with all that airtime and if she had any advice for working travelers. She said that even 28 hours of travel time isn’t worth pulling out the laptop and fighting drink trays to get work done; maybe work mid-flight is only for business-class flyers. So, technical communicators, you are now free to catch up on movies and reading for more productive traveling.

The Scope of Technical Communication

Guren spoke of how broad the technical communication field is, stating that the biggest challenge to the industry is “the amount of stuff you’re expected to know and the changes in the field that you’re expected to handle.” She said it was hard to define the profession, so we have people with the same title doing very different things.

We spoke about technical communication and the role of academia at length. Guren reflected upon the biggest growth being from high-tech/technology fields and the impact this has had. She feels that the theory gets lost in the technology and in academia’s clinging to a traditional English education. Unfortunately, many programs still push traditional English over technical communication. Often, this leads to professionals with an English degree/background who have to unlearn preconceived notions and constructs, then relearn the basics of being effective writers of technical communication. That is why much of her teaching has been on theory and the basics.

Her current perspective also stems from early in her career, when Guren felt the need to get some technical communication training while on the job. She found relatively few academic departments and they offered little, so she relied on available individual courses and seminars, investing time and money in training and a personal resource library. Eventually, Guren started developing her own methodologies based on accepted practice and theory, and personal experience on the job. Guren’s “Golden Rules” of technical communication became integral to the Tech Comm 101 and Tech Comm 201 online STC certification courses she teaches.

According to Guren, even one brief stint in a technical communication course can assist the traditionalist in learning how to effectively apply their natural well-spoken and florid language into concise and clear, user-centered documentation. She said our readers “don’t read documentation, they use documentation.” Writing prose is not the same as writing technical documentation; the profession benefits from a general English education as medical training would benefit a dentist or even an oncologist—the same academic topic but very different fields and applied knowledge. Guren said she has seen, over and over, that many lack the fundamental theory, which is far more important than any given software tool and “never changes. It never goes away. It doesn’t matter what you’re documenting. It doesn’t matter what tools you’re using. It doesn’t matter what industry you’re in, or what domain you’re in. The theory and the thought process that you have to go through, and the questions that you have to ask, and the preparation you have to do is the same… that process is fundamentally the same… if I can teach that, I’ve given people tools that can last their entire career.”

Usability in Technical Communication

Guren got into usability testing first as a consumer, taking workshops with industry greats like Jakob Nielson. One day, a client began requesting usability data on bidirectional, bilingual (BDBL) documentation, and there was no data available. To fill the gap, she started doing her own usability testing based on prior training, and had the work published at a the Tekom conference in Germany. This led to a focus on the impact of language and culture on usability.

While she contends that globalization is harder than localization because of the lack of focus for a target culture, Guren also says her approach is essentially the same for the two. “You want to follow the same best practices as far as writing controlled English, creating a lexicon…  all of the stuff that you do is going to benefit both… the process is pretty much the same.” She also spoke to globalization’s state of flux, as evidenced by the increased demand for localized versions in the European Union. To that end, more of her students in Europe are prepared to go local, know more languages and think about how the language of the documentation may be received in other cultures, particularly compared to American authors. She suggested technical communicators add The Global English Style Guide: Writing Clear, Translatable Documentation for a Global Market by John R. Kohl to their library, as well as The Design of Everyday Things by Donald A. Norman. Her bonus tip was to encourage technical communicators to start a wish list or registry on Amazon of these and other books they would want for their own reference library, and to direct people to that list for gift suggestions.

Guren believes that usability testing is an ethical responsibility. This means technical communicators must clearly identify the users and give them what they need, beyond just documenting how products work. She reminisced about a contract to design the interface and documentation for a piece of software that would, essentially, be used by one data-entry person. Not until she went to install the new system did she find that the one user was physically challenged and would not be able to efficiently or easily use the fancy hot keys they had designed without some immediate changes to the programming.

Professional Titles and Approaches in Technical Communication

Guren doesn’t like using the term Technical Writer to describe what we do in the industry, because on any given day we are doing so much more. “I think the term didn’t even do us justice 20 years ago…  now I really question why anyone would consider themselves a tech writer.  80 percent of what you’re doing is not writing—you’re communicating, you’re thinking, you’re analyzing, you’re strategizing, you’re doing graphics, preparing for localization, you’re sitting in meetings, you’re playing with the GUI, etc. When we say technical writer, we’re picking the most old-fashioned name with the most limited scope for the job that will get you the least respect and the least money.” She quoted Saul Carliner as saying, “Pick the job title that’s going to get you the most money.”

Guren encourages technical communicators to use that title, or something like user experience specialist, documentation specialist, etc. Technical writer is often mistaken for programmer by others. She wants to see those in the profession think of ourselves with more respect and start seeing the grandeur and scope of the profession—what we offer our companies and the value we provide.

Guren has noted no negative impacts from being a woman in the profession. Instead, she finds that personality is far more of a factor in success in technical communication. “The truth is, you cannot do this job if you’re an introvert. You’ll kind of muddle along, but you’ll never really thrive. This profession requires you to aggressively hunt down and acquire information. No one’s going to hand you everything you need on a silver tray. We have to be really proactive, and run out there, and chase people down.”

She contends that it’s important to realize you aren’t being “offensively assertive” in obtaining information—you’re doing your job. You have to learn to ask the right questions, not the ones you can look up yourself or that you should know, but the ones that maybe raise red flags on what no one else has thought of. Guren said professionals should know and speak up about issues such as a “huge logical disconnect when I look at who the audience is, who these users are, how they’re using your product, where they’re using your product; a video training presentation isn’t going to help them if they’re using the product away from a computer.” While it isn’t necessarily comfortable, she said that such a conversation can inevitably save a company or client a significant amount of money.

Sometimes for technical communicators, editing isn’t finding grammar errors. As Guren put it, “Instead of spending two hours or two days, or however long editing a document, it’s a question of analyzing what is this information for, who needs it, how do they need it, what’s the situation. And it turns out you do not need a 12-page document, you need a sticker, a label that’s going to go over a lever on the front panel of a machine. That’s our job; that’s the analytical stuff I’m talking about—being able to collect information, analyze it and be incredibly logical; be really tough; ask all those right questions and realize that part of your job is being a translator and filterer of information; being able to say this is the wrong information—that’s the challenge.”

And because so many people fall into the profession of technical communication, the basics are even more important. Technical communicators need the basics and need to be able to share those basics with coworkers using the proper vocabulary to explain the rationale, the research behind an edit, or the usability implications. Keep in mind that technical communicators preparing user assistance are providing documentation that serves as a contract with the user and should be handled professionally and ethically.

Need a refresher? Check Leah Guren out at the STC Summit or online for STC certification courses.


Kell

13 years ago

Julie, its great to hear how broad the field has become, and as technical writers, we can bridge those gaps by simply practising our trade! Here is an article that I found really help me scale the learning curve:

http://requirements.seilevel.com/blog/2012/03/for-beginning-business-analysts-software-requirements-and-data-dictionaries.html

Lauren Hart

Lauren Hart

13 years ago

Julie,

This is a great article. I really enjoyed her lectures at WritersUA. Leah Guren gives a lot of good advice here, especially about using the best job title for us. I agree that “Technical Writer” doesn’t even come close to describing what we do everyday. Also, The Design of Everyday Things is a fabulous book! I’m putting the other one on my amazon wish list right now!

Subscribe to TechWhirl via Email