I am a fan of the PARA method by Tiago Forte for organizing information, and I have brought this to how I organize docs in my teams as well.

I believe, at a high level, you can separate between two major types of notes:

1. 🔨 Project Notes

2. 🎨 Area Notes

—

1) 🔨 Project notes are the stuff you need to deliver a project.

A project is an initiative that has a beginning and an end, and may involve multiple areas (cross-functional).

Likewise, projects need a diverse set of docs, including PRDs, design docs, rollout plans, and more.

—

2) 🎨 Area notes are long-lived documentation about a specific area.

An area is anything for which you need to maintain a standard, and that stays relevant for indefinite time (as opposed to projects, that have an end).

e.g. engineering onboarding, database schemas, company org charts are all examples of docs that may not belong to a specific project, but rather to a long-lived area.

—

Most action happens in project notes, while area notes are more useful for future reference.

Also, this separation is not static: after a project is delivered, you may archive most of its material, and move some of it into the respective areas, where it will stay useful for longer.

For example, you may move the database migration specs into the general database docs, or the PRD into the product area.

If your system supports it, you may tag content rather than move it.

E.g. I like Notion for docs because it is flexible and you can define areas and projects through relations and tags, rather than folders.

But you can do this in any tool, like Confluence, or Google Docs.

I wrote a full guide on how to write documentation and it’s one of the most popular Refactoring articles ever 👇