Making documentation for WordPress plugin [Episode 5]

Recap of Episode 5 of WordPress Plugin Startup Show: 14 July 2020

* SpeedGuard is a WordPress plugin to keep an eye on your site speed, in background.

* AB Split Test is a WordPress plugin to improve your website conversions automatically.

In episode 4 we started talking about making documentation for WordPress plugin, and we continue today.

Good documentation helps users to find answers

Even super-tech documentation can be written for humans!
For example, API documentation can include a problem-solution approach rather than just a list of functions and methods. Even Google does that!

And you don’t really expect that much from giant, but you do expect a more personalized approach from a small company!

I also find the GitHub Pages interface appealing for API documentation, here is what Timber’s docs look like there.

When users can easily find answers, it means:

1. less number of support tickets – obviously
2. more likely that people are getting the most out of the plugin 
3. and therefore more likely that they will renew it!

But also there are additional benefits:

• The community around your product is building up. For instance, ACF has a lot of questions answered on the forum. People help each other with specific problems. These pages are often the first search result when you googling something similar, and if you search ACF site they will br shown along with docs pages.
• You get a chance to understand your users better: What are the most commented-upon items, for example? The most viewed? The most cited? It can reveal holes in the sales funnel too.
• It helps to onboard new clients better (meaning, it helps to avoid refunds).
  If they don’t know how to use your product, or can’t see all the benefits they might abandon it (not renewing a license is almost as sad as asking for a refund). But this doesn’t mean it doesn’t solve their problem! It’s just that you haven’t show properly that it does. Lose-lose situation.

What sections should documentation include? What structure should it have?

Toolset used customer segments and customer journey to update their documentation recently. They explain things according to who is reading, and what that person is going to do with a help of their plugin. They even made a course for each case!

WP Rocket has a Troubleshooting section with lot’s of answers to cases then something doesn’t work as expected. It’s super relevant for any caching plugin users as each install has it’s own environment (plugins, themes, 3rdparties, server setup, CDN etc). And this is very common stage when people need assistance.

Advanced Custom Fields’s documentation expectedly has loads of technical information, and it’s organized in very clear way.

For example, each field’s page has the following sections: Description, Screenshot, Settings and Template usage. So you can see the usage of that specific field from all sides. Also, I’m not the only one to notice that while ACF’s documentation is all about code and functions it doesn’t feel machine-to machine talk somehow, but human-to-human! 

Though these three plugins’ documentation might look quite different I think all of them share the same approach. They target exactly on what their users will be looking for.

Next week we’ll be talking about using WordPress plugin documentation to get NEW users!