6.4 Design Blueprints & Learning Assets: Storyboards, Wireframes, Prototypes & Mock-Ups

Why the Blueprint Stage Decides the Budget

The CPTD content outline separates two skills that practitioners often blur together: designing blueprints, schematics, and other visual representations of a learning solution, and designing and developing the learning assets themselves. The separation matters commercially. Every hour of rework is cheap while the solution exists only as a document and expensive once it exists as media. A sequencing error caught on a storyboard costs a comment and a redraft; the same error caught after voice-over recording, animation, and localization into six languages costs weeks and a vendor change order.

This is also where stakeholder expectations are managed. A subject matter expert who first sees a solution as a finished module will review it as a critic. The same expert who reviews a storyboard reviews it as a collaborator, because the artifact visibly invites change.

The Three Blueprint Artifacts

1. The Design Document (The Contract)

The design document is the agreement that everything downstream is measured against. It is written before any screen exists and is signed off by the business sponsor, not just the project team. A usable design document states:

• Business and performance problem being addressed, with the metric that will move.
• Audience profile: roles, prior knowledge, language, access constraints, and where the learning will happen.
• Terminal and enabling objectives, written as performance statements.
• Modality and rationale: why this mix of instructor-led, digital, on-the-job, and coaching, and what was rejected.
• Assessment strategy: how mastery will be evidenced, and at which Kirkpatrick level the programme will be evaluated.
• Duration, seat-time budget, and constraints: compliance deadlines, system dependencies, release windows.
• Out of scope: the single most valuable section, because it is the one referenced when scope creep begins.

2. The Storyboard (The Screen-Level Specification)

A storyboard specifies, for each screen or segment: on-screen text, narration script, visual or media asset, interaction type, navigation logic, and the objective the screen serves. Adding an explicit objective column is the discipline that catches padding — any row that cannot name an objective is a candidate for deletion.

Storyboards are usually produced in a document or slide tool precisely because the format signals "not final." Practitioners who storyboard inside the authoring tool lose that signal and invite premature reviews of typography instead of instruction.

3. The Wireframe (The Structural Schematic)

A wireframe answers a different question than a storyboard. Where a storyboard asks what is taught here and how, a wireframe asks how is this organized and navigated. Wireframes are deliberately unstyled — greyscale boxes, placeholder text — because visual polish at this stage pulls review comments toward colour and away from architecture. They are the right artifact for a curriculum portal, an LXP landing experience, a performance-support site, or any solution where findability is the design problem.

Prototype Fidelity: Raise It Only As Uncertainty Falls

Fidelity is a cost decision, not a quality decision. The governing rule is that fidelity should rise only as uncertainty falls.

• Low fidelity (paper, slides, greyscale wireframes) is the correct choice when the sequence, the scenario logic, or the branching structure is still in question. It is fast enough to throw away, which is the point — cheap artifacts get honest feedback because no one is protecting sunk effort.
• Medium fidelity (clickable wireframes, a single built module) is the right stage for testing navigation and interaction with real users.
• High fidelity (production media, final styling, recorded narration) is justified only once the instructional approach is settled, because this is where cost concentrates.

The classic failure is inverted: a team builds one beautifully finished module to "show what it will look like," the sponsor approves the look, and the underlying instructional sequence is never tested at all.

The Learning Asset Library

The content outline lists role plays, self-assessments, training manuals, job aids, and visual aids as examples of the assets a CPTD designs or develops. Each has a job it does better than the others.

The Job Aid Decision

A job aid is not a supplement to training — it is frequently a replacement for it, and choosing correctly between them is a recurring CPTD scenario. Favour a job aid when the task is performed rarely, has many steps, must follow an exact sequence, changes often, or carries a high cost of error. Favour training when the task is frequent, must be performed fluently without reference, or requires judgment that cannot be reduced to steps. A well-designed job aid is used during the task, at the workstation, in the workflow — not filed in an LMS.

The Traceability Rule

Every asset must trace to an objective. In practice this means maintaining a simple map: objective, the asset that teaches it, the asset that supports it on the job, and the assessment that evidences it. The map makes two problems visible immediately — objectives with no supporting asset, and assets serving no objective. The second is where budget quietly disappears.

Exam Trap: Scenarios that describe a beautiful finished module which learners cannot navigate, or a large asset library that nobody can map to an outcome, are testing whether you reach for the blueprint stage rather than for more production. The corrective action is almost always to go back to the design document and the objective map, not forward to more media.