As the tech world evolves, we learn as we go and we share what we learn with our peers. But at what point do we become experts in our field? And is expertise in a subject enough to make what we write become technical documentation? The Expertise Paradox: the more you know...
Whether you realize it or not, you come into contact with technical writing on a near-daily basis, whether it’s by reading a manual, following a course, or troubleshooting an issue online. However, when looking for a quick fix to our issue, we don’t always go for official product documentation. Instead, it’s often quicker to look for troubleshooting blogposts or tutorial videos.
It’s worth keeping in mind that having experience with a subject or forming an opinion about it, does not make us all true experts and it does not make our content technical documentation. So what sets these things apart from what we do as a business?
Learn it
Technical documentation requires two pools of expertise, the first of which is the product itself: You need a subject matter expert. As a writer, you can (and should) immerse yourself in all aspects of the product. After all, you need to understand it in order to be able to explain it.
If we want expertise, you may ask yourself: Why leave writing manuals to a tech writer who is a bit of an outsider? Why not let designers or engineers do the writing themselves? Because the outside perspective is a benefit. It allows you to ask the type of questions an end user would ask.
Often, subject matter experts do not include information because it seems too obvious to write down. They assume all users know as much as they do. Compare it to asking a native speaker about grammar. They’ll know a mistake when they hear it but often can’t explain exactly why something is wrong.
Write it
The second pool of knowledge is tech writing itself. There is a whole range of software packages and workflows out there to familiarize yourself with. Luckily, you can draw on expertise of fellow writers and join conferences where you’ll hear all about the latest developments, like automation and AI.
Does that sound like a lot? It certainly can be! But in the end, you don’t have to use everything available. It’s all about finding the writing strategy that best suits you and your end user. Once you have a system that works, you can keep improving it.
Teach it
A tech writer’s end goal should always be educating the user. Content is communication, after all. So on some level, tech writers have to become educators. And as is the case in any classroom, if the students don’t grasp the information, teachers need to change their approach.
Each type of tech content requires its own writing style. By design, manuals are technical – and, lets be honest, not the most riveting read. While it serves its purpose, that style does not work everywhere. As educators, we need to change our approach if we want to keep users engaged during a PowerPoint presentation or e-learning course. We need to understand the purpose of each tech writing medium and rephrase our message where necessary in order to most efficiently reach the user.
Curiouser and curiouser
If you’re reading this blog then, like us, you probably have a curious mind. We’re continuously looking to improve our skills and become masters in our craft. This means learning and adapting to an ever-evolving field and product. It means developing expertise, professional judgment, and best practices, grown from experience and interaction with fellow experts.
This also means looking critically at what we know and how we write. Just knowing the ins and outs of a product is not enough to produce the technical content users need to support them in their tasks. Yes, we need to know the product, but we also need to understand the craft of technical writing and the needs of our users.
Because the more we know, the more we realize how much there is left to learn.