Many project managers entertain the idea that technical communicators belong at the end of a project only—that we perform strictly a responsive and reactionary function: to look at what has been created and write about it. To counteract this idea, one of my colleagues and I submitted a proposal for a presentation in an upcoming conference that’s mostly internal. (You may wonder what the point is of an internal conference, but it’s good for breaking down silos at least.) Our presentation topic is how to lower project costs by involving a technical communicator throughout the lifecycle.

To develop some ideas, I’m posting them here. They will largely address software development projects, since software development teams are our audience.

Requirements

If you’re in an Agile shop, you don’t worry about writing a requirements document at the beginning of the project. But if you’re following a waterfall process, those specifications have to be hammered out at the outset. Of course, the program or project manager and business analyst are heavily involved. However, they could benefit from the involvement of a technical communicator to write or at least review and edit the document.

Because the tech writer specializes in clarity of communication, he can ensure through asking the right questions and writing clearly that everyone understands the requirements. This saves time later when the project team has to go back to the requirements to get the official answer to some question. If the answers are clearly stated, then discussion and negotiation are kept to a minimum.

Vocabulary

At the start, the project team, users, and support need a common vocabulary so as to communicate clearly. I’ve discovered that one of the dangers of Agile methodology, if not mitigated by a clear glossary created at the beginning, is that due to contact with the developers, users start picking up their terminology. This can result in overly technical terms being introduced into the interface or in a discrepancy between the words that support agents and customers use. For example, I recently heard a coworker tell a user that “we call that” function a certain thing, when that was the first time I had ever heard that term. I hadn’t used it in the documentation, nor did it appear anywhere in the interface.

In such cases, in order to be clear, the technical communicator has to choose certain terms to use consistently in the documentation, but an inherent inconsistency results because not all users are following that same usage. If the technical communicator is included at the beginning and can set out the terminology then, confusion will be reduced.

Even if there is little risk of technical jargon slipping into the users’ vocabulary, the functions of the product need to be named. Do you use the term delete or remove? Box or frame? Book or folder? Edit or update? If we don’t pick one and use it but instead use different terms interchangeably, users may think they are different functions within the software.

Design

Interaction designers typically aren’t writers, and they’ll readily admit it. But interface text is an important part of the product. Imagine a screen that had absolutely no words on it. How would the user know how to even begin? You’d really need online help or a user guide then. It can be nearly as bad as no text or the wrong language if the UI text isn’t clear.

Much of the user’s interaction with software is generally facilitated—or hindered—by text, so its importance isn’t to be underestimated.

Again, if the technical communicator created a glossary at the beginning of the project, she can help the designer ensure that those terms are used properly and consistently throughout the interface.

Additionally, when the software is designed to give feedback to the user, the technical communicator can make sure that feedback is clear. Our profession lives on the premise that users don’t always understand what the developers understand. If the developers or designers are the ones writing error messages or other feedback text, then they are typically written to help developers understand the error’s cause. But these kinds of messages don’t do users much good. It’s better for the interface to give clear instruction about what to do after an error than for the user to have to go to the help system and hunt for the error’s explanation.

Beyond text, though, is the potential for the technical communicator to wear that familiar user advocate hat and give the designer feedback about the designs themselves. When we’re documenting a product, sometimes we become so familiar with it that we lose that mentality of first-time exposure. During the design or prototyping phase is a perfect time to take on that mentality and contribute to the design. Often, designers may work so hard at perfecting a design and experimenting with multiple approaches that nothing is new for them. The technical communicator is a prime candidate for sitting in that seat. And as I’ve pointed out before, the technical communicator can judge whether the design can be simply documented or will take a complicated series of steps. If the latter is the case, a different design may be in order.

Wrap-up

If a tech writer is walking into the project when it’s nearly complete, the product may be farther away from launch than planned or may be lacking in the quality that users expect. While creating documentation, I have raised questions or found problems that could have been avoided had the project management involved me in those earlier phases of the project. Problems with UI text or inconsistent vocabulary also could have been solved early; instead, to be fixed, other work must be postponed. Projects save time and money when they bring writers into the project early instead of waiting until they consider the product ready to ship.

Related entries (auto-generated):

Teaching Project Management How to Work with Technical Writers

Clear, Common Language Leads to User Success

Getting Involved Early Helps the QA Effort

Establishing the Correct Name of a Project

Tapping into the Resource of Project Documentation