When someone joins us at 3di as a new Technical Author, they might have a strong technical background and some experience of writing. However, the world of technical communication might be new to them. How do we get them started without scaring the living daylights out of them?
Understanding the basics – technical communication
I joined 3di back in 2014, when I arrived with a scientific background – a perfect fit for Roche projects. But I had no previous experience of the technical communication field.
Fortunately, authoring tools and technical communication concepts were introduced to me steadily. I was given time to get my head around a style guide and learn what is meant by single sourcing (hello, dear friend). There was always another thing around the corner that needed explaining, but I soon realised there was a solid foundation being built.
Since I joined, we have further refined our core training for new authors. We now have an induction “blueprint” of modules, which we can use for anyone who joins us. It covers all sorts of things, including documentation standards, understanding audiences, how to structure and design documentation, common content types, and the importance of graphics in what we do.
More recently, we’ve been reviewing our induction plan for new authors, to clarify what new authors should learn when they start at 3di. We’re also working on a learning syllabus for authors; due to the variety of tools and customers 3di works with, it’s not the easiest! But it’s certainly helping us decide what our core skills should be.
Want to find out more?
Into the wild – and onto customer projects
Of course, we can’t expect new authors to jump straight into a customer project without support. At 3di, each technical communication project is led by an experienced Lead Author, and first they have a customer induction with the new author.
The customer induction allows a new author to get familiar with the customer’s products, and the processes and tools we use for that customer. For smaller projects, this could be as simple as a one-hour session. But for larger service projects, it will be spread over several training sessions. And as we record project-specific information in our knowledge base, new authors can quickly look something up when they’re in a quandary.
After the customer induction, it’s time to get down to business. What’s key is selecting the right task for the new author to work on.
Perhaps the customer asks for a prescribed update to the compliance section of a product’s User Guide. Sounds like the perfect job for a new recruit! The new author can make the requested changes to the document, then pass it to the Lead Author to review. The Lead Author reviews the source files together with the published output, to check everything looks alright. This setup gives new authors a chance to start contributing to the projects and team, but in a safe (and most importantly version-controlled) environment.
Want to find out more?
Don’t stumble in the dark
Every customer is different. But we’ve got standard processes for running projects and services. Part of this includes templates and guidelines that allow authors to get on with their day job: creating quality content.
For example, we have standard templates for one of our most common authoring tools, MadCap Flare. We also have guidelines on how to use these templates, which contain information such as what each style is for, and how to insert safety messages. These templates are used as the starting point for new projects using MadCap Flare, allowing the common assets to become familiar to authors – no matter the project they’re working on.
Content models help ensure documentation is well-planned and consistent. They also help authors know what to write when the product changes. For example, when a new feature is added to a product, the author can check what types of topics they should create. They also know what information these topics should contain. This kind of guidance helps authors understand what they are doing, and gives them a framework to work from.
These templates, models, and guidelines help embed best practices and understanding amongst authors. Although here at 3di we often need authors to work on a variety of projects and customers, these make things much easier. To read more, check out George Lewis’s blog post about the three pillars of quality technical content here.
Moving on up
Getting to grips with technical communication and the various customers that we work with is no small task for new starters. But all these steps help standardise training for our authors, and ensure that their training is supported by other team members and the resources they’ve created. With these, it shouldn’t be too long before the new starter will be another expert in the field.