In custom software projects, it can be difficult to avoid documenting third-party software. Especially when the custom software is built for users who have a standard desktop configuration and use other tools, such as Microsoft Office, in their daily tasks. It saves money and time in development when the team doesn’t have to create everything from scratch; we know that the users have access to certain third-party applications that will satisfy parts of the business process.

However, this can lead to a reliance on third-party software. If using that software is an established part of a business process, it falls to the technical communicator to explain when to use it during the process.

Personally, I don’t like documenting third-party software for a few reasons:

  • It can be upgraded or changed at any time, so I have to keep track of those changes in addition to changes to the projects I work on. The steps I provide for one version of the software could be totally different in the next version.
  • It’s harder to document third-party software when localization is needed and it doesn’t readily accommodate multiple-language needs. For something like Microsoft Office or Windows menus, extra effort is necessary to get the right images in additional languages.
  • I’m sure it’s duplicate effort—whatever I document has most likely already been documented.


If something takes minimal effort to document, such as how to tweak a setting in a browser, I don’t mind it much. Speaking of browsers, though, if you’re documenting a Web application and your users may have any browser out there, it can become a pain to document how to do something in half-a-dozen different browsers.

In general, may be good practice to simply direct the users to consult the documentation of third-party software. Of course, we may be tempted to go ahead and document it ourselves if we don’t think the official documentation did an adequate job.

Better practice may be to take some time to find the answers in the third-party documentation first, and then in our own documentation, tell the users how to locate the right information (rather than just saying, “See Microsoft Word’s help for instructions”). This saves the users the effort of trying to find what’s relevant themselves.

Related entries (auto-generated):

Consider Users’ Environment as Part of User Experience

Determining How Much to Document the Transition from Legacy Systems

SharePoint as a Way to Manage Document Reviews

Separating an Application’s How and Why

Why You Should Know How Consumers Use the Products You Document