- You know the invoice exists. You no longer know which folder it is in, because your folders answer several questions at once.
- What makes a folder tree unreadable is not its depth. It is mixing criteria on the same level, and a framework more than thirty years old helps you spot it.
- You leave with a fifteen-minute action: name the axis of each level in your most cluttered folder.
You are looking for a March invoice. You remember the client, roughly the date, and you know you filed it somewhere under Documents. You open Invoices, then Misc, then 2026. It is not there. You finally find it in Clients\Dupont\, next to a 2026-Q1 folder you created in January and forgot about.
This is not a memory problem. Every folder you created answered a specific question. When you opened Invoices, you were asking what kind of document this was. When you opened Clients, you were asking who it was for. Both questions are fair. They just do not belong on the same level, and after a few months one folder holds the answers to several questions at once.
The cost stays small. Taken one at a time, these detours cost a few seconds. Repeated every week, they turn into constant hesitation: where would I have put this? You stop trusting the tree and start going around it with Windows search. Search works well enough, but it does not replace a filing system that holds.
The most common mistake is to think the problem is a lack of folders, or that they are not fine enough. People add levels: Clients\2026\March\Invoices. The tree gets deeper without getting clearer. The real problem is a criterion that changes from one level to the next, sometimes inside a single level.
A framework older than Windows
In 1989, in Information Anxiety, the architect and author Richard Saul Wurman made a simple point: whatever the subject, there is only a limited number of ways to structure information. He summed them up with the acronym LATCH: Location, Alphabet, Time, Category and Hierarchy.
The acronym matters less than the observation behind it. You almost never need to invent a new filing criterion. You pick one of five, and a healthy tree applies one criterion per level. The rest is discipline, not software.
Five questions, five criteria
Each axis answers a different question, and each one breaks in its own way. That is why you have to choose.
Location answers “where?”. It works when the place is the first thing you remember: photos from a trip, documents for a job site, files tied to a meeting room. It fails when the same document has to be found from two different places.
Alphabet answers “what is it called?”. Clients, contacts and course chapters are naturally filed this way, because you know their name before you know their date. It fails when a name changes, or when you do not know the name yet.
Time answers “when?”. Monthly statements, meeting notes and dated versions gain a lot from it. A prefix such as 2026-03-08_ in the file name is enough to sort them without an extra folder. It fails when you search for a subject rather than a moment.
Category answers “what type is it?”. Invoices, quotes, templates and screenshots: when the type of a document matters more than its subject, one folder per category is the right call. It fails when the same category covers ten different clients and you end up searching by client anyway.
Hierarchy answers “what does it belong to?”. A file that belongs to a project, which itself sits under an area of your work, has a place in that chain. It fails when two projects overlap and one file belongs to both.
The mix that makes everything unreadable
Take your invoice. It is filed by client, then by year, then by type. Each level makes sense when you look at it alone. The trouble starts when one level carries two criteria: a Clients folder where Dupont sits next to 2026-Q1, or a list of folders that mixes Invoices and March. You no longer know where to look, because two logics compete for the same level and you have no rule to settle it.
The Misc folder is the classic symptom. It takes in everything that did not find a place, so it is mixed by definition. Before you empty it, ask which criterion is missing. If you cannot name one, the file has no clear home. In that case, archiving it is better than leaving it in a blurry slot, because opening Misc will not help you find it anyway.
This mix rarely comes from bad intentions. It comes from a moment when a folder was created to answer an urgent question, without anyone asking which criterion it added to the others. The habit to build is simple: before you create a folder, write down the question it will answer. If it answers no new question, it already exists somewhere.
A rule you can state in one sentence
A tree holds when you can describe it in one sentence: “each client has a folder, and each client folder holds a year, then a document type”. Here, alphabet sets the first level, time the second, category the third. You can check the rule at a glance, and new files find their place without a decision.
File names matter as much as folders. A stable name such as 2026-03-08_quote-dupont.pdf carries a time axis and an alphabetical axis in the same name, with no extra depth. It works as long as you use the same pattern every time. A name written differently each month breaks the sort, and you are back to searching.
You also have to accept that search will sometimes win. A tree does not need to answer every possible question. It needs to answer the questions you actually ask, the frequent ones, and let search cover the rest. A folder meant for everything ends up serving nothing.
Adapting the criterion to your work
The right axis depends on what you search for most. A freelancer who invoices clients will usually need alphabet and time: clients first, then years. A student will think more in category and hierarchy: the course, then the subject, then the document type. Someone who manages sites or venues will start with location.
There is no universal rule, but there is one question to ask about your own work: when you look for a file, what comes to mind first? That first reflex is usually the right criterion, because it is the one your memory already uses. File by it, and do not override it with a logic that looks better in theory.
When hierarchy fights with time
A project that runs for twelve months produces dated files, and you would like to file them both by project (hierarchy) and by month (time). Both are valid. The trap is putting them on the same level: Project-X and 2026-01 side by side. Keep hierarchy at the top and time underneath: Project-X\2026-01\. That shape stays readable when the project stops, because it does not spill into any other folder.
When a file belongs to two projects, keep it in the main one and put a shortcut in the other. Duplicating it creates two versions that drift apart at the first change, and you no longer know which one is right.
One action to take tonight
Open the most cluttered folder in your Documents. For each of its levels, look at the subfolders and write down the question they seem to answer: where, what is it called, when, what type, what does it belong to. If a level answers two questions, or none, note it. Do not move anything yet.
Then choose the single level that costs you the most time, and rename its folders so they all answer the same question. One level, not the whole tree. Fifteen minutes is often enough, and your next search will be faster, because you will know where you put things.
What this changes for you
You do not need an asset management tool to file your documents. You need one criterion per level, written down somewhere, and applied to every new file. The rest follows: a search that finds what it should, an inbox you empty every week, and a tree you no longer have to work around.
The lesson Organize & Manage sets out the full grid: which axis to pick for each type of folder, the cases where a tree breaks, and an exercise on your own tree. To see where notes, links and files should live, read how to keep context between your notes, files and actions as well.
Sources
Reference checked on 5 November 2026.
See the source of this article
- Richard Saul Wurman, 1989, Information Anxiety, whose LATCH framework is summarized on Richard Saul Wurman, Wikipedia