Tips for writing SaaS documentation

If you’re writing documentation for a software-as-a-service (SaaS) product that releases constantly, it’s easy to be overwhelmed by the amount of new functionality being released that needs to be documented.

But do you really need to document all of it? Nope.

Instead, document the hidden, document the weird, and document the why.

a round blue circle, orblike in nature, representing a SaaS product. there is a corner poking out from behind it, labeled “document the hidden”. there are two yellow circles and a yellow diamond, labeled “document the weird”. there is a question mark next to it, labeled “document the why”.

Consider every new product feature in terms of what the user cares about. Don’t document what the product can do—document what the user wants to do.

I recommend adopting minimalism in your documentation, especially if you’re trying to keep up with the fast-paced release cycle of a SaaS product. Anni Bond wrote an excellent overview on Adopting minimalism in your docs.

I use a series of questions to keep my documentation minimal and to focus my documentation efforts.

Documenting a feature

When reviewing a feature, consider the following:

It’s often helpful to use your role as a user advocate to push for product improvements rather than documenting around problems with the user experience.

Reviewing doc feedback

When reviewing documentation feedback from a customer or the field, consider the following:

Try to understand the root of the feedback. Rather than giving in and adding a quick note about anything and everything, consider what improvements might make sense to make to the documentation or the product to address the core issue.

Documenting strange behavior

When reviewing a request from PM or engineering to document something weird, consider the following:

Write less for success

It might seem like I’m telling you to find a lot of reasons to avoid writing documentation. I am. It’s important to focus on the documentation that customers are going to go looking for, instead of making sure the entire product functionality is documented.

Say your product requires people to confirm their email address before they can start using it.

Will customers read documentation about how to confirm their email address? No.

Do you need to write documentation about how to confirm an email address? Also no.

If you have a strong understanding of your users and their mental models, you can make this same determination for other, more complex, workflows in your product.

Stop trying to keep up with the product and start helping the people using it.