In Slab, information exists in two ways: topics and posts. You can think of topics as super-charged folders for storing your content, and posts as the content itself. Your information architecture, then, is the way that your topics are organized. 

We recommend that you at least begin setting this up before rolling out Slab more widely within your organization — too many cooks in the kitchen can lead to disorganization and confusion. Gather input from your teammates, but allow the final decision to rest with few key individuals.

As you get started, you'll find that Slab is a blank slate. We designed it to be as flexible as possible, as each company is unique, and will have its own needs and use cases. You have the power to customize your information architecture however you like, but here are some tips to kick things off. 

We recommend creating topics for: 

  • Company. Use this for company-level information, like all-hands notes or quarterly progress reports.
  • Onboarding. Use an onboarding topic to store relevant information for new hires, like reading list, first week to-dos, and tools to start using.
  • People/HR. Use this for company policies, info on benefits, employee handbooks, etc.
  • Teams/departments. You can create a top-level topic to contain individual sub-topics for each team — this will work better if you have a larger number of teams. If you have fewer teams, you can create top-level topics for each team. 

Here's an example organization-wide architecture with top-level topics for each team (top-level topics are in bold and sub-topics are nested underneath). 

And here's an example of an engineering team's individual architecture:

Again, these are just examples — as you continue to build out your wiki, you'll learn more about what organizational structure makes the most sense for you!

It may help to keep the following tips in mind: 

  • Focus on clarity.  Everyone on your team should be able to easily navigate your wiki — not just those who set it up. Get multiple sets of eyes to make sure that your architecture makes sense broadly, and that everyone will know where to look for information.
  • Give teams flexibility. Allow each team to construct their topic (whether top-level or sub) in the way that makes the most sense for how they work. A structure that fits one team's workflow might not fit another's!
  • Allow for exceptions. Remember that you will likely have some exceptions to your  architectural rules. For example, if you've chosen to create a single top-level topic for all teams, it might make more sense to exclude the HR team, and instead create a top-level topic for HR so that everyone can more easily access the important information contained there. 
  • Take advantage of topic descriptions. When you create a topic, you can include a description of the topic's purpose. While not required, these add clarity to your architecture and reduce confusion! 
Did this answer your question?