Do you have administrative users, developers and end users that use your application? If so, then organizing your knowledge base by user role can be a good option.

Create a section for admins, developers and end users. By grouping the content in this way, you make it easier for customers to find the information they need without being bothered by the information they don't.

Do you have different customer segments that use your product? Do they use it in very different ways?

We ran into this problem. For example, we have customers that integrate with Zendesk. Instead of creating a single integrations section, we created a separate section for each integration.

Much of the help content for each integration is similar, but that is fine. By segmenting our documentation by the intent of the customer we have seen a big decrease in confusion and support requests.

Does your software perform tasks that fall into logical groupings? For example, creating invoices, generating reports, and reconciling payments. Those are three separate tasks.

Those tasks could be a good way to break up your documentation.

Don't confuse this with breaking up your documentation by feature. Feature-based documentation is rarely as effective as task-based documentation. Focus on the tasks your customers want to perform and create your sections based on tasks, not features.

Do your customers have different goals or purposes for using your software? Organizing by goals can be a good option.

For example, if you were an email marketing application you might create sections such as follows:

• Growing your subscriber list
• Using email to sell your product
• Using email to sell your services
• Using email to establish yourself as a thought leader

Each section would have articles that would help your customers reach their particular goal.

Whichever method you choose, choose one. Some organization is better than no organization. Your customers and your authors will thank you for having a clear organizational strategy.