Building a Custom Learning Management Platform

Project Overview

The Problem

The company delivered experiential learning programs — cohort-based, multi-week journeys involving facilitators, learners, assignments, discussions, and progress tracking. All of it was managed across disconnected tools: spreadsheets, communication platforms, and file-sharing systems.

This worked at a small scale. As programs grew, it didn't. Off-the-shelf LMS platforms weren't the answer. Tools like Moodle, Blackboard, and NovoEd which I benchmarked as part of the discovery process were built for self-paced, topic-level learning. A learner enrols, consumes content, and earns a completion. That model works well for individual skill-building. It doesn't work for what we were delivering.

Our programs operated at a client and cohort level. The same course could be running simultaneously for multiple companies, each with its own learners, facilitators, and real-world business problems shaping the work. programs combined self-paced modules with live sessions, individual assignments with group collaboration, and facilitator-led checkpoints with learner-driven progress. No existing platform was designed to manage that combination across multiple clients and cohorts running in parallel — without collapsing into manual workarounds.

The timing mattered too. This was built during COVID, when in-person delivery had stopped. The platform wasn't solving an immediate crisis — it was building the infrastructure for what came next, when the world opened back up and program volume returned.

Scope & My Role

I led experience strategy and definition end-to-end: user research, information architecture, feature prioritisation, and developer collaboration. Worked closely with a designer who translated the system structure into high-fidelity prototypes.

I authored the full product requirements document with detailed specifications covering platform hierarchy, role-based permissions, content and course windows, submission gallery, notifications, leaderboard, and a phased feature roadmap across three releases. Ideas came from the whole team through structured brainstorming; I synthesised them, challenged them, and translated them into a buildable specification.

This was early in my career, and platform design at this level was new territory. I treated that as a research problem: build the knowledge through benchmarking, stakeholder conversations, and asking the right questions before making decisions.

Constraints

The platform required serving four distinct user groups simultaneously — internal program teams, facilitators, client L&D observers, and learners each with different access levels and expectations.

• Users could hold multiple roles at once
• Programs ran in parallel rather than in isolation
• Courses were structured in stages rather than as flat content lists
• The platform needed to balance the needs of internal teams, facilitators, client L&D stakeholders, and learners each with different expectations and levels of access. Creating clarity across roles without overcomplicating the system required deliberate decisions about visibility and hierarchy.

Investigation

I led the discovery process across all four user groups that would touch the platform, plus a benchmark of the leading LMS options.

Researching existing LMS like Moodle, Blackboard, and NovoEd all fell short. Built around topic-level content delivery, not client-level program management. A standard LMS could hold a course. It couldn't hold a client relationship, a multi-cohort program structure, and a facilitator team with role-specific permissions — all running simultaneously.

This confirmed that replicating existing patterns wouldn't solve the problem. We needed a structure tailored to how experiential programs actually ran.

Gathering & Prioritising Features

We conducted an open brainstorming session with the wider team. Everyone who would use the platform had a stake in what it included. Ideas ranged from core structural needs, role-based permissions, modular content, assignment submissions, reporting dashboards to engagement mechanics like leaderboards, challenge systems, and gamified notifications.

At this stage, nothing was filtered. The goal was to gather as many ideas as possible — quantity over quality.

I then led the prioritisation process with the founder of the company, mapping features across three phases using a desirability / viability / feasibility framework.

Pushing back on Phase 1 scope

The founder wanted gamification and engagement mechanics in Phase 1. I pushed back.

If the core platform doesn't work, if permissions are wrong, if the hierarchy is confusing, if learners can't find their cohort then leaderboards don't matter. Engagement features are only valuable when the foundation is solid.

Phase 1 had to be purely functional: a platform that worked reliably for all four user types. Everything else would layer on top in Phases 2 and 3.

Cross-cohort visibility

A similar decision was made on cross-cohort visibility. Some stakeholders wanted broad oversight across all cohorts. We limited access by default not for simplicity, but for privacy. These programs were built around real client problems, tailored to specific organisations. What one company's learners were working on was not visible to another's. That had to be protected by design, not by policy.

Structuring the System

The platform hierarchy was designed to mirror how programs actually ran.

• Client — the organisation commissioning the program
• Course — the specific learning journey
• Experience Centre (Cohort) — the active group of learners working through it together

Each Experience Centre was a contained environment: learners accessed their content, submitted work, and interacted with peers without seeing other cohorts or programs.

Role-based permissions

Access was defined by role, so the same platform served everyone without exposing the wrong data:

Multi-modal delivery

The platform supported multiple delivery modes within a single program. This multi-modal structure that was not available in any of the benchmarked platforms was the core design problem the system solved.

Prototyping & Validation

Working with a designer who created the high-fidelity designs, I led walkthroughs with the external development vendor — explaining system logic, role permissions, user flows, and feature priorities. I stayed involved through active development to ensure design intent was preserved in the live build.

Internal validation testing was conducted with team members navigating as learners, admins, and facilitators, completing real tasks: accessing a cohort, submitting an assignment, and posting to a discussion thread. Where navigation was unclear or hierarchy broke down, I iterated before handing back to development.

Phase 1 was approximately 90% complete when the project was paused — a leadership decision driven by business priorities, as the revenue-generating learning programs needed our time more than this.

Click to view

What Happened Next — And Why It Matters

When the platform was scrapped, the operational problem didn't disappear. programs still needed to run, facilitators still needed briefing, client information still needed capturing, and teams still needed to coordinate across concurrent deliveries.

I designed a manual operations system to hold it all together:

• A standardised folder architecture that mirrored the platform's hierarchy — every client had a consistent structure so anyone on the team could navigate it without asking
• Intake templates that captured the information the client team was collecting inconsistently, ensuring proper handover and nothing fell through the gaps
• A project plan template that gave the experience design team a shared structure with clear owners, milestones, and lead times
• A facilitator brief template that standardised how information was passed to facilitators, replacing the ad-hoc briefings that had been causing errors

The result was a system that multiple teams — client engagement, experience design, operations, and design — could use without training. It absorbed the coordination work the platform would have automated, and it held up as the business scaled.

Outcome & Impact

The platform MVP was designed, validated, and in active development before it was paused due to changing business priorities.

What came after was arguably as valuable: a manual operations system that solved the core coordination problem within the business's constraints and kept programs running reliably as the team grew.

Reflection

This project taught me to let go when a something wasn't working or possible and focus on designing the next best thing.

Foundation over fancy features. Everything else is decoration until the foundation holds.

The folder structure and templates weren't glamorous work. But they worked, and they outlasted the platform that inspired them. Sometimes the most impactful design is the one that makes the manual work manageable.