The variety of tools tech comm professionals use
Background
Ferry Vermeulen from INSTRKTIV asked more than 70 technical writing professionals (from conferences such as Lavacon, MadWorld, COMtecnica, ETC, tekom Berlin, Nordic TechKom, and Information Energy) the following question:
If you could use just three technical writing tools in your company, which ones should you use (in the technical writing tools definition, standards and other helpful attributes are included)? (See Technical Writing Tools: The Ultimate Expert Choice.)
Of course if you ask people at Madworld, a technical writing conference focused on MadCap Software products, what their favorite tools are, they’re going to include Flare and other MadCap products, so just keep that in mind.
However, the mix of professionals from European conferences like Tekom (a large TC conference in Germany) and Lavacon, which isn’t focused on any specific tool but rather leans toward content management and content strategy, provides more of a well-rounded mixup.
Highlighting a Few Responses
Looking through the responses, I’d never heard of IEC 82079-1:2012, which Ferry describes as “The international standard for User Instructions.” (Even looking at the link, it’s still vague to me.) Solidworks Composer looks like a good tool for documenting machinery graphics that require exploded 3D images.
George Bina mentioned Schematron, which looks useful if you use oXygen XML Editor.
Subash Babu Asokan mentions EpicEditor, a JavaScript-based Markdown editor that you can configure through an API.
Some people avoid listing technical tools and instead list conceptual “tools” or theories, such as minimalism principles, structured technical writing (DITA), usability testing and task analysis, cross-industry thinking, “Not to apply our mental model for that of the user,” and “my brain.”
It’s clear for some, they work in more high-level strategies and concepts and probably don’t always perform the tactical, nitty-gritty execution. That or they’re just tool agnostic.
Joe Gollner listed Github as an essential tool, as did some others. Lukasz Gornicki says Github is “hosting that enables … whole new ways of generating and hosting documentation content.”
Qian Li listed Microsoft Lync (an instant messenger client) as an essential tool. Eric Reiss listed Skype.
Stefan Dierßen listed Phonegap, a tool to build mobile apps. And Neil Perlin listed Viziapps, a similar mobile-app-building tool, in their lists.
Andrew Lawless listed Termweb, a terminology management solution.
Magda Caloian listed “Writing on Post-Its” as well as “Books (exactly, real books).” (I’m wondering which books. Are we talking fiction, style guides, or industry books such as those reviewed in the TC Journal?)
Marc Achtelig listed Freemind, a mind-mapping tool.
Dimiter Simov listed Axure, a prototyping tool. Chris Steele listed Verify, another prototype-feedback tool. Chris explained why:
A good UX tool is priceless. Something like Verify to collaborate and test UI layouts helps build data-driven decision in design. Too often there is contention around untested opinions. A philosophy of research, good practices/methods, with a tool to support the process can align cross-functional team members to create a positive user experience.
Andrea Maliska listed Sketch and Sabine Stoye noted Inkscape. Maliska says she likes Sketch “for wire-framing and building out mock ups for UX and design.” It’s “lighter than having to learn photoshop.” She also listed Trello, which allows you to organize your projects using cards. Hmmm, Trello. I’ve heard of this tool quite a bit. Maybe it’s time to try it out?
Various people (mostly Europeans) listed quite a few XML-based CCMSs that I’ve never heard of.
Sarah O’Keefe listed structured content, terminology, and automation (defined as “tasks where humans don’t add significant value”).
Eric Reiss made this comment about tools:
To be perfectly honest, I’m not sure it really matters which tools one uses when working with UX in general and usability specifically. First of all, the tools change and evolve regularly, so what may be a good tool today can easily be replaced by something better at any time. Second, a tool is never better than the person using it; just buying, for example, Camtasia Studio from TechSmith for screen recording (which is a very solid and widely used suite of products) will not make the quality of your work better.
Good points! Still, at some point in the execution of a strategy, you have to open up a tool of some kind.
Anthony Apodaca listed Omnifocus, which is a kind of productivity smartphone app.
Lukasz Gornicki listed “Documentation Continuous Delivery” as a tool. He describes this approach as follows:
It is about having a solution that allows you to easily scale the content delivery process across an organisation without the need for any special on boarding. It is about enabling delivery development teams to provide as much content as often as they need with just one click. I’ve presented it at a few conferences already: https://github.com/derberg/documentation-continuous-delivery. This year I talk more specifically about the approach and its usage with Microservices infrastructure and will present the tooling for it that we are open sourcing before the end of this month.
Gornicki is one of the few tech comm pros to list static site generators in his toolset. I was hoping to see more docs-like-code responses in the responses. There were quite a few people who listed Github (often with DITA complements), so this suggests some trends at least.
Andrei Essaoulov made an interesting comment, essentially highlighting the shortcoming of tools to handle all the needed situations:
As a note, what I bump against a lot recently is the necessity to manage collaboration on content created in different tools: As an API writer I need developer input, I need engineers to write, but they prefer to write Wiki or markdown. I also get input from support and marketing, and they are Word users. So, if I were to create a perfect collaboration environment, it would allow Wiki, and maybe form-based technical writing; it would have markdown/ASCIIDoc capabilities; and also efficiently ingest Word into some kind of XML-based backend CMS. I feel like whoever comes up with that will corner the tech comm technical writing tools market.
Conclusion
Overall, Ferry’s post provides an interesting lens on the tools that tech comm professionals use. If you’re looking for a tool to do something, you might browse this list. This list of tools also shows you the diversity and variety of tools that people in our profession find indispensable.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.