Currently based in Ohio, but frequently travel and work remotely or temporarily relocate to be near a client's site. Also see this.
An independent technical writer is typically one who is highly competent and is confident enough in his/her abilities to not require the security of company benefits and a regular paycheck. You can have this experience and competency working for you at less than the cost of an in-house writer—while not being committed to providing a steady 40 hours of work per week.
You don't need to provide me space to work or equipment and software licenses.
You are not responsible for my social security, medical insurance, workers compensation, sick leave, holiday pay, or vacation pay.
When you don't need me for a while, it's not a big deal. I will enjoy the time off.
I use e-mail (pdfs), cloud storage, or FedEx to get your product to you.
I can conduct information-gathering interviews remotely.
If I need to see it, run it, take it apart, or install it, I will happily come to your site.
Working off-site, my productivity is greater because:
I can enjoy long periods of focused concentration without interruption
I'm not affected by distracting office noise, personnel, and politics
I work during times of peak productivity, which may not always be 8-5
Instead of commuting I can be working
I work through holidays when necessary
Comprehension should be a writer's aim—first and foremost. Technical writing that is unclear or difficult or impossible to comprehend is worse than useless because it:
wastes the time of people on the job (and one technician's delay could have a huge ripple effect)
creates a negative impression of the company behind the product
fails to achieve the goal of decreased equipment downtime
results in calls to the service department
may result in equipment damage or injury to persons
How many times have you encountered a description of a process or procedure that, even after numerous close readings, you failed to comprehend the writing? Lack of clarity is often the reason, followed by the writer's own lack of understanding of the subject matter.
To achieve clarity in my writing, I use the following techniques. These can also be thought of as "self-editing" checks on one's writing, and will help ensure cohesion and coherence as well as clarity.
My Top 6 Essential Technical Writing Techniques for Achieving Clarity
- maintain a topical focus
- use transition words
- use "old-new information" sentence structuring
- use varied sentence lengths and short paragraphs
- use parallel construction
- eliminate wordiness
Here is the interesting thing about these techniques—they act as a test of the writer's own understanding of the subject! Gaps that may exist in a writer's own comprehension of the subject matter will most likely be revealed to the writer when these techniques are employed.
[future example here] (preliminary manual version)
I have experience providing many different types of graphics. The type of graphics used will depend on the specific situation, resources available, and client preference.
Photographs are the most efficient method to illustrate a process or procedure, and experience is helpful in getting shots that are clear depictions of what you are trying to illustrate. And once you have a decent shot, there are some simple steps that can be done using Photoshop to greatly enhance a photograph and make it worthy of inclusion in a quality document.
I always ask the question, "What graphical enhancements can help communicate this information?" Often, redesigning the text is all that is required, such as simply breaking a long paragraph into shorter ones or using a "Note" or "Important!" paragraph style. And of course, [future example here] a well-designed table or graph can greatly enhance user comprehension and access.
Other situations might require an infographic such as a piping and instrumentation-type drawing (PID), a data/control flow diagram [example 1] [example 2] or schematic diagram [example1] [example 2] to provide a quick visual overview of how a complex system is arranged and interconnected.
Creating a PID requires that the technical writer be a competent reader of schematics and able to comprehend and visualize large complex systems. A skillful technical writer can create a PID that is accurate and informative while not being confusing or cluttered by unnecessary elements.
I have enjoyed working with many professional technical illustrators and I greatly appreciate their talents when they are available to me, but more typically I create my own graphics.
The example is a procedure for removing a roll from a paper making machine. The drawings are to-scale, derived from drawings done on a drafting table. The facility had not yet been built.
Removed extraneous detail, drew in components relevant to the procedure, added callouts.
The task was to create a graphic that conveys the instruction "Empty every day." Also see these wordless instructions.
In the above example, the original version was all one line weight with no shaded areas. It was impossible to see differentiate the structures. Working with the illustrator, I requested shading for some areas, some heavier line weights, greyed-out background lines, and removal of extraneous background detail.
It is important for the technical writer to evaluate existing graphics for how well they function in communicating the intended concept or structure.
Computer screenshots ((future example here)
The first example is . . .
All too often, software screenshots are plunked down onto a page with little thought, i.e. with no explanatory call-outs or tie-in to the text, are inappropriately sized, or are illegible due to low resolution.
Original PIDs and schematics (See Information Design above)
The graph packs in a great deal of information. It was an interesting information design challenge.
The table originally was simply lines and data with no formatting to assist the reader—no shading, no space between rows, and no merged cells. The new table exemplifies how an information design perspective can lead to a usability improvement.
The table is also an example of the danger of never reviewing your boilerplate!
A check of the part number drawings revealed many parts were no longer available or were superseded. Furthermore, numerous dimensions given in the table were found to have been incorrect as well.
With a pretty good eye for design, typography, and page layout—these being the focus of my Master degree studies—I have designed manuals and other kinds of publications for many clients and employers. Elements on a page or digital display must be legible and arranged in a way that helps make the information accessible. Essential considerations include:
client preference or an existing corporate style
balanced page elements
text and graphics that are sized appropriately
informative text headings and graphic callouts
eliminate any distracting elements
adequate headers, footers, TOCs
good indexing strategy
clean templates with minimal complexity
minimal paragraph and type styles
Adobe Framemaker—what do you mean when you say you are an expert user?
By "expert user" I mean that the Frame documents I create are built on elegant, streamlined templates of paragraph and character styles, page and step numbering, running headers and footers, index tagging, tables of contents, hyperlinks, etc.—without excessive complexity.
Since version 3 in 1993, Framemaker has been my DTP tool of choice, although I am equally impressed with InDesign.
What about Word?
Many people don't know this, but Word can be made to develop a large multi-section document. It has a book-creation capability that links chapter files. However, while I will use Word if that is a client requirement, I do not recommend it for technical publications.
Although Word has many of the capabilities of a DTP tool, it is essentially a word processor that has been pressed into service as a DTP tool. Word performs very poorly as a desktop publishing platform. It is unstable. Much of a writer's time is spent maintaining the formatting and keeping everything from blowing up. Yes, everyone is familiar with Word, but creating a simple Word document is much different compared to creating a multi-section technical manual based on a complex Word template.
- Nearly eight years as sole writer managing the preparation, production, distribution, and continual updating of all manuals for a manufacturer's entire product line (NMC-Wollard and Voith).
- Many years experience developing proposals, documentation plans, schedules, and providing frequent project-status reports (these are typically monthly, otherwise on any schedule a client wishes).
- I practice "continuous improvement." This includes continual pro-active maintenance of documentation with respect to keeping up with engineering changes and making continuous usability improvements. I am always happy to revisit a publication—a "finished" manual is never a "forgotten" manual. And it is never a bad idea to periodically review existing manual text for accuracy and usability!
- I always keep a project in a state of organization such that were I was unexpectedly unable to continue the project, another writer could step in and have no trouble determining what's what. There are numerous techniques to accomplish this. Two simple ones are 1) using sub-directories with informative names, and 2) keeping the main project directory clear of unnecessary files. Within a document, any text that is yet to be verified is colored red.
A short answer to the question is that this work simply comes natural to me. And I enjoy it. Add the fact that every hour on the job is an hour of solid work.
A more detailed answer is that I can both be super-productive and deliver a high-quality product because I . . .
- truly enjoy the actual tasks of illustrating and desktop publishing
- can understand large complex systems
- have a solid work ethic
- have a high comfort level with writing
- have a strong sense of curiosity
- have a strong interest in science and technology
- have a logical and analytical mind and I use it
- can think "outside-the-box"
- have an ability to see from the reading audiences' perspective
- enjoy multitasking and working at a fast pace
- can create graphics that are clear and convey information effectively
- enjoy DIY, hands-on work with tools
- enjoy maintaining focus on complex problems for long periods
- get to work in places and with people and machines that I find personally interesting
Typically I will blast through a client's projects in less than the estimated time while taking on numerous additional fix-it tasks and raising the bar on the documentation they've been used to getting from their in-house writers.
My primary tools of choice are Framemaker, InDesign, Acrobat, Illustrator and most other illustrating programs, and Photoshop.
Also see the note above on using Word.
I have worked with many different illustrating and graphics tools and am flexible with respect to the tools a client wishes to be used. If the tool is new to me, I quickly come up to speed—on my own dime.
1) I keep my overhead low, and
2) my focus is on productivity, quality, and getting the job done, not on how long I can extend a project.
My hourly rate is likely below the cost of a full-time employee and less than what a job shop would charge for an experienced technical writer.
The big advantage to you is that my productivity is much greater that of the typical experienced technical writer—while delivering a higher-quality product.
Typically I invoice by the hour, and will provide an estimate if the client desires. For well-defined projects I would consider a fixed-price project.
Travel is the only expense for which I have ever requested reimbursement.
Occasional driving to a client site I consider a cost of doing business.
For overnight and air travel I would submit to the client an accounting of expenses incurred.
Existing publication—editing and/or updating only
The usual first step is a site visit, but I have provided quotes when all communication has been by mail, email, and phone.
We would discuss:
the original documentation
the specific desires you have for the documentation
the extent of new source material available, such as engineering notes, drawings, or other product or process information.
the availability of subject matter experts and their commitment to the documentation effortQuote turn-around time: typically 24-48 hours
A site visit is typically a necessity, but I have also provided quotes for new documentation when all communication has been by mail, email, and phone.
We would discuss:
the extent of documentation which exists for similar products or processes, if any
your challenges with respect to documentation requirements
the specific desires the client has for the documentation
the extent of source material available, such as engineering notes, drawings, or other product or process information.
the availability of subject matter experts and their commitment to the documentation effort
Typically a preliminary table of contents is delivered along with my quote.
Quote turn-around time: typically 48-72 hours
If we decide to move forward on a project, I would prepare a very simple "Work Agreement" that basically reiterates the parameters of the project, identifies the project lead on the client side, indicates my hourly rate or the agreed-upon fixed price and invoice scheduling, and so forth. If requested, I can provide an example Agreement with my quote.
In addition to my Agreement, sometimes the client will have their own standard contract for independent contractors.
My signing of the client's Confidentiality Agreement is of course standard procedure.
I am flexible as to work locations. I am used to relocating, which I can do quickly and easily with no expense to the client.
I have a valid passport and am a willing and experienced traveler.