The Conventional Wisdom
Records managers often see classification scheme design as a technical exercise with right and wrong answers. We've built a rigid framework around non-variable terms, functional classification, and hierarchical logic that "proven practices" demand. When project managers ask for a filing structure that starts with project names and drills down to stages, we explain why that's technically inferior. When they build exactly that structure on their shared drives anyway, we blame user resistance and poor change management.
The profession has convinced itself that low adoption rates, systematic control of records between 10 and 20%, stem from insufficient training or weak executive sponsorship. We rarely question whether the classification schemes themselves might be the problem.
Why It's Incomplete
This orthodoxy confuses structural elegance with effectiveness. A classification scheme that satisfies records management principles but drives users to shadow systems hasn't solved anything. It's failed at the only metric that matters: getting information under systematic control.
Consider how project managers actually think about their work. They organize around projects first, then stages within each project. Every project management software vendor builds their tools this way, project name at the top level, stages nested underneath. These vendors conducted user research, ran usability tests, and optimized for adoption. They didn't accidentally converge on the same structure.
Yet records managers insist on inverting that hierarchy: stage first, project name second. We argue this approach limits the number of top-level folders and prevents unlimited proliferation of project containers. Those arguments are technically sound. They're also academic when project managers refuse to use what we've built.
The disconnect reveals a deeper problem. We've prioritized our convenience and our vendors' database constraints over the people who actually need to file records. We've mistaken "proven practice" for "effective practice."
The Evidence
Look at how Woolworths organizes its stores. Their classification scheme violates every principle of logical consistency. Coke sits in "drinks" with 180kJ/100ml. Monster energy drink lives in "energy drinks" with 9kJ/100ml. Milk, also a drink, appears in the dairy section at 247kJ/100ml. Orange juice, a subset of drinks, occupies its own "juice" section at 180kJ/100ml.
By any taxonomic standard, this is terrible classification. Energy content doesn't predict location. Broader and narrower terms mix freely. The hierarchy serves no logical purpose.
Woolworths organizes this way because it's effective. They've tested customer behavior and optimized for what gets people to find products and complete purchases. Their goal isn't elegant taxonomy, it's sales. They've chosen effectiveness over correctness.
Records management should make the same choice. Our goal isn't beautiful classification schemes. It's systematic control of information. If a "terrible" classification practice drives usage up, it's better than "proven practice" that drives usage down.
The current approach clearly isn't working. When users implement their own classification schemes on file servers, schemes that make sense to them and that they actually use, we should pay attention. They're telling us what works.
What to Do Instead
Start with user research, not records management principles. Before you design a classification scheme, watch how people currently organize information. What structures do they build when given freedom? What mental models drive their filing decisions? Where do they go when your official system frustrates them?
Interview the people who will use the system. Ask project managers how they think about their work. Ask legal teams how they organize matter files. Ask HR how they conceptualize employee records. Don't explain why their preferences are wrong, learn from them.
Then design for adoption first, technical correctness second. If project managers want project name → stages, give them that structure. If it means variable terms above non-variable ones, accept that trade-off. You can't apply retention rules or disposition authorities to records that never enter the system.
Test your schemes before full deployment. Pilot with real users doing real work. Measure usage, not just compliance with design principles. If people route around your scheme, that's data. If they complain it doesn't match how they think, listen.
Be willing to back out "proven practices" that fail in practice. If usage drops after you implement a technically superior classification, revert. Your ego isn't more important than systematic control.
Document the trade-offs you're making. Explain to auditors and stakeholders why you chose user adoption over structural purity. Most will understand that a simple scheme people actually use beats an elegant scheme they ignore.
When Conventional Wisdom Is Right
Traditional classification principles still matter in specific contexts. When you're building archives that need to serve researchers decades from now, functional classification and stable hierarchies become more important than immediate user convenience. Archivists can't interview the original users, so they need structures that make sense without that context.
For regulatory compliance in heavily prescribed industries, you may have no choice. If a sector-specific standard mandates particular classification approaches, you implement those approaches regardless of user preference.
And sometimes users are simply wrong about what will work at scale. A classification scheme that feels intuitive for a team of five might collapse under the weight of fifty projects. Your expertise in information architecture still matters, just not more than user adoption.
The key is knowing which scenario you're in. If you're designing for current users doing current work, optimize for their mental models. If you're building for long-term preservation or regulatory mandate, other principles take precedence.
But for most records managers most of the time, the iron rule should be simple: do what gets people using what you've built. Everything else is secondary.
