Structure a question bank around the thing that changes least. For most degree programs, that is the subject, not the module code and not the academic year. Then use tags for everything that varies: level, topic, skill, the year it was last used. Hierarchy decides who owns an item. Tags decide who can find it.
That distinction is the whole job. Almost every unusable bank got it the wrong way round.
Why does a question bank stop being usable?
Not on the day it is built. A new bank is always tidy because one person made every decision that week and still remembers them all.
It fails around year three, and it fails in a recognizable way:
- Nobody can find an item without already knowing where it is.
- The same question exists three times, in slightly different words, written by three people who each searched and found nothing.
- Half the folders are named after a member of staff who left, or a module that was renumbered.
- Nobody is sure which version of an item was the one actually used last year.
None of that is a software problem. It is the compounding cost of a structure that made sense to one person for one year, applied to a program that runs for a decade.
The cost is real, and it lands on assessment quality. When finding an existing item is harder than writing a new one, staff write a new one. The bank grows without improving, item statistics scatter across near-duplicates, and nothing accumulates enough evidence to be worth trusting.
What should the top level be?
This is the decision everything else inherits, so it is worth arguing about properly.
The candidates are usually subject or discipline, module or course code, academic year or cohort, and the person who wrote the items. Only the first is a good answer.
Module codes change. They get renumbered, merged, split, and retired, often for administrative reasons unrelated to content. A bank keyed to module codes needs to be restructured every time the curriculum committee tidies something up.
Academic years are worse. They guarantee that the structure will grow forever and that a good item written in 2023 will be invisible to whoever teaches the subject in 2027. Anything organized by year is a filing system for the past, not a bank.
People leave. A top-level named after whoever wrote the items becomes unmaintainable the moment they do.
Subject survives all of that. Cardiovascular physiology will still be cardiovascular physiology after the module has been renumbered twice and its author has retired.
How deep should the hierarchy go?
Shallower than you want it to be. Two levels is usually right; three is the practical limit.
Every level you add is a decision someone has to make correctly when filing an item, and correctly again when looking for one. Those two people are often not the same person and often disagree. A five-level tree does not organize a bank; it just creates five chances to guess wrong.
The rule that keeps this simple:
Hierarchy is for ownership. Tags are for retrieval.
If a property is something an item belongs to (one place, exclusively, with someone accountable for it), it belongs in the hierarchy. If a property is something an item is, and it could sensibly have several of them, it belongs in a tag.
By that test, subject is hierarchy. Difficulty, topic, clinical skill, question format, the year last used, and the curriculum outcome are all tags. An item can be of intermediate difficulty, focus on arrhythmias, and be mapped to two learning outcomes. None of those can be a folder without forcing a false choice.
One practical consequence worth knowing before you design a deep tree: structure resists being unpicked later. StudyDrome Exam Manager will not delete a bank that still has child banks under it, and most systems have a similar guard. Nesting is easy to create and tedious to undo.
Who owns an item?
Ownership is a different question from access, and mixing them up causes most of the arguments.
Access is who can see and edit — a permissions question, and every serious system has controls for it. Ownership is who is accountable for ensuring an item is correct, current, and defensible if challenged. Software cannot answer that one.
The rule worth writing down: every branch of the hierarchy has a named owner, and that name is a role, not a person. "Subject lead, cardiovascular" survives staff turnover. "Dr Ahmed" does not.
Do this at the point the branch is created. Retrofitting ownership onto a bank that has run for three years means someone has to go and ask about items nobody remembers writing.
What has to be true before an item goes in?
A bank is only as trustworthy as its weakest intake rule. Agree the standard once, write it down, and apply it to everything.
A workable minimum has four parts. The item has been reviewed by somebody other than its author. It is tagged. It maps to a learning outcome. It meets your item-quality standard. Most of the damage in real banks comes from avoidable item flaws rather than from bad structure. An item filed correctly is still flawed if it was flawed when written.
Decide the question format at intake, too. An item that only works as an extended matching set, or that needs a shared case, has different reuse properties from a standalone question — which is worth knowing before it is buried three levels down. The question types available to you shape what a good bank looks like.
How do you keep it usable in year three?
By treating the bank as something to be maintained, not something to be filled.
Review on a cycle, not on complaint. Every item is reviewed on a fixed schedule. Without one, the only items ever reviewed are the ones a candidate challenged.
Retire deliberately. An item that has been exposed too often, or that tests something no longer taught, should be marked as retired rather than deleted. Deleting it destroys the history that explains a past result. Exposure is also something you choose: if candidates are shown the correct answers after a sitting, those items are spent, which is why what you disclose after an exam and what you retire are one decision.
Let the statistics do the triage. Items accumulate performance data every time they are used, and that data tells you which ones to look at first. The complete guide to item analysis covers how to read it. The point here is structural: statistics only accumulate if the same item is reused rather than rewritten, which is the payoff for a bank people can actually search.
Expect no help with duplicates. Assume nothing will warn you that an item already exists in different words. The defense is procedural — search before you write, and make review the step where a familiar-looking item gets caught
A structure checklist
Decision | The question to settle | A default that ages well |
|---|---|---|
Top level | What changes least in our program? | Subject or discipline |
Depth | How many filing decisions are we asking for? | Two levels, three at most |
Hierarchy vs tags | Does an item belong here, or is it merely this? | Belongs to one place → hierarchy. Could be several → tag |
Tag vocabulary | Who is allowed to invent a new tag? | A fixed list, extended deliberately, not by anyone typing |
Ownership | Which role is accountable for this branch? | A named role, recorded when the branch is created |
Intake standard | What must be true before an item is filed? | Reviewed by a second person, tagged, mapped to an outcome |
Review cycle | When does an item get looked at again? | A fixed schedule, not on complaint |
Retirement | What happens to an item we stop using? | Marked retired, never deleted |
Reuse | Can two exams draw the same item? | Decide it explicitly, before the first clash |
Frequently asked questions
How should you organize questions in a question bank?
Put the slowest-changing property at the top, usually subject or discipline, and keep the tree shallow, at two or three levels. Everything that varies goes in tags: difficulty, topic, skill, curriculum outcome, the year last used. The test is whether an item belongs to one place exclusively, or merely has that property. Belonging is hierarchy. Having is a tag.
Should a question bank be organized by subject or by module?
By subject, in almost every case. Module codes are renumbered, merged, and retired for administrative reasons, and each change requires restructuring work unrelated to content. Subjects outlast all of it. If you need to see the items for a module, that is a tag or a saved search over a subject-based bank, not a folder.
What is the difference between a folder and a tag in a question bank?
A folder is exclusive: an item sits in one, and that placement usually decides who owns and can edit it. A tag is additive: an item can carry many, and they exist so people can find it. Use folders for accountability and tags for retrieval. Problems start when a property that could reasonably take several values gets turned into a folder.
When should you retire an exam question?
When it no longer tests something you teach, when it has been used often enough that exposure is a real risk, or when its statistics say it is not doing its job. Mark, it is retired rather than deleted. A deleted item takes with it the record of what a past cohort actually sat. That record is exactly what you need if a result is challenged.
How do you stop the same question being written twice?
Mostly by process, not by software. Do not assume a system will notice that an item already exists in slightly different words. Make searching the bank a required step before writing, keep the tag vocabulary small enough that searches actually work, and use second-person review as the point at which a familiar-looking item is recognized.
Can the same question be used in more than one exam?
Usually yes, and that is the point of a bank rather than a set of papers. It does need a deliberate decision, because reuse across a cohort that talks to itself is an exposure risk. Agree a rule about how often an item may appear and across which exams, and write it down before two people discover the clash by accident.
Where to go next
If you are restructuring an existing bank rather than starting one, the decisions above still apply — but do them before you move anything, not after. The structure you arrive in is the structure you will live with.
Structure decides where an item lives. Access decides who can reach it, which is a different question with a different answer — see question banks, sub-banks and who can open them.
Retrieval is the third question, and it is the one tags exist for. What tagging is actually for covers tag dimensions, the tag tree and the clinical-skills library — and who reads them once they are set.
How a bank becomes a paper is a separate problem with its own trade-offs, covered in written exams. And the quality of what goes in matters more than any of this: a well-organized bank of flawed items is still a bank of flawed items.