In this article
Why it’s important to organize your corporate wiki
Before joining the Atlassian Ecosystem in 2013, I used MediaWiki (the software behind Wikipedia among others). After 5 years I moved to Confluence — you know what? There aren’t many differences in software, but when it comes to structuring your wiki, the nature of the hosting organization is important.
A wiki for an open community like Wikipedia starts from scratch, but a corporate wiki has unique needs. These include employee users (rather than volunteers), complex access control and content approvals, and corporate settings that should be mimicked (internal processes, policies, department structures, existing projects, etc.) and aligned to the business strategy.
But why? Because we want a wiki to be successful and serve its purpose, whether that’s document management, knowledge base, teams collaboration, or any other goal we set for it. In this article, we’ll dive into the basic foundation to structure and organize your corporate wiki.
What to organize in a corporate wiki
There are three basic hierarchies to take into account:
- The Wiki level: where we have to decide on spaces
- The Space level: where we have to think of the page hierarchy for those spaces
- The Page level: where we have to plan the structure of the content within pages
You don’t have to organize the whole wiki on day 1. Wikis evolve thanks to their community (Ward Cunningham referred to this as the wiki’s Organic Principle), so the structure will grow over time. But don’t fall into empty wiki syndrome either.
Create a basic initial scaffolding to encourage users to start adding content.
The empty wiki syndrome is an analogy to writers' "Blank Page Syndrome," where a person experiences a block, gets stuck, and stares at a white page without knowing how to start.
Before we start thinking about how to organize our wiki, choose your planning tool: A piece of paper, a text editor, a whiteboard, or anything else. PRO TIP: do not start directly in Confluence. This is so you focus more on the tool than on the structure.
One method, displayed below, is to work with mind maps (each node equals a page), because the radial hierarchy helps to structure and break down the scaffolding. But there are many ways you can approach this.
PRODUCT SHOUTOUT: Whiteboards (an Appfire app) is great for creating roadmaps and discussing ideas with my team, and it’s ideal for this task 💯 recommended.
Wiki level organization
At this level there’s no hierarchy and each space is at the same level. The only mechanism (without resorting to external apps) that you can use to categorize is labeling. If you’re interested in diving a bit deeper here, check out this session on creating a label system in Confluence by K15t.
Here it’s recommended to start with your own organizational setting to create a space for projects, services, clients, products, categories, departments, or similar entities (leaving personal spaces aside). And each of these corporate units may have a different aim: Knowledge base, documentation, project management, research, daily work, etc.
Think about your organization and determine if a client, project, department, service, product, team or a role should equal to a space. If the answer is yes, you have your initial structure.
Example: Product solution space
Here’s a real example: Appfire is a solutions company, and we group our apps into 9 solution-based categories. This looks like one space per solution category (e.g., the BI/Reporting category where I work is a space).
We also work in core teams called triads to handle the products in these categories. The team is made up of Product Marketing, Product Engineering, and Product Management, so we also have 1 space per each of these teams.
Beyond that, there are spaces that house information for the rest of the company: Support, Corporate Social Responsibility, Operations, Human Resources, and News.
Space level organization
At the space level, there are more mechanisms to mimic our corporate unit, whether it’s a product, project, service, a team, or other. In Confluence, we can use Space blueprints, which are templates to create spaces with an overview, a few pages, and sample content to help you get started.
Confluence provides a few by default, some third-party apps provide added templates, and you can even create your own if you have technical skills.
Project blueprint space
Imagine your organization always creates a space for each new project with the same initial project structure: Project document control, project definition, scope, assumptions, risk assessment, stakeholders’ requirements, budget, deliverables, Gantt, roles, responsibilities, quality plan, and so on.
It would be useful to have a custom Space blueprint “Project space” with all those elements as pages as the initial page hierarchy, and some of those pages with a content placeholder to encourage initial contributions.
Interestingly, in project management jargon, the initial project document is also called “project blueprint” where the project definition, scope and approach, risk assessment, and deliverables are indicated.
Product documentation space
If we write product documentation (i.e., a space to document our products), we again have to replicate our corporate setting and provide consistency, because consistency helps both contributors (content writers, developers, product managers) and clients.
So we follow a similar page hierarchy in all our document spaces. Contributors will find it easier to start working in a known hierarchy. Similarly, clients will know how to find the answers they need by referencing Getting Started, User Guides, Help Center > FAQ, Support, and Product News.
PRODUCT SHOUTOUT: We document each product in a separate space and publish a new version every time we do a release. Using the app Scroll Viewport, we keep the draft document and the published version separate.
Product solution space
Using Appfire’s BI/Reporting category space, we follow the same mental model as before, mimicking the corporate setting on our page hierarchy.
Because we work in core teams, we create the same structure: Product Management (PM), Product Marketing (PMM) and Product Engineering (PE).
We then add child pages based on the work of each team e.g., Product Roadmap under PM, Email Nurturing under PMM, or Security Audits under PE.
Page level organization
The last part to discuss is organization within our pages, how we structure the layout of the content using text formatting, headings, images, tables, and so on.
i) Consistency again is important, and Confluence offers more than 70 templates to help your team prepare marketing plans, communicate incidents, add your meeting notes, or set your OKRs. Use them whenever you have the opportunity.
Page template or blueprint? The two are very similar. Blueprints are templates created by Atlassian or by third-party apps, and page templates are the ones you create.
ii) Well formatted pages are also key. Whether you want to describe a company policy or display data, take a moment to make your content easier to read and understand. Use layouts to structure the content and tables to present your most important data. Help viewers get your message at a glance.
Once you’ve determined how templates should be used (to provide consistency and page formatting to present content effectively), it’s time to create your own templates. Modify existing templates or create new ones to work with custom templates, adapted to your internal processes.
Example: Product analysis template
Because Appfire has more than 200 apps in our portfolio, it makes sense to do regular product comparison and analysis. That’s why we created a page template to outline a consistent analysis process that’s easy to put together and read through.
With this template, we don’t have to worry about remembering key metrics or indicators to look at: the template and content placeholders do this for us.
PRODUCT SHOUTOUT: Content is key, so you have to present important data is an a functional and beautiful way. We use Advanced Tables for Confluence in our product analysis page template.
Let’s structure Atlassian Confluence for success
Check out this Livestream recording – now available on demand – on how to structure spaces, page trees, and pages so people can find what they need in Confluence. Hear from Matt Reiner from K15t, Gorka Puente from Appfire, and DJ Chung, Senior Product Manager on the Confluence & Discovery Organization team, on this deep dive into successfully organizing your Confluence site.
A wiki’s organic growth should not hinder its usability and access to content. Mimicking the corporate setting simplifies adoption and contribution by users, and provides direction. That way, corporate strategies permeate the wiki scaffolding and facilitate user participation.
Using a known structure of pages and spaces will simplify things for your colleagues because it communicates what content you need for each page. This increases participation and encourages healthy collaboration, ensuring your wiki thrives.
Start small—don’t try to create a hierarchy for the whole organization. First, at the Wiki level, decide on your own projects/products/departments. Then at the Space level, take the space that you know the best and create the initial page hierarchy. Finally, at the Page level, work on the home page.
When you and your team are comfortable, move on to the next steps: Page and space templates, advanced page formatting, etc.
And don’t forget to smile you did it!
Last updated: 2022-08-04