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

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Defining Confluence space structure for digital documentation

Hi,

I'm trying to define the ideal structure for a Confluence space for a company's digital documentation. My objective is to have a clear structure where the team working into the space know where to put a page when they need to create one.

I realise this is an IA question as much as it is a Confluence question.

I keep coming back to this statement on the one of the Atlassian Wiki pages "The key is to think of a space as the container that holds all the important stuff a team, group, or project needs to work"

Ideally the structure could apply across multiple companies, although I appreciate a one size fits all won't work perfectly in reality (but even so, having a base to start from wouldn't be a bad thing).

Some assumptions to consider:

  • Each company would have their own space
  • A company could have multiple applications (e.g. website 1, website 2, iOS app)
  • Some information could be applicable to more than one application (e.g. an API that is consumed by both a website and an iOS app, or a CMS that provides content to all applications)
  • Each space would include project delivery documentation as well as product related information. Project delivery documentation is 'temporary' but product related information is not. Another way of saying it, some information needs to be maintained (information about a website feature), some does not (a risk log after the project has closed)
  • I had a thought about making a distinction between end-user facing applications (e.g. website, iOS app) and non-end-user facing (API, CMS) but not sure if that achieves anything

 

This is where I've landed with a space structure. Does anyone have any advice, criticisms or thoughts on this?

  • Onboarding / knowledge base
    • How to use this space
    • Company info
    • Developer toolkit
  • Applications
    • General (non-application specific documentation)
      • Architecture
      • API (assumes API that is consumed by all apps)
        • API 1
        • API 2
        • API 3
      • CMS (assumes headless, so provides content to all apps)
    • Website 1
      • Technical documentation
      • Feature catalogue
      • Component catalogue
        • Testimonial component
        • Image gallery component
      • Template catalogue
        • Homepage template
        • Campaign page template
    • Website 2
      • Technical documentation
      • Feature catalogue
      • Component catalogue
      • Template catalogue
    • iOS app
      • Technical documentation
      • Feature catalogue
      • App screen catalogue
  • 3rd party documentation
  • Project delivery
    • Project 1
      • Risk log
      • Project timings
      • UAT plan
      • Go live plan
      • QA release notes
      • etc
    • Project 2
    • Project 3

 

Thank you in advance for your help!

1 answer

One thing to consider is that you cannot have two pages in one space with the same name. For instance, for your websites, you have a sub page called Technical documentation on each. That will have to change to Technical documentation 1, Technical documentation 2 or something similar.

I would probably split off each website and each project as separate spaces, and keep the rest in a general space.

Also consider using the app Space Tree Creator. That way you could set up template spaces for new websites and projects, and create news spaces using these templates with one click. You can add parameters as well, to automatically fill in relevant data upon creation. We use this to create new spaces for subsidiaries.

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira

Announcing the waitlist for Jira Work Management

Hey there Cloud Community members! We’re excited to give you the first glimpse of the new home for business teams on Jira — Jira Work Management. Jira Work Management is the next generation of J...

132 views 3 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you