A web app I built to replace the 30-minute write-up an instructional designer does at the start of every project. You give it a topic, a target role, an industry, and how many learning objectives you need, and it returns them in Mager format, tagged with Miller's level and 70-20-10 placement, ready to export to Word or Excel.
Writing learning objectives is one of those jobs that feels simple until you’re doing it for the fourth time in a week. Every instructional designer knows the shape: Behavior plus Condition plus Criterion, tagged to the right Miller level, placed inside the 70-20-10 rhythm. But doing it from scratch, cleanly, for a new topic, still eats thirty minutes a time. I built the Learning Objectives Generator to get that thirty minutes back.
What I built
A small, focused web app with one job. A form asks for five things: topic, target role, industry, desired LO count (3 to 7), and an optional context paragraph. One button sends it, and the pipeline does the rest.
The pipeline. The topic and context get wrapped in an instructional-design system prompt and sent to the Claude API (Sonnet 4). The system prompt encodes the Mager format strictly, forces each objective to be mapped to a Miller’s Pyramid level (Knows, Knows How, Shows How, Does), and assigns each objective to a 70-20-10 placement (on-the-job experience, social learning, formal learning). The model returns structured JSON; the server parses it, validates the shape, and hands it to the export layer.
The export layer. Two formats, one click each. A Word export using the docx library that drops the objectives into a template L&D teams already use. An Excel export using exceljs that keeps the column headers and data types clean so downstream tools (LMS imports, competency trackers) can pick it up without reshaping.
Dynamic count logic. I originally shipped it fixed at 7 objectives per set. Early users wanted flexibility, so I added user-selectable 3 to 7 with dynamic prompt logic: if the user asks for 7, the prompt instructs the model to expand the topic further into adjacent sub-skills. If they ask for 3, the prompt instructs the model to cover only the main pillars concisely. The model stayed the same; the change in framing alone made the output much better.
Why a standalone web app, not Copilot Studio
I built this as a standalone Node app specifically because the output needed to leave the Microsoft 365 environment and land in Word and Excel files that anyone, client or contractor, could open without a license. Copilot Studio would have added unnecessary complexity around file generation, and Power Automate would have added latency to every run. A Node server with two export libraries was cleaner, faster, and easier to maintain.
What it improved
The thirty minutes became ninety seconds, which is a 95% time reduction and doesn’t look special until you multiply it by every new program design in a quarter. For a team running twenty programs a year, that’s ten hours of instructional-designer time reclaimed from an activity that was never the point. The LO quality didn’t drop, and the format discipline went up, because the model has zero tolerance for sloppy Mager phrasing when the system prompt enforces it, and the exports landed ready for the next step in the pipeline instead of requiring a reformatting pass.
It’s the kind of tool I build when I notice myself doing the same thirty-minute job twice in a week. My test is whether I ever want to do the manual version again. With this one, I don’t.