I've been doing technical writing of one sort or another since 1999, when I was doing QA for Altec Lansing's R&D branch in Kfar Saba, Israel. Back then we would put out innovative, audio-related devices like (gasp) USB audio devices that worked on Windows ME and 2000. They were buggy and setting them up wasn't the straightforward thing that it is today. We needed docs. We had some hoops that users had to jump through, and we needed a way to document what they were, what the edge cases were, and how to diagnose and fix all of that stuff. It needed to be nicely packaged, cleanly formatted, and accessible to users who installed our helper application. I found the Robohelp application, which is used for creating standard help applications on Windows, and added a help file to our install. During our QA process, we would identify the issues, document what we thought was salient, and organize it into the help file that was bundled with the device. I was 19 at the time, and I had zero experience with this stuff, and it was an immensely naive process. Nonetheless, it just felt like the right thing to do for our users, and my manager didn't explicitly tell me not to. It's been 24 years, and since then I've done documentation for a bunch of projects. The scale has grown, and the way that I look at those types of projects has substantially changed. I have some thoughts about what makes for good docs and I'd love to share them with you if you're interested. Core Documentation Concept I’d like to start with a set of more concrete rules that I believe are critical to a documentation product's success. - so don't use words or complex sentences to describe what can be said in simpler terms. You will lose users along the way and it isn't worth your writer's ego. Docs should use small words to describe big ideas flourishy - because a personal, relatable set of tasks that tell a tale will be more engaging and memorable for your user than an abstract set of instructions. Docs should tell a story when you can - because seriously: this is a no-brainer. If your docs are not easy to find stuff in, your users won't find what they need. Docs should be searchable - and this is especially true when it comes to software products. This touches on the larger topic of developer advocacy, but in short: your docs should be supported by video tutorials, real use examples, and live technical support. Docs are almost always part of a larger strategy - because you may be sure that everything is right, but without real users, like with any other product, you won't know for certain. Test it and test it again. Docs should be tested Holistic docs are well-designed Products When you learn a new , concepts and ideas from that language flow into your bag of problem-solving tricks. It makes you into a better software developer and at the end of the day, you make better software because you are more aware and capable. programming language My career has been a complicated one and included a lot of software product design, software development, technical support, and developer advocacy. Each discipline has influenced how I think and approach others. When I approach a Technical Writing project, it's with this broad view of what it is that a user is going to need. I think that's the right way to think about docs: holistically. Docs aren't a well-defined thing and to make good ones you have to be flexible. To me, that means you have to think about your users from as many angles as possible. You can't take anything for granted or you're going to let some group of users down in a way that will negatively impact your brand, your product, or your business in a way that is hard to come back from. Your docs are very often a make-it-or-break-it experience for your users. If you do a good job, your users will use your product successfully, and become champions of your brand. If you don't, they will likely never use your product again because your docs left a bad taste in their minds. They will also let others know. Good marketing starts here, so keep that in mind. Making good docs Making good docs simply means that you must approach your docs creation as you would any other product process. You need to: Know why you are creating your docs Know who your target audience is Know what their pain points are Improve your docs over time Let's take a closer look at each of these. Knowing the why of your docs is often a really straightforward question and answer set on its surface. You are creating docs because if you don't, users will fall through the cracks and fail to use your product. At a deeper level, there is a specific answer for your use-case. Have a developer tool? That's one answer set. Have a retail design tool? Have an Accounting SaaS product? Have an automatic coffee maker? These are all separate answer sets. The form of your docs is described by who will use it. Is it online? Is it bundled with an app? Is it printed? Every user base will need something else and you have to be clear from the get-go who they are. Your job is to figure out what is hard for each of your users and craft your docs around funneling them through informative content that solves their specific problem. Most importantly, you have to know that you probably aren't going to get it right the first time. That means that your docs need to be maintained and updated as your products grow and change over time. Hopefully, this is done within some framework that allows easy communication with those users you are trying to help. You have to talk to your users, listen to their needs, and try to use your docs to make their experience using your product a better one. Your docs are an integral part of your success I'll sum up by simply underscoring how critically important docs are. Without them, your users are on their own and must fend for themselves. This will always mean fewer success cases, poorer views of your product within your ecosystem, more unhappy developers or users, and a negative impact on your brand or company. Docs are a serious sub-product in their own right, are an investment, and must be part of your wider product strategy. Also published here.
