Designing shared folders by work purpose

Design shared folders around the tasks people perform and the access each task needs. A department name alone often hides whether a folder contains drafts, approved templates or completed records. Begin with a small map of work purposes, assign an owner to each area and test whether a new colleague can find a file without knowing who created it.

Map the recurring journeys

Ask team members to show where they look for a project brief, a current working file, a reusable template and a completed deliverable. Note repeated detours and personal-drive copies. Group files by the questions users ask, not by every possible attribute.

A practical top level could separate active projects, shared resources and archive. Inside active projects, use a consistent structure only where teams truly share a process.

Do not build a tree so deep that every file has several plausible homes. If a document serves two teams, choose one authoritative location and provide access or a pointer from the other workflow where the product allows it. Copying the file creates a version problem.

Establish what an export or snapshot means when a true copy is necessary.

Folder Structure: By Department vs. By Work Purpose

Match boundaries to permissions

A folder boundary is useful when it corresponds to a meaningful audience. Internal finance drafts should not be placed beside material shared with all contractors merely because both relate to the same campaign. Check how the platform applies access at each level, then test the structure with real roles before migration.

For each folder, record its purpose, owner, who can add files, who can share externally and when contents are archived. Keep exceptions visible. A long list of per-file exceptions makes the folder's apparent access misleading; sometimes a separate restricted area is clearer.

Use names that survive staff changes

Avoid initials and temporary project nicknames as the only labels. Include stable identifiers that people recognise, such as client, project or year, but do not repeat every parent folder name in every filename. Define a rule for approved output and a rule for working drafts.

The goal is not perfect uniformity; it is to make the correct location and current state easy to infer.

Choose a person to review the top-level structure after teams or projects change. When a member leaves, review whether the surviving folder still makes sense. Retire empty or obsolete areas deliberately rather than leaving them as traps for new work.

Test before moving the archive

Create a pilot with a few active files. Give a new colleague three retrieval tasks and ask them where they would save a new file. If they choose different homes for the same type of work, revise the labels or examples.

Then check a restricted account's view. Only migrate broader content once ownership and access rules are understandable.