Skip to main content

Writing about third-party software

As a general rule, avoid including instructions on installing or integrating third-party products. To ensure that readers get the most up-to-date information, link to the third-party product's own documentation whenever possible.

What to include​

Include only the parts that Unity controls, such as the following information:

  • The purpose and general principles of the integration.
    • For example, "Use ThirdPartyTool with Unity to do Y. This process produces a file of type X."
  • Any features that don’t work with the integration, in full or in part, with a short description of why they don’t work.
    • For example, "When you use ThirdPartyTool with Unity, features X, Y and Z don’t work. This limitation is because…"
  • Version, account, and licensing compatibility.
    • For example, "To use ThirdPartyTool, use Unity 2021.2 or newer."
    • For example, "To use ThirdPartyTool, use their Developer Account."

What not to include​

To avoid errors and future problems caused by the third party’s updates, don’t include information that the third party fully controls, such as the following information:

  • UI and workflows
  • Rules (for example, password rules)
  • In-depth feature explanations and limitations, except where the limitation is specific to the Unity integration
  • Screen captures of the third-party product

Instead, link to the third-party product’s documentation as much as possible.

What to do if instructions are scarce​

If the third party’s instructions are poorly written or don’t exist, make a judgment call on a case-by-case basis. Generally, aim to minimize future maintenance.

Consider the following criteria, and consult with other writers or your lead if required:

  • User base: What kind of users does the product have? Are they very technical? What’s a reasonable amount of prerequisite knowledge to expect of them? Could an average user figure it out?
  • User impact: How much time and energy are users going to have to spend figuring stuff out? How critical is the product? Will users be totally blocked if they can’t get it to work? How much user feedback, if any, has Unity received about working with the product?
  • Third-party product complexity: How easy is the product to use? Does it have a GUI or WYSIWYG interface?
  • Burden of maintenance: How frequently does the third-party product change? How much effort is it going to be to keep your content up to date? Is that overhead worth it? Is it going to provide enough value to users for the time and effort involved?

Flagging third-party information​

If you do need to document a third-party product, make it clear to users that the information might be limited or incomplete. Use the following boilerplate text:

Attention: The following concerns a product or service (each a “Third Party Product”) that is not developed, owned, or operated by Unity. This information may not be up-to-date or complete, and is provided to you for your information and convenience only. Your access and use of any Third Party Product is governed solely by the terms and conditions of such Third Party Product. Unity makes no express or implied representations or warranties regarding such Third Party Products, and will not be responsible or liable, directly or indirectly, for any actual or alleged damage or loss arising from your use thereof (including damage or loss arising from any content, advertising, products or other materials on or available from the provider of any Third Party Products).