Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How do you structure your page trees for internal knowledge bases for processes or software?

I'm always curious how other people decide to design their knowledge base page trees. Ideally, it would make sense to both technical and non-technical viewers (even if they don't always all of the content like database schemes, etc).

For more complex projects we use something similar to this:

  • Team & Communication - This is an overview of the project
  • Development - different pages for test data, system architecture, new dev guides/resouces, dev/uat/stg/prod infrastructure, integration points, 3rd party components, etc.
  • Meeting Notes - internal/external meetings related to the project
  • Project Management - estimations, project plans, etc
  • Quality Assurance - overviews of qa environments, reports, testing plans, etc
  • Requirements - Technical requirements for the application; This is where most of the content lives. 
  • Retrospectives - mostly meeting notes from the dev team
  • Trackers - decisions, change requests, glossaries, dictionaires, external documents, scheduled tasks, etc.

For less complex projects we use something like this (adapted from this article):

  • 00 - About - General introduction and overview of the project, team and communications
  • 01 - Roadmap - All things related to planning and specifications. This is the main working area for the analysts and will contain things like backlogs, wishlists, functional specs for a future version etc. This is the main area where you will find the actual projects.
  • 02 - Development - Groups everything that someone needs to know to be able to develop on the application. Note that a technical analysis for a specific story to be implemented does not belong here, a technical overview of how something is implemented does.
  • 04 - Release Notes - This section gives an overview of the entire release history.
  • 05 - Maintenance & Support - This section groups all documentation relevant for operational (technical) support of the Knowledge Base. Ideally, this is enough so a team member without knowledge of the inner workings can offer basic support (like editing articles, check log files, etc).
  • 06 - User Documentation - Contains all end-user documentation like manuals or public API's.

Just curious how those more experienced handles this and I'm looking for ideas and best practices we should start following. 

1 comment

Hi! Thanks for your post in listing your internal page structure. I was looking for best practice examples. One or our requirements building out the below table of contents was that it would be designed for technical and non technical team members to be able to navigate. Here is a navigation tree I developed with my team in my last company.

It was a challenge managing it as we grew, as the laws of entropy strike first in documentation and there are always other tasks that seem more important than playing a librarian - though it was worth it for our team.

* Introduction

* Onboarding Overview

* Training

* Teams

* Ceremonies & Meetings

* Initiatives & Projects

* Process and Procedures

* Testing

* Release Management

* Production Support

* Business Capabilities And Tech Components

* Terminology

* Miscellaneous

* Confluence Feedback

* Product Refinement Process

* Ideas for Machine Learning


* L1/L2 Production Support How-to articles

* Platform Applications

* Product Strategy

* Run Books


Log in or Sign up to comment
AUG Leaders

Atlassian Community Events