Authoring and piloting a new training approach for the cloud version of a federal forensic DNA system, built for roughly 2,500 analysts nationwide, and designed to replace a legacy system that duplicated content instead of teaching it.
Audience: Internal instructional design team; end users are approximately 2,500 forensic DNA analysts and administrators nationwide
Responsibilities: Instructional Design, Curriculum Architecture, Systems Thinking, Visual Design, Team Enablement
Tools: Storyline (eLearning, microlearning, software simulations), Snagit (demo videos), PowerPoint (job aids, decision guide)
The Problem
The legacy training system for a large software system consisted of 46 computer-based training modules. It did have a logic to it, just the wrong one: content was distributed equally, feature by feature, and each CBT reproduced the Help system almost verbatim, including software rules, error messages, and field definitions. The result wasn't training so much as a duplicate of a reference manual delivered in module form. There was no distinction between content someone needed to understand, content they needed to do, and content they just needed to look up when the moment called for it.
That legacy system is now being replaced entirely. The organization is migrating from a classic version of the software to a new cloud version, with a four-year transition window, and rather than carrying the old approach forward, my team (nearly doubled from 4 to 6 people specifically to take this on) is authoring and piloting a new training approach from the ground up for the cloud system.
The Solution
Two connected pieces of work. First, a content-format decision guide and reference table that forces a real distinction between concepts, tasks, and reference material — replacing "one feature, one CBT" with "the right format for what this content actually is." Second, and built on top of that logic, a curriculum map for the new cloud ecosystem, structured around how users actually encounter the system rather than how the software happens to be organized internally.
Process
The decision guide went through real iteration before any of this curriculum work began, from an early linear, zigzag layout to a three-branch parallel tree after a teammate's feedback surfaced that format decisions branch by content type rather than following one path.
With that framework in hand, I designed a curriculum map that splits into two layers: an onboarding package — a "what's new from classic to cloud" microlearning piece plus a navigation-basics demo video, aimed at reorienting existing analysts rather than re-teaching them the whole system — and function-specific packages, each built from one microlearning concept lesson, one software simulation, two videos (an intro to that function's UI and a "common errors and how to solve them" walkthrough), and 2-3 job aids. I also laid out separate learning pathways for analysts and administrators, since the two roles touch the system differently, and proposed a model for producing on-demand training products based on ongoing user analytics — so the curriculum keeps evolving after launch instead of going stale the way the legacy system did.
Early handwritten thoughts
First decision chart - hard to follow, missing nuances
Outcome (in progress)
This work is live, not retrospective, and I'm currently the sole team member developing the cloud curriculum, while the rest of the team maintains and updates the existing classic system in parallel. I built the curriculum map shell independently and presented it to my team lead and the broader team, who responded well to the function-specific package model. We are now moving forward with that approach, and I'm detailing it further for one of the core software functions specifically. That detailed curriculum is the next step before it goes to leadership, and eventually the client, for approval; once approved, prototypes will follow the same review chain.
Applying the decision guide to specimen data entry, one of the system's core functions, split its content into concepts, tasks, and reference material, and produced a deliverable mix of one CBT, five short demo videos, and three job aids, in place of what the legacy approach would have made a single long-form module. That's the model now shaping the curriculum map I'm building for the rest of the system: a smaller, more varied, more purpose-built library replacing 46 modules that were solving the wrong problem well.
What I Took Away
The legacy system's real flaw was a reasonable-looking rule applied without asking what content actually needed. That's the throughline of this whole project: design influence, at any scale, starts with asking whether the existing logic serves the needs of the learner. Rebuilding the framework from the format level up, and then using it myself to architect an entire curriculum, has been the real test of whether the thinking holds at scale, and so far, it's shaping decisions I wouldn't have made under the old model.