The same content can live in multiple schemes
Aliases: polyhierarchy · cross-classification · multiple access paths
What it is
An item does not have to live in only one tree. The same “travel expense guide” can sit under Finance by topic, under Trip prep by task, and under This year’s policy by time—three schemes at once. Multiple organization schemes does not mean mashing three logics into one menu layer. It means giving the same object several legal entry paths. A single tree that forces one “correct” slot discards the other two clues the person may be holding.
Coexistence is not a giant navigation that lists every entrance. Each scheme remains a complete, coherent system; the object is simply attached more than once. Which scheme a person walks depends on the clue in hand at that moment.
Why it happens
People search with whatever clue is currently available. Those who remember the topic walk the topic tree; those who remember what they were doing walk the task tree; those who remember “it went out last month” walk time. A single tree turns the other two clues into dead information: the clue is still in memory, the system offers no matching axis, and the person must translate known information into the architect’s chosen kind. Failed translation looks like random clicking, a switch to search, or a conviction that the content does not exist.
Technically this is usually one store, many attachments: several parents, several label sets, or several facet values. Cognitively it is an admission that we do not know which clue will be brought. Forcing a unique location saves the storage diagram and dumps translation cost onto every lookup.
Studying it
Compare single-entrance against multi-entrance lookup under different clue conditions; do not ask whether people “like” having several classifications.
- Paradigms: the same collection, one group restricted to a topic tree, another able to use topic or task or time; scripts that supply only a topic clue, only a task clue, or only a time clue.
- Independent variables: number and kind of available axes, whether the UI lets people switch axes, consistency of the object’s labels across axes.
- Dependent variables: success when the clue matches the axis and when it does not, rate of switching to search, and whether people realize another walk exists.
- Methodological note: if the lab writes all three clues into the task, single-tree performance is overestimated because participants can do the translation themselves. Real lookup often has one clue left. Logs and interviews should ask “what did you remember about it then,” not only whether it was found.
Where it stops holding
On a tiny collection (a dozen items) multiple schemes create a sense of duplication whose browsing cost exceeds translation cost. Where regulated records require “one file, one number,” what coexists are retrieval entrances, not the official filing location—and the authoritative location must be named. If schemes are mixed in one navigation layer (Finance next to Trip prep next to 2024), people read them as one broken classification and coexistence has failed. Contradictory names for the same object across axes turn many entrances into many places not to find it.
Applying it
- List the clue types people actually bring. Give each type a complete axis; do not pack them into one menu layer.
- After attaching an object on each axis, spot-check that every axis reaches the same object and that titles still match.
- Feature one or two of the most-used axes in primary navigation; put the rest in filters, related links, or search to avoid overloading the chrome.
- Verify with three scripts that supply only topic, only task, or only time. Each should arrive without translation. If a clue type can be rescued only by search, that scheme was never built—it was only said to “be allowed to coexist.”
Related
- Within the group: G1.02.1 Exact schemes (alphabetical, chronological, geographical) have one right place · G1.02.2 Ambiguous schemes (topic, task, audience) depend on judgment · G1.02.4 The scheme depends on what the user already knows
- Adjacent: G1.06 Faceted classification · G1.09 Types of organizational structures · G3.10 Faceted navigation
- Search terms:
multiple organization schemes·polyhierarchy·cross-classification