eLearning 3.0 — the practice, not the platform

INTRODUCTION

In May, a provost told me her team had booked two days in August to “flip the switch” on a new learning platform. Procurement closed in March. Training webinars were scheduled for July. The syllabus template was a Word document on a shared drive, faculty release time was unbudgeted, and the Center for Teaching and Learning had one media specialist for 13,000 students. The decision she faced was not another vendor demo; it was whether to delay go‑live to avoid compounding old practices with new software. Her operational reality was the same one I have watched recur since 1997: institutions try to buy their way to better outcomes when the constraint is practice.

I learned that lesson early. When my partners and I founded Blackboard, the first challenge was helping campuses put rosters, files, and discussions online. But even after events like our 2004 IPO and the introduction of Building Blocks for custom integrations, a deeper problem remained. The market could assemble a tech stack. The harder work was deciding how to teach and run. Standards formed, but when outcomes stalled, it was rarely because an API didn't exist. It was because pedagogy, staffing, review cycles, and data habits had not changed together.

Lesson — Diagnose the operational constraint before buying new technology.

Institutions often purchase new software to solve problems that are actually rooted in their operating habits. Before signing a contract, determine whether the real bottleneck is a missing feature or an undefined process. The hardest work involves aligning people and workflows, not just assembling a technology stack.

Here is the plain version: practice sets the constraint.

> Practice sets the constraint.

eLearning 3.0 is a practice change before it is a platform change. It names a set of operating disciplines—pedagogy patterns, staffing roles, content operations, assessment models, and data cadences—that, when sequenced and sustained, change what learners do and what institutions can measure. The platform question gets simpler once those disciplines are in place, not before.

I’ll use one metaphor, concentrated at the open, a pivot, and the close, because it fits the operational truth. Campuses are often like kitchens with high‑end appliances and no recipes or roles. People keep buying new ovens. What matters is learning to cook as a team: agreeing on the menu, prepping consistently, tasting early, and plating on time. Once the recipes work and the line runs, you can justify a new range. That is eLearning 3.0.

What follows is built from operational detail: how the category formed, what “practice” looks like in concrete terms, the order to change things, what to measure, and how governance should adapt. It is not a defense of any single platform. It is a field manual for institutions that want outcomes to move.

WHAT PRACTICE REALLY IS

Practice is not a slogan; it is the set of recurring behaviors that produce teachable patterns and institutional reliability. When I say eLearning 3.0 is a practice shift, I mean the work moves from individual heroics to a designed, inspectable system where roles, artifacts, and cadences are explicit.

THE PEDAGOGY PATTERNS

Operationally, start with three artifacts: a program outcomes map, an assessment storyboard, and a weekly activity plan. The outcomes map ladders course outcomes to program outcomes so every assignment knows why it exists. The assessment storyboard defines how evidence will be generated, with rubrics specified before content is produced. The weekly plan sequences time on task, interaction modes, and feedback moments. None of this requires a specific platform, but any good platform should make these artifacts easier to express and audit.

Lesson — Define the learning architecture before producing any content or assets.

Begin by creating a program outcomes map, an assessment storyboard, and a weekly activity plan. These artifacts form the blueprint for learning, aligning every assignment to a program goal and defining how evidence of learning will be gathered. Only after this architecture is set should you begin building media or writing course content.

> Design the work learners will do before you design the site they will click.

Pedagogy patterns also include pacing decisions—fixed cohort schedules, mastery‑based progression, or hybrid models—and feedback loops. For example, a writing‑intensive course might adopt a 72‑hour feedback SLA with required exemplars on week one. A data science course might use short, auto‑scored pre‑labs and human‑scored project reviews. The principle is consistent: define the learner actions and the instructor review points first; pick tools afterward.

THE STAFFING MODEL

Most campuses still treat online course building as an extra duty for faculty, supported by a generalist instructional designer and an over‑subscribed media person. eLearning 3.0 requires unbundled roles with clear handoffs: subject matter experts for intent and voice; instructional designers for learning architecture; media producers for assets; QA specialists for accessibility and consistency; data analysts for signal interpretation; and faculty time allocated for review and facilitation, not production. If your budget line has only “software subscription,” you will stall.

Create capacity in predictable units. A useful baseline is a two‑person pairing of an instructional designer and a media/QA partner who can deliver a minimum‑viable course section in 6–8 weeks when the pedagogy artifacts exist upfront. Add a fractional data analyst to the pod during the first two cycles to build the measurement habits.

CONTENT OPERATIONS

Content ops is the invisible scaffolding. It includes a component library (headers, activity blocks, rubric shells), a naming convention, alt‑text standards, a media compression profile, and a versioning rule. A campus that shares component libraries across programs will outpace a campus that treats every course as a bespoke artifact. Publishing quality rises when friction in reuse falls.

Set a default review cadence: an accessibility gate before first release, a QA pass before each term, and a five‑item punch list for instructors to personalize within a defined envelope. Provide a short, non‑negotiable “house style” that keeps cognitive load down for students moving across courses.

ASSESSMENT AND EVIDENCE

Assessment belongs to practice because evidence systems drive behavior. Decide what you will take as proof: auto‑scored checks for fluency; rubric‑based artifacts for synthesis; peer feedback for critique; simulations for applied judgment. Reverse engineer tools from evidence. If you can’t name the evidence, you’re not ready to buy the platform feature.

DATA HABITS

Data is not a dashboard; it is a set of agreements. Define canonical terms: what is “enrollment” for a program with rolling starts; what constitutes “mastery” in a multi‑attempt design; what is a “session” in blended delivery. Decide what gets reviewed weekly (operational health) and what gets reviewed termly (curricular effectiveness). Create a one‑page data dictionary per program before you integrate anything. You can wire the APIs later.

If you don’t know what you want to see, integrations won’t show it.

HOW THE CATEGORY FORMED

It helps to see how we got here. In the late 1990s, as web servers left the physics closet for central IT, campuses experimented with course websites. The need to package these functions into course tools drove the first commercial LMS wave. During that period, Blackboard and other entrants like WebCT emerged to provide a consistent platform for posting files, running discussions, submitting assignments, and publishing grades. The operational goal was basic but important.

By 2001, SCORM 1.2 gave us a way to package and track content across systems, and by 2004, the center of gravity shifted from monolith to ecosystem. We introduced building blocks to let institutions and partners extend, integrate, and customize workflows without waiting for core releases. This opened a market logic: institutions could assemble their own combinations of authoring tools, assessment engines, proctoring services, and analytics.

The next decade layered on interoperability. IMS Global’s Learning Tools Interoperability (LTI) standard in the early 2010s gave campuses a consistent way to connect external tools with identity and grade passback. Canvas, launched in 2011, set a new tone on user experience and API‑first approaches; Moodle’s open ecosystem continued to flourish. The MOOC wave began in 2012, bringing new attention to scale, video production, and assessment at volume. The U.S. Department of Education’s 2015 guidance on regular and substantive interaction quietly reinforced the point that design and facilitation—not just content—determine quality.

Lesson — Follow the historical pattern of professionalization by standardizing practice before standardizing tools.

The evolution of educational technology follows a clear sequence: experimentation, fragmentation, emerging standards, commercialization, and finally, the professionalization of practice. Institutions that succeed will mirror this pattern internally. They focus on defining their operational and pedagogical model first, which makes subsequent platform decisions much simpler.

If you trace the pattern through 2020 and the emergency remote period, the theme holds: technology matured enough to support many models, but the diversity of outcomes across institutions mapped more to practice maturity than to platform choice. Where campuses had program‑level outcomes maps, unbundled roles, and shared templates, they moved quickly. Where they had generic shells and ad‑hoc training, they treaded water.

The historical through‑line is simple—the winners standardized practice before they standardized tools.

CONSEQUENCES OF PRACTICE CHANGE

When you change practice, your operational profile changes in ways a budget sheet will miss unless you plan for it. The immediate consequences show up in staffing calendars, review cycles, and what students experience in week one.

CALENDAR AND CAPACITY

A practice‑first shop runs on sprints. A reliable cadence I’ve watched work is 12 weeks from framing to publish:

• Weeks 1–3: Pedagogy framing and asset inventory. Outcomes maps drafted, assessment storyboard locked, exemplars collected, and content gap list created. Faculty release time is spent here.
• Weeks 4–9: Build and test. Componentized content assembled, media produced to a set profile, accessibility checks applied, and a pilot run of one unit with 6–10 students or TAs for signal.
• Weeks 10–12: Polish and commit. Revise based on pilot signals, finalize rubrics, set facilitation guide, and schedule a pre‑term QA pass.

This cadence lets you commit to predictable throughput: two to three course sections per pod per term, with quality that rises over iterations. It also exposes where you are under‑resourced: e.g., audio editing delays everything for want of one part‑time role.

FACULTY WORK REDEFINED

eLearning 3.0 separates production, facilitation, and improvement. Production is a team sport with faculty as subject matter experts and reviewers. Facilitation is where instructor presence and feedback live, governed by clear SLAs (e.g., 48‑hour response on forums, 72‑hour grading on artifacts). Improvement is a scheduled, data‑informed revision cycle, not a heroic sprint the week before classes.

This is additive for faculty. It buys back time spent on mechanics and repurposes it for feedback and mentoring—work most faculty value more than formatting pages. The feeling of loss comes from shifting norms; the gain is more time on teaching.

STUDENT EXPERIENCE AT WEEK ONE

Students feel practice. In a practice‑mature program, week one offers a clear orientation, an early low‑stakes check to build fluency, a sample of the main assessment pattern, and a visible path to help—calendarized office hours, discussion prompts with response times, and a prompt feedback expectation. Cognitive load is spent on learning, not on finding.

PROCUREMENT AND RFPS

Lesson — Change your staffing calendar and faculty roles before rewriting your RFP for new software.

A practice-first approach reshapes procurement. Instead of starting with feature checklists, you first define your operational reality: production sprints, unbundled staff roles, and clear faculty expectations. Only then can you write an RFP with requirements that reflect how you actually work, ensuring any new platform fits your model.

Procurement changes character. Instead of feature checklists, you can write RFP items as practice requirements: “Supports templated activity components with version control,” “Exposes rubric results at the criterion level via API within 24 hours,” “Allows role‑segmented workflows for QA before publish,” “Enables mastery pacing with remediation triggers.” Vendors can demonstrate fit to your operating model rather than to a generic list. You also discover you already own 70% of what you need.

> Change how you work and the RFP writes itself.

PLATFORMS THAT FOLLOW PRACTICE

Once practice is explicit, platforms stop being abstract choices and become concrete fits. The same product can be an excellent fit for one institution and a poor fit for another depending on the practice envelope.

SEQUENCE OF SELECTION

Start with the authoring and component layer before the LMS. If your practice depends on flexible activity components reused across courses, invest in the component library and authoring workflow first—this could be a headless CMS pattern, a structured authoring tool, or disciplined use of your existing LMS’s templating. Then evaluate the LMS or learning hub against your required workflows: versioning, role‑based review, accessibility gates, and data exposure. Add assessment engines and proctoring last, and only when the evidence demands it.

INTEGRATION PATTERNS

With practice defined, integration needs get simpler and sharper. You will likely need:

• Identity and role mapping that respect unbundled production and facilitation roles.
• Grade and rubric criterion passback that supports your evidence plan.
• Content lifecycle hooks (draft → review → publish) with timestamps for audit.
• Event logs for student activity that match your data dictionary.

Avoid over‑integration. Many institutions wire up dozens of tools prematurely. Start with a small set that aligns to your evidence plan and expand only when a practice need emerges.

ACCESSIBILITY BY DESIGN

Accessibility is not a post hoc audit; it is a pre‑publish gate and a design habit. Pick platforms and authoring paths that make accessible choices the default—alt‑text prompts, contrast checks, caption workflows with reasonable turnaround times, and math and code rendering that support assistive tech. Then measure conformance at the course and program level as you would measure on‑time delivery in any operation.

MIGRATION WITHOUT RIP‑AND‑REPLACE

Because practice sits above tools, migration can be staged. Redesign a program with your component library and workflows, then bind those to your current LMS. If and when you change LMS vendors, the redesigned courses port with less friction. Your platform choice becomes a buying decision rather than a rescue mission.

Tools should bend to your recipes, not the other way around.

A PRACTICAL 18 MONTH PLAYBOOK

Institutions do not lack ambition; they lack an operating plan that fits academic calendars and resourcing realities. Here is a playbook I recommend when a president or provost wants visible movement without a campus‑wide reset.

MONTHS 1–3: CHOOSE THE PROVING GROUND

Pick one program with enrollment concentration—often first‑year writing, intro STEM, or a high‑enrollment professional program. Appoint a cross‑functional lead with time authority: faculty champion, instructional design lead, media/QA lead, and a data partner from IR or IT. Create the pedagogy artifacts: outcomes map, assessment storyboard, weekly plan. Budget release time for two faculty members to co‑author with the design team.

Name a short list of non‑negotiables: accessibility gate, response‑time SLA, week‑one experience pattern, and a five‑item course style guide. Draft the one‑page data dictionary: terms, measures, and weekly vs. termly reviews.

MONTHS 4–9: BUILD, PILOT, AND MEASURE

Run two 12‑week cycles to produce and field‑test a minimum‑viable course section, then a second section improved from the first. On the first pass, pilot one unit with a sample of students or TAs to test navigation, clarity, and workload. Collect four signals: time‑on‑task, first‑week completion of the low‑stakes check, rubric criterion distributions for the main artifact, and help‑seeking behavior (office hours, forum posts). Use those signals to adjust pacing, prompts, and exemplars.

Train facilitators on the specific patterns of the redesigned course—what to respond to within 48–72 hours, how to give rubric‑anchored feedback with two examples, when to escalate. Do not assume prior facilitation maps to the new design.

MONTHS 10–12: TEMPLATIZE AND PACKAGE

Codify what worked into reusable components: activity blocks with plain‑language prompts, rubric shells with criterion‑level descriptions, feedback templates, and a facilitation guide that fits in six pages. Publish the component library for other programs with two recorded walk‑throughs by faculty peers. Finalize the practice‑aligned RFP items for any tool gaps you discovered, but delay buying unless evidence demands it.

MONTHS 13–18: SCALE TO 25% OF CREDITS

Expand to cover 25% of high‑enrollment credits—your biggest volume and your strongest signal base. Add a second pod to increase throughput and avoid single‑point bottlenecks. Establish a weekly operational review: time‑to‑publish, QA issues found per course, accessibility conformance rate, and facilitator SLA adherence. Run a termly curricular review on outcomes alignment and rubric distributions. Publish a one‑page scorecard for the provost.

By month 18, you will have an operating model, a component library, trained facilitators, and early outcome movement. You can then decide whether platform changes are warranted—based on the fit to practice, not because the calendar says your contract is up.

Pilot one program well and the campus will follow.

GOVERNANCE, DATA, AND CAPACITY

Governance should make practice durable. That means decision rights are clear, data definitions are stable, and resourcing is protected across budget cycles.

DECISION RIGHTS AND ROLES

Set program‑level governance with representation from faculty, design, media/QA, and data. Give the program lead authority over component library updates and template changes within a shared standard. Establish a change‑control process for platform integrations—requests must reference a practice need and an evidence plan. Keep the committee small enough to decide and large enough to represent.

DATA DEFINITIONS AND REVIEWS

Publish a program data sheet with canonical terms and methods: what counts as a submitted artifact, how to treat late work in mastery‑based pacing, and how to calculate participation in asynchronous forums. Define roll‑up logic so leadership can compare apples to apples across programs. Hold a weekly operational review for leading indicators and a termly review for learning outcomes and equity gaps. Keep analytics honest by tying every chart to a decision.

CAPACITY AND BUDGET

Lesson — Budget for the human capacity to execute your practice, not just the software subscription.

Staffing is the rate limiter for change. Prioritize funding for practice lines first: faculty release time, dedicated design and media pods, and data support. Only after funding the human work of redesigning courses should you allocate funds for new software. Investing in reusable components and facilitator training provides compounding returns that software alone cannot.

Software is a line item, but it is not the operating budget. When resources are thin, prioritize activities with compounding returns: component libraries, template improvements, and facilitation training. De‑prioritize bespoke one‑offs unless they are strategic showcases that will become templates.

EXTERNAL PARTNERS AND VENDORS

Use partners to accelerate practice, not to offload responsibility. Ask vendors or service firms to co‑build templates, train your pods, and make their deliverables reusable across programs. Structure contracts around throughput and reusability, not just deliverable counts.

Governance exists to keep practice from unraveling when people change jobs.

THE BET I’D MAKE TODAY

The kitchen metaphor returns because it earns its keep. Stop buying appliances to fix a menu and a line that don’t exist. Teach the team to cook together, write the recipes, and run the line. Then upgrade the oven.

If I were leading a campus today, here is the sequence I would commit to for the next 18 months:

• Choose one program with enrollment gravity and appoint a cross‑functional lead with time authority.
• Produce three artifacts first: a program outcomes map, an assessment storyboard, and a weekly activity plan.
• Fund two pods (designer + media/QA) and faculty release time for two co‑authors; add fractional data support.
• Run two 12‑week redesign cycles, pilot one unit in cycle one, then ship a full section in cycle two.
• Measure five things relentlessly: time‑to‑publish, QA issues per course, accessibility conformance, facilitator SLA adherence, and rubric criterion distributions on the main artifacts.
• Templatize what works, publish a component library, and train facilitators on the new patterns.
• Write practice‑aligned RFP items only after the first cycles; buy tools only when evidence shows a gap the current stack cannot fill.
• Scale to 25% of high‑enrollment credits by month 18; decide on platform adjustments based on fit to practice.

eLearning 3.0 is a professionalization of the work of teaching and learning online. It is not a silver bullet and not a rebrand of the LMS. It is an institutional choice to make pedagogy patterns, staffing roles, content ops, assessment models, and data habits visible and inspectable. The gains compound: faster production, clearer student experience, better evidence, and more time for faculty to teach.

Practice before platform—and outcomes move.

Stop buying platforms to fix practice.
Start treating eLearning 3.0 as an operating change.

I learned this the long way. In 1997, we founded Blackboard (by merging with CourseInfo) to digitize the basics: rosters, files, discussion, gradebooks. By the 2004 NASDAQ:BBBB IPO, extensibility (Building Blocks) and standards (SCORM, later LTI) let campuses assemble sophisticated stacks. Yet the bottleneck wasn’t software—it was practice: how people teach, collaborate, review quality, and use data.

Here’s the operating truth: tools follow rules. If pedagogy, staffing, assessment, and data habits don’t change together, outcomes don’t move.

What to change first:
- Pedagogy patterns: learning outcomes, activity design, feedback loops, mastery pacing.
- Staffing model: instructional designers, media, QA, data analysts, and deliberate faculty time.
- Content ops: templates, asset libraries, review cadences, accessibility as a gating step.
- Data habits: shared definitions, weekly operating reviews, small feedback pilots before big dashboards.

Then pick platforms that fit the practice. The RFP becomes clearer: which system supports your templates, your QA steps, your data cadence, your integration constraints—not generic feature lists. You likely own enough tools already.

A simple cadence works: 12-week redesign sprints (3 weeks framing, 6 build/test, 3 polish). Ship one redesigned section as a minimum viable course, collect signals, iterate. Measure time-to-launch, review cycle time, accessibility conformance, mastery progression, and faculty hours. Budget for practice, not just software.

If you lead a campus or school, you can move 25% of high-enrollment credits into redesigned, feedback-rich formats in 12–18 months without a rip-and-replace. That’s eLearning 3.0: the practice, not the platform.

If this resonates, share it with your teaching and learning team and pick one program to pilot this quarter.

#HigherEd #eLearning #EdTech #InstructionalDesign