Learning objectives generator

How to use the generator

1. Audience. Who will do it: “new developers on the team”, “first-year apprentices”, “support agents in their first month”. Specific enough that the objective couldn’t be pasted into another course.
2. Bloom’s level and verb. Pick the kind of thinking the lesson asks for, then one verb from that level. The verb is the part someone could watch or check.
3. Behaviour. Finish the verb: what exactly will they trace, explain or build?
4. Condition and degree. What will they have to hand, and how well will they do it? Both are optional; the generator warns when they’re missing but doesn’t insist.
5. Collect or check. Add each objective to your list and download it as Markdown, or switch to Check yours and paste the objectives you already have, one per line.

What makes a learning objective measurable

A learning objective says what learners will be able to do at the end of a lesson, not what the lesson covers. It’s measurable when two people watching the same learner would agree whether it was met. That rules out verbs for a state of mind: you can’t see someone “understand” or “appreciate” something. You can see them explain it, use it, or spot what’s wrong with it.

The ABCD format makes that concrete. It builds on Robert Mager’s performance objectives (Preparing Instructional Objectives, 1962), which ask for a performance, its conditions and a criterion:

• Audience: who will do it.
• Behaviour: what they will do, as an observable verb and its object.
• Condition: the circumstances, tools or information they’ll have.
• Degree: how well, how fast or how many, so everyone knows when it’s met.

Put together: “By the end of this lesson, new developers on the team will be able to trace the failure to the line of code that causes it, given a failing test, in under 10 minutes.” Anyone can check that one, including the learner.

Bloom’s taxonomy verbs by level

The levels follow the revised Bloom’s taxonomy (Anderson & Krathwohl, 2001), which renamed the original categories (Bloom and colleagues, 1956) as verbs and put Create at the top. They run from recalling facts to making something new. A lesson doesn’t have to reach the top: an onboarding session can rightly stop at Apply.

Each verb appears once here, so the checker can name a level from it. In practice some verbs move between levels with the task: comparing two sorting algorithms by their running time asks for more analysis than comparing two words. Treat the level as a clue, and judge by what the learner actually has to do.

Verbs to avoid, and what to write instead

Understand, know, learn, appreciate, be aware of, be familiar with, grasp, comprehend, realise, recognise the importance of, gain an understanding of. They describe something happening inside the learner’s head. Keep the intention and ask what they would do that shows it:

• “Understand how Git branches work” becomes “Explain what happens to each branch in a merge, using a diagram of the commits.”
• “Know the main HTTP status codes” becomes “Name the status code for five common responses, without notes.”
• “Appreciate the importance of code review” becomes “Critique a pull request against the team’s checklist, with at least three specific comments.”

Examples for technical training

• Onboarding (Apply): “Run the project’s test suite locally, given a fresh clone of the repository, in under 15 minutes.”
• Bootcamp (Create): “Build a REST endpoint that returns products as JSON, using Express, so that all the provided tests pass.”
• Data course (Analyse): “Diagnose why a SQL query is slow, using its query plan, in under 15 minutes.”
• Code review workshop (Evaluate): “Given two pull requests that fix the same bug, recommend one, with a reason that refers to the team’s coding standards.”
• Security basics (Remember): “Recognise a SQL injection in a code sample, given five short snippets, without notes.”

Common mistakes

• Describing the lesson, not the learner. “This workshop covers accessibility basics” is a topic list. Say what learners will do with it.
• Two objectives in one. “Explain and implement a binary search”: if they can explain it but not implement it, was the objective met? Split it.
• A vague verb behind a good one. In “demonstrate an understanding of”, demonstrate is fine; an understanding isn’t something you can watch.
• A verb the lesson can’t deliver. An hour-long introduction that promises learners will design a system. Match the verb to what the lesson gives them time to practise.
• No way to check. If nothing in the lesson asks learners to do the verb, you won’t know whether it was met. A question built around the objective is the simplest check: the multiple-choice question checker helps you write one that shows what was misunderstood.

Once the objectives are written, give each lesson one in the course outline builder and see the whole course with its timings.

How the checker decides

It reads the verb the behaviour starts with (after “will be able to”, or the first word of a line), and looks it up in the table above; American spellings work too. It flags vague verbs anywhere in the sentence, a second verb joined by “and” or “then”, and sentences over 40 words. Conditions and degrees are guessed from wording such as “given”, “using”, numbers and “without errors”, so treat those warnings as prompts, not errors.