Technical writers are professional communicators. It’s their job to figure out what should be communicated to your audience and how. The audience could be your customers, clients, users, or staff. The final product could be a procedure, manual, website, or training video script. If you want to round out your team with a technical writer, understanding what a writer can and cannot do for your organization can help align expectations and reduce the chance of buyer’s remorse.
(Although they may desperately want to), don't ask a tech writer to
Fix a broken process. Capturing a process in writing (or other media) doesn’t necessarily make it a good process. The act of documenting, though, will often point to holes in the process, identifying areas for improvement.
Let’s say a critical step in the receiving procedure is to compare shipping documents with the items received. Basic stuff. The writer will be sure to include that step since it’s been identified as an important one.
Except--as the writer goes through the motions to test the steps--they realize the shipping documents are not in the box. They are only sent to a generic email that not all receiving staff have access to, especially those on third shift. This means staff can’t always follow the procedure because there’s a flaw in the process that sometimes prevents the step from being executed.
The writer can document the step all day, but they can’t change the fact that the step cannot always be performed as written. The process designer has to correct this.
Be a subject matter expert. And you don’t want them to be. “Fresh eyes” are valuable to any project. Yes, a writer needs to become familiar enough with the content to write about it with some accuracy and authority. But a writer will not be the expert; that’s where the SME comes in.
Yes, some SMEs write. But a technical SME often overlooks what terms and directions an audience of new users might require to make sense of the content. Audiences often struggle to understand procedures written by someone so deep in the technical weeds. A writer lives with one eye on the needs of the audience and one on the project requirements.
If you want your SME to write, consider asking a tech writer to review the work. Otherwise, let the writer write and let the SME SME.
Learn by osmosis. A writer needs access to SMEs, beta versions, source documentation, etc. They will also test out the documentation against the product when appropriate. Ultimately, clear and accurate documentation greatly depends on your willingness to answer questions, to provide access to application/equipment/source information, and to participate in meaningful document reviews. A question from a writer doesn’t mean they are not grasping the content; it’s usually the opposite: they’re working to gain a deeper understanding that will benefit the project as a whole.
Okay, so what CAN a technical writer do?
Make the lives of your audience better. Maybe that’s a borderline oversell, but think about the last time you assembled a piece of furniture with poor or non-existent instructions. Not only was it frustrating, but you ran the risk of doing it wrong and creating a safety hazard. (Wobbly bookshelf, anyone?)
A writer breaks down often complex information, reorganizes it, and then presents it in a way that’s understandable and usable. The audience doesn’t have to wade through technical jargon to move forward, and they don’t have to figure it out on their own. The documentation guides them.
Who is the audience, by the way, and what do they need? Is it someone new to the organization or only new to the application? Is it a potential customer seeking information about your product? Is a full manual needed? What about a one-page explainer? Should it be accessible from a SharePoint site or public portal? Based on these answers, the writer can make decisions and recommendations on how best to present the information and at the appropriate level of detail.
If all of this is done correctly, your readers/users/potential customers will be equipped with the information they require to move forward. And moving forward is the point.
Document your process efficiently. Your organization may need documentation for a variety of reasons. Maybe your industry requires it for auditing purposes. Are you seeking ISO-9000 certification and, therefore, need to establish a set of quality procedures? Do you need a manual to train new staff?
A writer will get those processes down on paper (or in the cloud) so they’re available when needed. They will also consider access and document control concerns so updates can be made easily when your processes change. (And they will change.)
Be a part of the development team. When possible, include a writer in the early phases of a project. They learn the system/program/process along with the team, reducing the lag time of bringing someone up to speed at the end of development. A writer can identify pain points in the process from the audience’s perspective. They can also start planning and drafting documentation specs, which will result in less time on the back end prior to release.
Having a technical writer on your team is an effective way to meet the needs of your audience. Should you decide to bring one on board, let me know if I can help. I know some good ones, including me.
Thanks for reading. See you soon.
Except--as the writer goes through the motions to test the steps--they realize the shipping documents are not in the box. They are only sent to a generic email that not all receiving staff have access to, especially those on third shift. This means staff can’t always follow the procedure because there’s a flaw in the process that sometimes prevents the step from being executed. 
Comments