Developing
Choose your build path and get to the right guide. Each path produces the same deliverables with workplace simulation built in.
What you need before starting
Confirm the Planning handoff package is complete:
- Module title and UCI code
- 3–5 learning objectives with Bloom verbs
- Assessment strategy and success criteria
- Activity breakdown with durations
- Simulation frame and workplace context
- Source materials and references
What you need to produce
Per module: blueprint, lessons, slides, labs, KBAs/SBAs, facilitator guide. Simulation context must appear in materials; naming must follow conventions.
Choose your development path
Custom Development
Build lessons, slides, labs, and assessments from scratch using our workplace simulation methodology.
Vendor Development
Adapt third-party content (like CompTIA, Schneider) into our Workplace Simulation methodology.
How hybrid development works
When to use hybrid: Your course has some modules where vendor content is instructionally solid and just needs adaptation, and other modules where no suitable source exists and you need to build from scratch.
How it works:
- During Planning, tag each module as Custom or Vendor in the module list.
- For vendor-tagged modules, follow the Vendor Development workflow (audit, adapt, reframe).
- For custom-tagged modules, follow the Custom Development workflow (build from scratch).
- Both types go through the same QA process. The QA reviewer should know which modules are vendor-adapted vs. custom-built since the review focus differs (adaptation quality vs. original quality).
- The module blueprint and facilitator guide are required for every module regardless of path.
Common hybrid mistakes:
- Treating vendor-adapted modules as “done” without adding simulation framing or workplace scenarios.
- Applying custom-level effort to modules that already have solid vendor content, wasting time.
- Inconsistent naming: vendor modules should still follow the same prefix and numbering conventions as custom ones.
Content quality checklist
Before moving to QA, run this self-check. If you can’t check every box, the module isn’t ready.
Content quality checklist
- Does every lab have a workplace scenario framing? (Not “configure X” but “Client ticket: …”)
- Is there a mix of formative and summative assessments? (Not just a KBA at the end)
- Does the module use at least 2 different content formats? (Not just slides + lab)
- Are discussions (DISC) or case studies (CS) included where appropriate?
- Is the 75% activated learning target achievable with this content?
- Does the naming follow conventions? (Prefix + module.lesson.number, R- for graded)
- Is the facilitator guide actionable? (Tells the instructor what to do, not just what to know)
See Non-Negotiables & Standards for the full rules, worked examples by content area, and bad-vs-good comparisons.
Exit criteria
Development is complete when: all required assets are built; naming is correct; links work; facilitator guidance exists; simulation context appears in materials; self-QA is done.
Common mistakes
- Building without a complete planning handoff.
- Simulation context pasted in once but not affecting tasks.
- Choosing the wrong path (custom vs vendor) so the team builds the wrong way.
Related tools/templates
- Custom Development — naming, lab/SBA structure, Companion
- Vendor Development — adaptation checklist
- Deliverables — templates and examples
- QA — worksheet and submission
Next step
Quality Assurance — Run self-review, complete the QA worksheet, and submit for review.