Independent practice · 2024–
eLearning Design System
An operational system connecting learning patterns, visual foundations, reusable components, platform implementation, accessibility, governance and learning-data design.
- State
- Active
- Role
- System strategy, learning design, UX/UI, front-end development and governance
- Scope
- Experience · content · system
What it is
A core system, not an ISQ-owned style guide.
I began the eLearning Design System in 2024 to stop recurring learning, interface and production decisions being solved again inside each course. The core system is intentionally neutral. It defines reusable patterns, components, implementation rules and governance that can be consumed by different branded learning environments.
Independent Schools Queensland is an important production implementation of the system, not the owner of the system itself. ISQ branding, typography and course-specific requirements sit in an implementation layer while the reusable design logic remains portable.
Architecture
Five connected layers
01
Foundations
Typography, colour, spacing, imagery and accessibility rules that implementations inherit.
02
Learning patterns
Repeatable structures for orientation, scenarios, decisions, legislation, reflection, assessment and resources.
03
Components
Reusable implementations of those patterns, with defined behaviour rather than appearance alone.
04
Platform implementation
Guidance for choosing the least complex implementation that fully supports the learning purpose — native blocks first, custom code only where it earns its complexity.
05
Governance and evidence
Lifecycle, accessibility, implementation status and learning-data conventions that keep the system coherent as real courses change it.
Production implementation
ISQ is where the system is being tested against real constraints.
The ISQ implementation applies its own brand layer while using the same core system to govern Rise course structure, reusable custom-code components, default blocks, accessibility and production decisions. That separation matters: improvements proven in one implementation can strengthen the core without turning the whole system into an ISQ artefact.
Current work includes reusable Rise components for questions, feedback, scenario and decision patterns, alongside implementation guidance for when a native Rise block is already the better answer.
Current extension
Learning data is becoming part of the design system.
Default course exports can tell an organisation that an activity happened without necessarily saying anything useful about the learning decision behind it. The system is now extending into xAPI governance: statement intent, naming, a shared profile and data dictionary, and custom Rise outputs where the default telemetry is too blunt.
That changes xAPI from a technical add-on into another governed design decision: decide what evidence is meaningful first, then implement the statement that carries it.
Decisions
Three decisions that define the system
Core and implementation
Keep the reusable system neutral; let brands consume it.
A branded implementation should prove the system, not become the definition of it.
Implementation complexity
Use the least complex implementation that fully supports the learning purpose.
Custom code is valuable when it creates behaviour the native platform cannot provide. It is not a quality signal by itself.
Learning evidence
Govern what learning data means before governing how it is emitted.
xAPI statements become useful when their verbs, objects and context correspond to a deliberate evidence question rather than a default export.
Open the current reference implementation (opens in a new tab)