Technical writing tools to know

Technical writers don’t need to know everything, there are a lot of apps and tools that you can use to get the job done. If you’re just getting into technical writing, you might wonder “What technical writing tools should I know?”

The software that you use and the skills that you need will vary depending on where you work. Every organization will have their own preferred tools for writing and publishing content. So my advice is: don’t worry about the specific tools. It’s more important to know the concepts and wherever you end up working will teach you the specifics of the tools they use.

Here are a few “software concepts” you should know, if you’re just getting into technical writing:

Code editor

Most of the time, you’ll work with “code” in a “visual” tool like a web Content Management System (CMS). That kind of software will show you what the output will look like as you’re writing it, almost like a word processor would do.

But sometimes, it’s helpful to copy some generated code and work on it in a code editor. That doesn’t happen all the time - but when it happens, knowing how to use a code editor is invaluable. You should know your way around at least one of these tools:

Microsoft’s Visual Studio Code is a very powerful code editor that can do a lot of things. It’s really popular with a lot of programmers, but it’s super handy for working on HTML and XML content, too:

Any Integrated Development Environment (IDE) will do. Different teams will try to standardize on different tools, usually something that the programmers are already using. Eclipse IDE is another development environment that a lot of programmers use.

At the bare minimum, you should be comfortable working in plain text using some kind of editor. If you don’t use an IDE, you should al least know how to use an editor like Notepad++ or whatever text editor you have on your system.

File management

When you work with all your files in the “cloud,” you start to forget that eventually you’ll have files to publish somewhere. The basics of file management come up a lot in technical writing. You need to know where you’ve saved a file or where your team stores all the project data and assets.

It also helps to know something about file transfers like how to push files from your laptop to a server somewhere. But publishing content as files isn’t something that happens all the time, or by everyone on a team. That said, if you know a file transfer software like Filezilla, you’ll quickly become a power user.

A lot of web servers run on some kind of Linux host. It’s not too likely that your organization will actually let you log in to the server to manipulate files directly. But sometimes, knowing how to login and do stuff at on the command line can be a shortcut to solving problems. So if you know how to use an ssh client like Putty, that’s a bonus.

Graphics

A lot of organizations have a graphics department or “branding” department that creates graphics for you. But if all you need to do is crop an image to a specific aspect ratio, or resize a photo to a more appropriate size, knowing the basics of a graphics application like Photoshop or GIMP can save valuable time.

It’s unlikely that a technical writer will need to create vector graphics like SVG, but sometimes a simple SVG is just what you need. If you know how your way around an SVG application like Inkscape, you’ll be very much in demand.

When you’re writing a manual or other “how-to” document, including a screenshot of what the screen looks like can make your document much clearer, and without so many words. In every office I’ve talked to, everyone just assumes you know how to take a screenshot, so know how to use the screenshot tool on your system.

DITA editor

DITA is super powerful for the right job. If you need to create documentation by reusing and remixing other stuff you’ve written before, then that’s a perfect use case for DITA. With DITA, you divide the content into “topics” like DITA Concept files to describe a thing, DITA Task files to list steps, and DITA Reference files to list specifications. You’ll find there are lots of DITA tools, so don’t worry about finding the “right” DITA software. Find one and learn it; knowing how to use one of them will really set you apart.

Publishing

A ton of “everyday” stuff gets done in a word processor, so you should know one of these. Dig deeper than just bold and italics, and learn things like how to use block (paragraph) and inline (character) styles, how to create headers and footers, how to add page numbers, and other, more advanced features of word processors.

In most organizations, especially ones that are more “established” like legacy companies, Microsoft Word is still pretty popular. It’s a good word processor, but the desktop version is much more powerful and feature-rich than the web version. Specifically, Word on the Web is good for basic formatting and rough drafts, but has a tendency to change how text flows around floated objects like images. What you get on screen may not be what you get in a PDF.

A lot of people really like LibreOffice Writer too, and it’s free so you can’t beat that. LibreOffice has been around a while too, longer than you think, and it’s very stable. It also runs on a variety of platforms.

If you are in a larger organization, there’s probably a graphics or publications team that generates print-ready material like fliers and posters. But in small to mid-size companies, you may not have a separate team for that, and they’ll look to the technical writer to make fliers or handouts for the next conference. So knowing a desktop publisher like Scribus will help, but it depends what you do and where you work.