My first year of teaching came with a problem I didn’t expect. Quarterly exams were coming up, and I needed test items that matched what I’d covered in class. Not close to it. Matched it.
That sounds simple. It wasn’t. I kept catching myself writing questions that tested things I’d mentioned in passing, while topics I’d spent three days on barely showed up on the test. I needed a way to check my own work before the exam went out, not after the scores came back.
That’s what led me to the Table of Specifications and, through it, to Bloom’s Taxonomy.
The Table of Specifications did the boring part well
A Table of Specifications is a test blueprint. You map your topics against your test items in a grid, and it shows you where you’re overloading one area and skipping another. Nothing clever about it. It’s a checklist, and I needed a checklist.
What it couldn’t do on its own was tell me what kind of thinking each question was asking for. I could balance the topics perfectly and still end up with thirty recall questions. That’s where Bloom’s came in.
I’d learned Bloom’s as a requirement, not a tool
I’ll be honest about where I started. In my education courses, Bloom’s Taxonomy was something you cited in a lesson plan template. Fill in the verb, move on. I didn’t connect it to anything I actually did in a classroom, so my objectives stayed flat. Lots of “define,” “identify,” “recall.” Nothing wrong with those verbs, but that’s all I had.
Writing real test items changed that. I started noticing that a vague objective produced a vague question, every time. If I couldn’t tell from the objective what a student should be able to do, I couldn’t write a fair test item for it either.
A before-and-after that made the difference visible
Here’s the objective I used to write for a lesson on the Cold War:
“Mauunawaan ng mga mag-aaral ang mga pangunahing pangyayari sa Cold War.” (Students will understand the major events of the Cold War.)
Reads fine. Sounds like a normal objective. But “understand” doesn’t tell me, or the students, what they need to produce. It doesn’t tell me what to test.
After running it through Bloom’s levels, I rewrote it as:
“Susuriin ng mga mag-aaral ang mga sanhi at bunga ng mga pangunahing kaganapan sa Cold War at ang epekto nito sa modernong lipunan.” (Students will analyze the causes and effects of major Cold War events and their impact on modern society.)
That one word change, from “understand” to “analyze,” changed the whole lesson. Discussions shifted from students repeating dates and names to students explaining why one event led to another. I noticed the difference in how they talked, not just what they wrote on the test.
Where this shows up in my instructional design work now
I still lean on this when I write objectives for corporate training or eLearning modules. The temptation to write “learners will understand the process” doesn’t go away just because the audience changed from high schoolers to adult professionals. It’s the same vague verb wearing a different outfit.
Instead, I push toward objectives that ask learners to analyze a scenario, evaluate a decision, or propose a fix based on a case. Those verbs force the design to change too. You can’t build a multiple-choice quiz for “evaluate.” You need a scenario, a decision point, something with stakes.
The lesson I keep coming back to
Bloom’s Taxonomy isn’t a form you fill out to check a compliance box. It’s a way to catch vague thinking before it turns into a vague course. The Table of Specifications keeps the content balanced. Bloom’s keeps the thinking honest.
If you’re writing an objective right now, try this test: could you write a test question for it without guessing what the learner is supposed to do? If not, the objective needs another pass, not the question.
What’s the vaguest objective you’ve caught yourself writing recently, and what verb fixed it?