13 Rules for a Gold-Standard HLDD

A High-Level Design Document is the contract between an instructional designer and everyone else who touches a course. When it’s good, the storyboard artist, the developer, the SME, and the project manager all agree on what they’re building before anyone touches a tool. When it’s bad, the disagreements emerge three weeks into production and the budget melts.

After running a gap analysis on three reference-grade HLDDs, the kind that produce courses that ship on time, I distilled thirteen rules. They’re uneven in scope on purpose. Some are structural, some are about scope discipline, and some are about the small disciplines that separate an excellent document from a competent one.

1. One performance gap, named in the first paragraph. Not three, and not “a range of needs.”
2. Audience defined by what they currently do, not what they are. Job titles are a poor proxy for current behavior.
3. Learning objectives in Mager format. Behavior, condition, criterion. No exceptions.
4. Every objective traces to an assessment item. If you can’t test it, it’s not an objective.
5. Every assessment item traces to a learning activity. If they can’t practice it, you can’t test it.
6. Module count justified, not assumed. Three is not a default.
7. Section count regime declared. Same number of sections per module, or an explicit reason why not.
8. Branching scenarios specified at the structural level, not left for storyboard.
9. Interactivity types named per section, with frequency budget.
10. Media decisions made, not deferred. “TBD” in an HLDD is a future fight.
11. Accessibility decisions explicit. WCAG level, captions, audio descriptions, keyboard nav, all stated up front.
12. Out of scope, written down. The unspoken assumptions are what kill projects.
13. Acceptance criteria for the build phase, named and measurable. Not “looks polished.”

Every one of these came from watching a project go wrong because the rule was missing.