Editing is arguably the most important process of technical authoring, and the one that takes up most of our time.
I’m a technical author, and I find editing quite challenging when we have several projects on the go at the same time.
Every company has their own branding guidelines; some also have special terms or acronyms that they use. Often, the rules and preferences for the editing process overlap from client to client, and we need to know everyone is getting what they asked for.
The Editing Process
When we edit a technical document, we might simply correct a procedure or document a new feature. The edit may coincide with a new release of the software, so we might just tweak a few screenshots.
- Alterations to the structure of documents
- Changes to product specifications
- Branding changes
- New fields in forms
- New annotations for images
- Language changes (such as British English to American English)
- Changes to file naming conventions
- Altering version numbers
- Amended contact details
- New document layouts
Technical authors work with different output formats: PDF, Word, web, eBook and so on. Each of these formats will have its own layout and conventions. In addition, clients request bespoke formats for different products or service types, and they may change all of these layouts for new releases. So: multiply the list above by two, three or four in some cases.
Editing isn’t just about technical instructions: it’s a very complicated affair. So how do you manage this if you’re flipping between multiple manuals?
A Style is Born
When we quote a fixed cost for a user guide, or bill for user guide maintenance, we factor in the time needed to understand all of the styles and conventions that we’ll need. Why?
- User guides work best when they are consistent, so that the information becomes more important than the presentation
- Practically every design decision applied in that user guide will have a reason behind it, even if the reason has never been recorded. Your technical writer needs to know about each decision made in the past, and needs to document their decision in the future. Why do you italicize notes? Why are some sections of text formatted in bold? There will always be an explanation. Our job is to document that and stick to it.
- Your user guide is often the first thing customers turn to when they have a problem. It needs to represent your brand accurately, and should match your current marketing material to a tee.
- Teams of technical authors need to work together, so a style guide cements their common understanding of the rules. Without that guide document, different writers inevitably apply their own personal interpretation of a convention, resulting in a mismatch, and that slows down the writing and editing process.
- Once you have a common style guide for technical documentation, technical writers can focus on the content without repeatedly tweaking the document’s design.
What You’ll Get
When we complete your user guide, or finish a round of revisions, we’ll provide you with your style guide on request. Equally, when starting a project, we ask that you give us any existing branding requirements or style guide documents so that we can develop them alongside your documentation.
The end result is a beautiful branded document that is consistent across formats, yet is usable in every format we create – now and in the future.
And if you employ us on a retainer, we will continually maintain and update your style guide, making it accessible to your staff in the cloud. We’ll always be working from the latest version, with style decisions created by you but maintained by our technical authors.
If your documentation is lacking a style guide, or you need some help updating the one you have, we’d be pleased to assist. Contact us today.
Latest posts by (see all)
- Outsourcing Your Blog to the Perfect Writer: Part 1 - February 23, 2017
- Fight Brexit: Become an e-Resident of Estonia - June 30, 2016
- How to Sprout a Series of Blogs From Just One Idea - May 9, 2016