Independent Schools Queensland · Design system
One design language, defined once and consumed across digital learning.
A shared framework connecting learning design, visual foundations, reusable patterns, interface components, accessibility and governance across Articulate Rise, Connect & Learn and future ISQ digital learning products.
In 60 seconds
- The problem
- Digital learning decisions and solutions were distributed across platforms, courses, documents and production code.
- My role
- Led the system from emerging course-level patterns through component development, documentation, audit, governance and live implementation.
- Scope
- Learning patterns, visual foundations, components, Rise implementation, accessibility, imagery, documentation, governance and the live reference site.
- Where it got to
- A working operational reference connecting design intent with reusable implementation across ISQ digital learning.
- Built with
- HTML · CSS · JavaScript · Articulate Rise · Moodle
The situation
Independent Schools Queensland produces a substantial amount of digital learning: compliance courses and professional-learning programs for teachers, principals, board members and volunteers across member schools. Much of it shares the same underlying requirements — section orientation, legislation and policy explanation, scenario progression, evidence presentation, decision points, role comparison, process explanation, reflection, knowledge checks and resource presentation — but each course had, until now, solved them again from scratch.
That pattern followed directly from the earlier work moving Connect & Learn onto ISQ-hosted Moodle: a platform migration and a parallel rebuild of more than sixty Storyline courses inside a single term. The migration solved where courses lived. It did not solve how they were designed, and the courses built afterwards faced the same recurring decisions the old ones had.
What was actually wrong
The problem was not inconsistent styling. It was repeated design decisions with no shared record of the decision already made: unclear component status, duplicated implementation, inconsistent learner experiences, documentation that drifted from what courses actually shipped, accessibility risk carried course by course, and no reliable way to hand a proven solution from one course to the next. None of that is fixed by a style guide, because a style guide describes appearance and this problem was about behaviour, structure and reuse.
Instead of designing one more polished course, the opportunity was to build the system that could support every future course: a shared framework connecting learning design, visual design, interaction design, platform implementation, production standards, accessibility and governance, so a recurring problem only had to be solved once.
My role, and who else was involved
Glenn led the design-system strategy, system architecture, learning-pattern definition, component specification, UX and information architecture, visual design, front-end development, Rise implementation, accessibility guidance, imagery standards, documentation, the system audit, and the governance and lifecycle model, as well as building the live reference site.
One system, several consumers.
Foundations set the values everything else inherits. Learning patterns turn those values into repeatable structures for a course. Components are the built implementation of a pattern. Platform implementation carries a component into a real authoring environment. Governance keeps the stack from drifting once more than one course depends on it.
Foundations
Design tokens and visual foundations: colour, type, spacing and the values every pattern and component inherits.
Learning patterns
Documented, repeatable structures for recurring learning needs — orientation, scenario progression, decision points, legislation explanation and more.
Components
The built implementation of a pattern: specified, named and given a maturity status.
Platform implementation
How a component is delivered in a real authoring environment, from a native block to custom code to a post-publish enhancement.
Governance
The maturity model, contribution process and versioning that keep the system coherent as it grows.
Consumed by
- Articulate Rise
- Moodle (Connect & Learn)
Extending platform implementation further is named as ongoing work, not a finished claim — see “Where it got to” and “What's next” below.
Selected components
- Section opener
- Orients a learner at the start of a new section: what it covers, why it matters and how long it takes. A native platform heading block could not carry the “why it matters” framing without breaking the platform's own styling, which is why this is a reusable custom-code component rather than a default block. It carries a heading landmark and a defined reading order, so a screen-reader user meets the section the same way a sighted learner does.
- Scenario stage
- Carries a narrative scenario through several linked stages, so a course can put a decision in context rather than stating it in the abstract. Built as a reusable component because scenario-based courses recur constantly and had previously been rebuilt per course, each with slightly different navigation and a slightly different accessibility story. Keyboard and focus behaviour is specified once, in the component, rather than re-tested on every course.
- Decision point
- Presents a choice and its consequence, used wherever a course needs a learner to apply judgement rather than recall a fact. This is the component followed through specification, implementation and use below, because it is the clearest example of a pattern that started as a recurring course requirement and ended as a documented, governed part of the system.
- Legislation panel
- Presents a piece of legislation or policy alongside a plain-language explanation, used across the compliance courses the system grew out of. A post-publish CSS enhancement was considered and set aside here, because the panel needed a defined reading order and a collapse state that a CSS-only treatment could not guarantee across authoring updates; it is built as a governed reusable component instead.
- Resource panel
- Surfaces supporting resources — documents, links, further reading — without breaking a course's linear flow. Implemented as the lightest tier available, a native platform block with a post-publish CSS enhancement, because the learning purpose needed a clearer visual treatment rather than custom interaction logic. The system's rule is to use the least complex implementation that fully supports the learning purpose, and this component is the clearest example of that rule being applied rather than overridden.
Three decisions I would defend
What was chosen, why, and what it cost. A decision presented as costless is marketing.
Build a design system, not a course style guide
- The choice
- The work was scoped as a system connecting learning design, visual foundations, components, implementation guidance and governance, rather than a visual style guide for Rise courses.
- Why
- A style guide fixes what things look like. The recurring problem was about what things are and how they behave: which pattern to reach for, how a component is implemented, and who decides when it changes. Only a system with governance behind it can answer those.
- What it cost
- It took longer to reach something publishable, and it is harder to explain in one sentence than “a set of templates.” A style guide would have shipped sooner and looked finished faster.
Separate native, custom and post-publish implementation
- The choice
- Every pattern is assigned the least complex implementation tier that fully supports its learning purpose: a native platform block first, a reusable custom-code component only where the platform default cannot do the job, and a post-publish CSS enhancement or externally hosted asset where that is enough.
- Why
- Customising every block is how design systems become unmaintainable, because each customisation is one more thing that can break on a platform update. Restricting complexity to where the learning purpose actually needs it keeps the system sustainable as ISQ's platforms change.
- What it cost
- Some components look plainer than a fully custom build would allow, and the tiering decision itself takes judgement on every new pattern, rather than defaulting to “build it custom” as the safe answer.
Treat production code as evidence
- The choice
- The system was audited by comparing its strategic documents, implementation guides and component documentation against the actual production CSS, HTML and live course implementations, rather than assuming the written specification was correct.
- Why
- Documentation drifts the moment nobody is watching. Courses ship, deadlines move, and a component gets adjusted locally without the documentation catching up. Treating the built courses as the primary evidence, and the documentation as a claim to be checked against them, is how that drift actually gets found.
- What it cost
- The audit surfaced undocumented components, inconsistent naming and duplicated treatments that then had to be reconciled, which is slower and less comfortable than trusting the documentation and moving on.
Governance and audit
Each component carries a documented maturity status, from an early proposal through validation in production to becoming a governed, reusable part of the system, with a defined path to retirement when a pattern is superseded rather than silently abandoned. The exact set of status labels is confirmed against the live system rather than restated here as a fixed list.
The system was audited against its own strategic documents, implementation guides, component documentation, production CSS and HTML, and live course implementations, rather than assuming the written specification was the complete system. That audit surfaced undocumented components, inconsistent naming, locally redefined values, duplicated treatments and components that had diverged from their documented pattern.
Versioning and a contribution route are what keep the system from drifting again now that more than one course depends on it. This is treated as an ongoing operational discipline, not a one-off clean-up.
Where it got to
- Distributed design decisions consolidated into one coherent reference
- Documented, reusable learning patterns derived from real course production
- Shared visual and interaction foundations across Rise and Moodle-based delivery
- A catalogue of reusable, specified components
- Rise implementation guidance for the patterns and components in the system
- Accessibility requirements attached to component documentation
- Imagery and media standards for digital learning production
- Drift between documentation and production surfaced and reconciled through audit
- Component status and lifecycle governance, so the system can evolve without becoming an uncontrolled collection of one-off builds
- A maintainable live operational reference connecting design intent to implementation
- Foundations built as governed values, so a future rebrand can be carried through the system rather than redone course by course
Adoption figures, development-time savings and accessibility certification are not published and are not claimed here.
What I would do differently
The next stage is adoption rather than invention: testing the system through further production work, resolving components still in an early or experimental status, extending platform implementation, and finding out whether the system actually improves consistency, accessibility and delivery efficiency rather than assuming it does.