Course Creator Dashboard Requirements: Authoring, Publishing and Learning Operations

A course dashboard is successful when an instructor can turn a learning objective into a published, accessible course and then understand where learners struggle. A grid of upload buttons and revenue charts does not accomplish that job.

The core workflow crosses curriculum structure, drafts, media processing, captions, assessments, prerequisites, pricing, review, versioning, enrolment, communication, analytics and support. If these states are collapsed, edits can break active learners, analytics lose meaning, and creators cannot explain what changed.

This guide defines a complete first-release dashboard around one course lifecycle. It distinguishes useful learning evidence from vanity engagement and gives product, design, engineering and operations teams concrete acceptance criteria.

Start with a curriculum map

Creators need to see outcomes, modules, lessons and assessments as one coherent path.

The failure mode is concrete: content becomes an unordered file library. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, make course structure and learning outcomes the primary authoring surface. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include module order, lesson type, objective, estimated effort, prerequisite and completion rule. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with reorder, missing objective, locked lesson and active learner. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: learning product lead
• Release evidence: curriculum acceptance sample
• Stop condition: a published lesson has no place in the learning path

Use explicit draft states

Authoring, review, scheduled publishing and live content require different authority.

The failure mode is concrete: every save changes the learner experience immediately. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, separate working draft from approved and published versions. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include editor, reviewer, status, scheduled time, change summary and version. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with concurrent edit, rejected review, schedule change and rollback. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: content operations
• Release evidence: publication state tests
• Stop condition: an unreviewed save reaches learners

Build structured lesson editing

Text, video, files, activities and embeds need consistent blocks rather than arbitrary markup.

The failure mode is concrete: pasted content breaks accessibility and mobile layout. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, offer a bounded component set with semantic headings and preview. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include block type, validation, alt text, transcript, source and responsive behavior. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with copy paste, missing alt, mobile preview and unsupported embed. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: editor experience owner
• Release evidence: lesson rendering matrix
• Stop condition: authors can publish inaccessible empty structure

Treat media as a pipeline

Video upload includes validation, processing, renditions, captions, thumbnails and failure recovery.

The failure mode is concrete: the dashboard marks an upload complete before it is playable. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, show separate upload and processing states with actionable errors. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include file limit, type detection, scanning, checksum, transcode state, caption and retry. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with interrupted upload, corrupt video, duplicate file and failed transcode. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: media lead
• Release evidence: media lifecycle report
• Stop condition: learners receive an unplayable published asset

Checkpoint 4: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Make accessibility part of publishing

Captions, transcripts, keyboard use, contrast and meaningful structure affect whether learners can participate.

The failure mode is concrete: accessibility is a post-launch content cleanup. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, block publication or require documented exception for critical accessibility gaps. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include caption status, transcript, alt text, heading audit, focus order and contrast. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with keyboard-only lesson, screen reader, zoom and caption synchronization. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: accessibility owner
• Release evidence: WCAG-oriented review record
• Stop condition: required learning content has no accessible equivalent

Design assessments as versioned evidence

Questions, attempts, grading and feedback should connect to named outcomes.

The failure mode is concrete: editing a question changes the meaning of historical scores. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, version assessments and retain the exact item set used for each attempt. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include question version, objective, answer policy, attempt limit, rubric and feedback release. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with question edit, retake, manual grade and invalid item. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: assessment owner
• Release evidence: historical-score reproducibility
• Stop condition: a past result cannot be reconstructed

Separate completion from mastery

Watching a video is activity; it does not necessarily demonstrate learning.

The failure mode is concrete: the dashboard calls progress learning success. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, define completion rules and mastery evidence independently. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include view threshold, activity submission, assessment score, rubric and override reason. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with skipped video, failed quiz, manual completion and changed threshold. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: learning analytics lead
• Release evidence: metric definition sheet
• Stop condition: one percentage mixes incompatible outcomes

Protect active learners during changes

Published courses evolve while people are enrolled.

The failure mode is concrete: reordering or deletion strands learners or invalidates certificates. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, choose whether a change applies to new enrolments, all learners or a new course version. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include effective version, migration rule, learner notice, prerequisite recalculation and rollback. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with deleted lesson, changed passing score and archived cohort. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: release owner
• Release evidence: course migration simulation
• Stop condition: editing content silently changes earned outcomes

Checkpoint 8: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Give pricing its own workflow

Course price, discounts, subscriptions and instructor earnings are financial configuration, not lesson metadata.

The failure mode is concrete: a creator changes price without understanding active promotions or refunds. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, separate catalog product, price versions, offers, entitlement and settlement settings. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include currency, tax presentation, effective date, coupon limits, refund policy and creator share. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with price change, expired offer, partial refund and unpublished course. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: commerce owner
• Release evidence: purchase-to-entitlement test
• Stop condition: payment success and creator earnings share one status

Handle cohorts and schedules explicitly

Cohort courses add start dates, sessions, capacity, attendance and deadline changes.

The failure mode is concrete: a static course date is copied into every learner record. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, model cohort instances that reference a course version. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include timezone, capacity, enrolment window, live link, attendance, deadline and exception. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with timezone boundary, rescheduled session and late enrolment. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: program manager
• Release evidence: cohort calendar test
• Stop condition: one change corrupts another cohort

Build communication with consent and context

Announcements and reminders should reference a course event and respect preferences.

The failure mode is concrete: creators blast every learner or expose recipient lists. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, use scoped audiences, templates, preview, scheduling and delivery history. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include course or cohort audience, channel, locale, opt-out, sender and message version. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with duplicate schedule, withdrawn learner and failed delivery. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: communications owner
• Release evidence: notification audit
• Stop condition: a creator can message unrelated users

Use analytics that answer decisions

Creators need to know where learners stop, fail, retry or request help—not only total views.

The failure mode is concrete: charts optimize watch time without learning context. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, tie events to course version, lesson, outcome and learner state. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include event definition, consent, deduplication, denominator, timezone and freshness. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with repeat viewing, deleted user, course version and bot traffic. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: analytics owner
• Release evidence: recomputable funnel
• Stop condition: a metric has no documented denominator

Checkpoint 12: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Provide learner support context

Support needs enrolment, entitlement, progress, attempts and communications in one controlled timeline.

The failure mode is concrete: staff reset records directly in the database. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, create bounded actions such as resend access, extend deadline and invalidate attempt with reason. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include role, reason, before-and-after state, learner notice and immutable audit. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with wrong course, expired elevation and repeated action. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: support lead
• Release evidence: support recovery drill
• Stop condition: routine help needs unrestricted database access

Plan integrations at stable boundaries

Video providers, live classrooms, identity and external learning tools should not define the internal course model.

The failure mode is concrete: provider IDs leak through every screen and make replacement impossible. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, use adapters and stable internal references; adopt standards such as LTI only for validated interoperability needs. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include provider mapping, scopes, webhook verification, retry, status and disconnect. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with expired token, duplicate event and provider outage. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: integration architect
• Release evidence: disconnect and replay tests
• Stop condition: one vendor failure blocks all authoring

Create a publication gate

A complete course needs curriculum, content, accessibility, commerce and support readiness.

The failure mode is concrete: publish is enabled because every title field is filled. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, run a transparent readiness checklist with blocking errors and accountable overrides. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include objectives, broken links, media state, captions, assessments, price, refund copy, preview and owner sign-off. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with empty module, failed media, inaccessible file and stale price. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: quality lead
• Release evidence: signed publication report
• Stop condition: a critical learner path has not been previewed

Implementation references

Use 1EdTech Learning Tools Interoperability and record the exact version reviewed for this release.

Compare implementation decisions with 1EdTech Caliper Analytics and record the exact version reviewed for this release.

Validate the relevant controls against W3C Web Content Accessibility Guidelines and record the exact version reviewed for this release.

Review W3C WebVTT Specification and record the exact version reviewed for this release.

Continue into Education and EdTech when converting the guide into a scoped product build.

Frequently asked questions

What belongs in a course creator dashboard MVP?

Curriculum structure, draft and review states, structured lessons, media processing, accessibility checks, assessments, publishing, enrolment visibility, learner analytics and support actions.

Should every save update the live course?

No. Maintain an independent draft and an approved published version so creators can preview, review, schedule and roll back changes safely.

How should course videos be handled?

Use an upload and processing pipeline with validation, malware controls, resumability, renditions, captions, thumbnails and explicit failure states.

What analytics are genuinely useful?

Version-aware lesson completion, assessment attempts and mastery, drop-off points, repeat attempts, support demand and cohort comparisons with documented denominators.

How do edits affect enrolled learners?

Use an explicit version policy. Apply changes to new learners, migrate active learners under a reviewed rule, or create a new course version while preserving historical evidence.

Are captions optional?

Treat accessible alternatives as a publication requirement for essential media, subject to the applicable standards and audience rather than an optional polish task.

How should creator payments appear?

Show gross sales, adjustments, refunds, fees, creator share, pending earnings, available earnings and payouts as explainable separate states.

What should block publication?

Missing essential content, broken learner paths, failed media, unresolved accessibility gaps, invalid assessments, incomplete pricing or entitlement configuration, and absent support ownership.

Turn the checklist into release evidence

A strong dashboard or platform is not defined by the number of controls it displays. It is defined by whether every important state has an owner, a permitted transition, a recovery path and evidence that survives the happy-path demo.

Keep the first release narrow, but do not make its promises vague. Accurate boundaries build more trust than copied features whose security, learning value or operational consequences have not been designed.