In the Lion King, Musafa's ghost told his son Simba to remember who he was. There's something that we tech writers, or we writers in general, can take that from that. We need to remember who we are and why we are doing what we are doing.
Whether we want to admit it or not, as writers, we are doing what we do for the audience. Even if we are writing in our dairies (and yes, there are people who still write dairies, even blogs are diaries in of themselves, except they are in cyberspace), you are still writing for an audience.
Whether you are writing for one or one million, the end goal of writing is to communicate a message to the audience. With that in mind, we must tailor that message to them.
Understand Your Audience
This is key in writing a document. I can't stress how important it is to know your audience. This should be the first step before you type a character on the screen.
So why is this important? The obvious answer is for every document there is an audience. Why write anything to anyone if you don't understand who they are?
For example, you're not going to write a whitepaper for an electrical engineer audience to educate them on circuits, currents, transistors, or diodes. Since they know about electronics, you wouldn't waste your time--or theirs--defining these components. You should focus your attention on how to have electrical currents run through circuits better and with less power. Or maybe, you would show them how to create certain schematics for a chip.
Another example would be if you're creating a user guide on how to run an air conditioner written to the general audience, you're not going explain the nuts, bolts, materials, and components that were used to create the air conditioner. You're just going explain how to use it. You may also have surface technical specifications in the guide, like the amount of BTUs the air conditioner uses, but nothing beyond that.
So before you write a document, know who you're writing for. Otherwise, the information in the document is worthless.
If you don't know who the audience is, then ask an SME or do some research yourself. Any SME worth their salt should be able to help you with this.
In any case, it's important to gauge your audience, so you know how much or how little information you need to communicate, as well as the type of information.
Listen to Your Audience
The second part of understanding your audience is to listen to them. If your audience is confused by certain portions of the document, there are missing steps, or the information is not as accurate as it should be, you need to take the feedback and improve it. In some ways, documentation is like software; it's fluid and it has bugs. Documentation gets better, like software (or at least should), if you listen to the complaints as well as the complements. Otherwise, the documentation is useless to the audience and they will find someone else who can meet their needs. So listen up!
Build a relationship with Your Audience
The third part of understanding your audience is to build a relationship with them. This is very similar to listening to your audience, except it's taking it to the next step. If you can, try to keep an open dialogue with them. See what works for them, what doesn't, and why. Have your audience complete surveys or even participate in usability tests on your documents. This can be useful to see if they can try find trouble spots as they're going through the document.
If you're able to do this, your audience will put more trust in your abilities. And you will be able to provide the audience the documentation they need. As a result, it's an ongoing, constantly-evolving relationship. It's a win-win situation.
Servant's role
Remember, documentation isn't about you. It's about them. A technical writer is really a servant's role. If you prefer to being in charge, then pursue project management instead. If you choose that path, then I wish you well on that journey. But writing, especially technical writing, revolves around how to best serve the audience you're writing for.
The third part of understanding your audience is to build a relationship with them. This is very similar to listening to your audience, except it's taking it to the next step. If you can, try to keep an open dialogue with them. See what works for them, what doesn't, and why. Have your audience complete surveys or even participate in usability tests on your documents. This can be useful to see if they can try find trouble spots as they're going through the document.
If you're able to do this, your audience will put more trust in your abilities. And you will be able to provide the audience the documentation they need. As a result, it's an ongoing, constantly-evolving relationship. It's a win-win situation.
Servant's role
Remember, documentation isn't about you. It's about them. A technical writer is really a servant's role. If you prefer to being in charge, then pursue project management instead. If you choose that path, then I wish you well on that journey. But writing, especially technical writing, revolves around how to best serve the audience you're writing for.