Taxonomy

Classification is unnecessary while there are few items. Twenty documents in one list sorted by recency are all visible at once. The trouble arrives somewhere around two hundred. Three scrolls down and the thing you want still isn't on screen, and any document whose title you can't recall exactly has effectively disappeared.

So people start making folders, and the second problem starts there. Without a rule, everyone invents a different one. One person files by year and creates 2026. Another files by kind of work and creates Planning. A third names a folder after whatever they were doing that week, new-feature-final. Put those three side by side on one screen and a new hire has no basis for deciding where their own document belongs. What actually happens is that nobody opens anyone else's folder and everything gets found through search. The folder tree stays on screen, unused, and nobody can point to the moment it stopped working.

A taxonomy is that rule, decided once and written down. Which attribute divides the items, how many levels there are, how many branches a level holds — all settled in advance. It exists so the decision gets made once instead of per person.

It starts by choosing a single dividing attribute. The same pile of documents can be split by team or by kind of work, and mixing both on one level turns every individual item back into an argument.

Five steps.

1. Gather the real names and read them. Not the categories in your head — the two hundred titles currently in use, laid out so repeated words surface. A scheme built without this step usually fits only the person who built it. Reading real titles also tells you which branches you were about to invent and nobody actually needs.
2. Choose one dividing attribute. The deciding question is what users remember when they come back looking. If someone hunting a six-month-old meeting note remembers which team it belonged to but not when it happened, team is the attribute. Asking people how they would organize the content gives a different and less reliable answer than watching how they look for it.
3. Decide how many levels. Two or three is normal. Past four, reaching one item takes four clicks or more, and people give up in the middle.
4. Decide how many branches sit on a level. Five to nine is the convention. Nineteen items on one level makes scanning the level a task of its own, and the items near the bottom get opened far less than the ones near the top regardless of what they contain.
5. Decide what happens to items that fit nowhere. Keep one catch-all branch, but measure what sits inside it. Once 20 percent of everything lives in the catch-all, the problem isn't too few branches — the attribute chosen in step 2 is wrong.

Items that keep belonging to two branches at once are another signal. A hierarchy gives each item exactly one home, so a feature spec written by the marketing team raises the same question every time it's filed. The answer there is not to subdivide further but to supplement with a faceted filter, which narrows by stacking attribute conditions and therefore lets one item answer to several at once.

Three places account for most of the use.

The first is building navigation — the menus and lists that move people between screens, and the form in which classification actually becomes visible. Split content into eight branches, surface four of them in the menu, and the other four might as well not exist.

The second is drawing a sitemap, the tree diagram of a product's whole structure. Draw the diagram before settling the classification and the picture reflects the taste of whoever drew it rather than any real structure.

The third is designing search UX. When results get grouped, or filters appear beside them, those groups and filters come straight out of the taxonomy. With no classification there is nothing to do with a hundred results except print them in one column, which is the state most products are in when someone first complains that search is bad.

Naming comes next. Deciding what each branch is called is labeling, and a correct division with wrong names still leaves users walking past the right place without opening it.

"Should the taxonomy go by team or by kind of work?"

A proposal to settle the dividing attribute. Every screen downstream changes with that answer.

"A third of everything is sitting in the catch-all folder now. The taxonomy needs another look."

Raising the problem that the scheme no longer holds the items it has to hold.

"The taxonomy has three levels and the menu only shows two of them."

Pointing out a gap between the structure on paper and the structure users can see.

At Pagedeck, Noa took this on once the average company passed four hundred documents. Pulling three hundred real titles and reading them showed four kinds — meeting notes, specs, retrospectives, and customer support records — covering 78 percent of everything. Only 11 percent had a team name in the title.

Mia still pushed for team as the attribute. Noa, who had watched ownerless team folders pile up at a client that reorganized twice, asked where those documents go after a reorg, and there was no answer. So the first level became the four kinds of work, and team moved to a filter instead.

The most common mistake is treating this as a one-time decision. Calling something a skeleton makes it sound like a thing you don't revisit. But items keep arriving, and arriving items outgrow the branches drawn for them. Four branches split around four hundred documents become, at four thousand, one branch holding fifteen hundred. Teams that measure the catch-all ratio and the largest branch twice a year see that point coming; teams that don't find out after users have quietly switched to search-only.

Copying the internal org chart is the other frequent one. The chart already exists and is already agreed on, which makes it look like the fastest route. Organizations change, though, and the classification stays. Merge two teams and two folders sit there with no owner; the new team that formed last month has no home because nobody made one. Most of the people using the product have never seen that chart in the first place, and asking them to learn it before they can file a document is a cost the chart's authors never notice.