Latest posts by techwriter (see all)
- BOOK REVIEW: “Design for How People Learn” by Julie Dirksen - July 10, 2017
- 12 Top Characteristics of a Good Technical Writer - July 3, 2017
- What Are the Qualities of a Good Technical Writer? - June 28, 2017
© Ugur Akinci
The first few years of a typical technical communication career are great. You’re full of enthusiasm for your well-paying job and happy to generate one user manual after another.
Yet after 5 or 10 years some of us hit a plateau. All of a sudden, the same job is not nearly as much fun.
At that point you might want to extend and expand your career in two different directions:
1) Pre-Writing Extension
Let’s look at the Pre-Writing Extension option…
By “Pre-writing Extension” I mean the time spent in any project thinking about the specs, including marketing, requirements, and design specifications. In screenwriting terms, you could call that “Pre-Production Phase” as well. You can revitalize your career by offering your services in the preparation of specifications.
Yet, anyone who has spent some time in the industry knows that specs are usually written by developers and engineers, and rarely by technical writers. Why? For one thing, most tech writers do not have the kind of technical/engineering background necessary to write the detailed functional specs.
So, what’s the best way for a technical communicator to participate in that process? Answer: preparation of Use Cases.
A Use Case is a scenario of the “typical interaction” between the end-users and the system. By brainstorming about both the “normal” and “alternative” flows of interaction, the tech writer gains a pretty good knowledge of what the main functions of the system are, what the main “operational procedures” are going to be, and what the troubleshooting section of the manual should look like.
The marketing and sales departments of most companies do not allow technical communicators directly get in touch with the customers and end-users. But if you could arrange such authorized contacts, you could interview the prospective and/or current customers and learn a lot about such Use Case scenarios. That kind of information would be invaluable for a product manager as well. And once you have that kind information under your belt, you would be a more valuable member of the project team since your documentation would reflect the real concerns out there.
Also see: Post-Writing Extension
Use Cases Resources
Writing Effective Use Cases
Use Case Driven Object Modeling with UMLTheory and Practice
Use Cases: Requirements in Context (2nd Edition)
Applying Use Cases: A Practical Guide (2nd Edition)
Succeeding with Use Cases: Working Smart to Deliver Quality