Best Technical Writers

What a good technical writing project includes

Technical writing gigs are priced by document, page or project. Check that the project states:

• Documents to be written or updated, with a rough outline.
• Audience: end users, administrators, developers or staff.
• Research: product testing and interviews with experts.
• Visuals: screenshots, diagrams and annotated images.
• Format and tool the docs will live in.
• Style: a style guide, or one created for you.
• Review rounds with your experts, and delivery time.

How to brief a technical writer

1. The product or process and who uses it.
2. The problem: the questions users ask most, or the mistakes they make.
3. Existing material: old docs, specs, support tickets and videos.
4. Access to a test account or environment.
5. Experts the writer can talk to, and when.
6. The publishing tool and any templates.
7. Terms: product names and words to use consistently.

Test the finished documents with someone new. Ask them to follow a guide step by step while you watch. Where they hesitate or go wrong, the document needs work, however clear it seemed to you.

Plan for updates. Products change, and outdated documentation causes more confusion than none. Decide who updates the docs with each release, and ask the writer to leave a short note on how the documents are structured.

What drives the price

• number and length of documents
• complexity of the product or subject
• developer documentation and code samples
• screenshots, diagrams and videos
• research and expert interviews
• the writer's experience in your field

Red flags

• Samples that are vague or full of marketing language.
• No request for product access or expert time.
• Documents delivered in a format your team cannot edit.
• Requests for production admin access instead of a test account.
• No review step with your experts before delivery.

For documents in other languages, see our translation guide. For editing existing documentation, our proofreading and editing guide explains the levels of editing. For product and app work, read our software development guide.

Ask the writer to structure the documentation around tasks, not features. Users usually arrive with a goal, such as setting something up or fixing an error, and they want the steps for that goal, not a tour of every button. Task-based articles are easier to search, easier to keep short, and easier to update when one part of the product changes. A simple list of the most common tasks, taken from support tickets, is a good starting point for deciding which documents to write first.

Quick pre-order checklist

• I have defined the documents and their audience.
• The writer will get a test account and time with experts.
• The format and publishing tool are agreed.
• Experts will review before delivery.
• I have a plan for keeping the docs up to date.