Make the next step visible
The Original interface starts with favourites and LMS objects. In Light, I brought course status, progress and the next action together on the learner Dashboard
Enlarge screen 
Enlarge screen A clearer way to manage learning with ILIAS
Product owner for the PoC · Business analysis · Self-hosted product exploration
I chose to explore ILIAS as a self-hosted option for corporate learning. The aim was to start with essential workflows, make everyday tasks clearer and leave room for future development
Swipe across the demo to explore the desktop interface, or choose Fit to screen for an overview
Loading the demo
The interactive workspace will appear here
Interactive reconstruction of selected learner and administrator workflows, using fictional data and simulated imports. Demo state is stored in your browser. This demo does not connect to an LMS or demonstrate that it has all the features of a production system
Designed for desktop
The interactive demo is available in a desktop-sized window. Here, explore the key screens and the product decisions behind them
Enlarge screen Enlarge screen Adding content is not assigning learning
I separated course content from the decision about who should receive it. The administrator selects learners, then reviews the audience and deadline before assignment
Enlarge detail Keep the learner oriented
The course page brings the learning module, due date and current status together. Continue takes the learner back to the activity; the LMS remains responsible for tracking progress
View full screen Screens from the public reconstruction, using fictional data. They illustrate the proposed workflows, not production adoption or validated user outcomes
The question was not simply whether ILIAS could run a course. It was whether employees and administrators could manage everyday learning tasks in it, and whether there was a viable way to move from the existing platform
The case at a glance
- The challenge
- Plan a platform transition without stopping learning or losing progress, history and evidence of completion
- My approach
- I mapped essential workflows, limited the initial scope and set continuity, architecture and acceptance requirements
- The result
- A self-hosted ILIAS PoC with a custom skin and the Unified Light design implemented and checked on the test LMS. This was not a completed migration or corporate rollout
Business context
The business needed to continue providing corporate learning as budget constraints changed. An earlier market evaluation had identified a commercial LMS as the best match for the company’s functional requirements, but the purchase was not approved
I investigated whether an independently managed, self-hosted LMS could support the company’s learning workflows and what would need to change
The PoC explored what the platform could support, how people would use it, the limits of the deployment and future integration requirements. It was not intended to prove that ILIAS matched the shortlisted commercial platform or would reduce total costs
Preserving two years of existing SCORM courses mattered as much as cost, but moving course files alone would not keep learning running. I considered Google Classroom, which was already available to us, a cheaper commercial LMS and ILIAS without interface changes. In my assessment, these paths meant content rework, functional compromises or leaving the usability issues unresolved
I chose to test ILIAS with an adapted presentation layer, not to assume it was already a better replacement
My role
I acted as the product owner for the PoC and combined several responsibilities:
- identified and assessed the open-source alternative;
- translated the business context into product and deployment requirements;
- defined the learner and administrator journeys;
- prioritised the initial scope and established acceptance criteria;
- set the requirement to preserve native ILIAS domain logic;
- directed the design system and presentation-layer work;
- reviewed implementation quality through hands-on and visual QA;
- separated implemented functionality from future architecture and integration proposals
I remained accountable for product direction, quality and final acceptance. The AI-assisted delivery section explains how I divided the work with Codex
Keep learning moving during a platform change
A future transition needed to happen quickly without interrupting learning. Progress, recorded learning history and reporting evidence had to remain available throughout the change, not only after the new platform was in place
Existing platformNext platform
Progress
Learning history
Completion evidence
The platform also needed records of learning-related user actions, complete enough to reconstruct recorded activity and provide evidence of course completion for auditors. The available evidence does not establish the logging scope, retention rules or validated completeness
During my ILIAS walkthrough, I found learning objects, course containers, completion settings and membership in separate parts of the interface. I needed to connect the administrator’s setup process with the learner’s course attempt, while leaving progress tracking to ILIAS
Target workflows
Administrator workflow
- Describe the course
- Add learning material
- Define structure and completion rules
- Select the audience
- Review and publish
- Assign the course
Learner workflow
- Find assigned learning
- Start or resume the course
- Complete the learning activity
- Save progress
- Return and see the current status
I kept the underlying LMS model and aimed to make the sequence easier to follow. Each step had its own operational decision, responsible role and acceptance criteria
Product decisions
1. Separate import, publication and assignment
An imported SCORM package is not automatically a published course, and a published course is not automatically an assignment. I treated these as separate product states with separate administrator decisions and acceptance criteria
Each step needed a review before the administrator moved on. A successful upload alone would not complete an assignment
2. Start with essential workflows, not every feature
Learners, tutors and course administrators have different responsibilities and next actions. I mapped their pages and states, then prioritised the minimum functionality needed for an initial launch rather than exposing all of ILIAS or reproducing every commercial LMS feature
Further capabilities would follow in stages. The aim was to avoid changing too much at once and reduce the risk of errors, but progress, learning history and required reporting were non-negotiable parts of the initial scope
3. Preserve domain logic and customise the presentation layer
I set a requirement not to change the ILIAS core for product-specific behaviour. Customisation was placed in a separate skin, with extension boundaries and a documented policy for upstream fixes
The goal was to avoid creating a separate version of ILIAS that would become difficult to upgrade and maintain. I updated and refined the system while developing the PoC
Functional acceptance: save before leaving a course
- Required behaviour
- The documented player contract required Save and exit to wait for confirmation from the native LMS before returning to the course page and refreshing progress
- Failure behaviour
- On timeout or save failure, keep the attempt open and offer Retry save or Keep learning. The presentation layer must not write its own tracking data or silently discard the attempt
- Recorded check
- A separate native ILIAS capture audit for this public demo recorded a synthetic SCORM package being imported, launched by a learner and used to answer a sample question
- Acceptance boundary
- That check confirms basic playback in native ILIAS, not the redesigned save-and-return flow. Whether tracking data persisted on the server was not independently checked; the save, retry and return behaviour still needed testing in the running LMS
4. Establish the design system before adding themes
I prioritised Light before Dark so that shared components and their states could be reviewed in one theme before extending the semantic token system
Shared components, tokens and rules were also intended to support new features and pages after the initial launch, without rebuilding each screen from scratch. Figma became the design reference, with explicit visual acceptance criteria
One component for every learning state
The learning state determines the next action: start an assigned course, continue an attempt or review completed learning. The card structure and action position stay consistent across states
Continue Learning Card · state variants
ASSIGNED · NOT STARTED
Workplace Safety 2026
IN PROGRESS · 65%
Workplace Safety 2026
COMPLETED · 12 JUL 2026
Workplace Safety 2026
Original Figma exports
Shared properties linked to Figma variables
All three variants use the same surface, padding and corner-radius variables. The Continue action is bound to the primary colour token
- Card surface
color/surface-solidLight alias →light/surface-solid· #FFFFFF- Inner spacing
spacing/520 px on all four sides- Corner radius
radius/md8 px on all four corners- Continue action
color/primaryLight alias →light/primary· #0E7C75
Names and bindings checked against the saved Figma nodes. This is a readable extract of their properties, not a screenshot of the editor
A linked instance, not another copy
The learner Dashboard uses an instance of the In progress variant. The outline marks that exact instance in the exported screen
Course details are sample data. Original Figma exports remain available for inspection; the implementation status is recorded below
What the PoC produced
Verified on native ILIAS
- A self-hosted test environment and a verified SCORM playback scenario
- A custom presentation skin, with early CSS and template iterations reviewed through hands-on walkthroughs
Designed and audited in Figma
- A Unified Light design system built from token-bound components and explicit interface states
- An inventory of pages and user roles, supported by visual and structural QA checks
The final Unified Light design was implemented and checked on the running ILIAS PoC
Reconstructed for this public demo
- Selected learner and administrator workflows, using fictional data, simulated imports and local browser state
Proposed for future validation
- Architecture notes separating native ILIAS logic, presentation customisation and future workflow extensions
- A compliance-course pilot and operational measures to test with employees before considering a rollout
The prototype received positive feedback from management and was presented to C-level stakeholders for further consideration. This helped communicate the product direction and potential operating model, but it did not represent production approval, a confirmed budget or company-wide user validation
Back to case overviewFrom local fixes to a design source of truth
Early iterations relied on direct CSS and template changes in the test LMS. I refined the interface, but local fixes created visual drift and made consistency harder to maintain
I changed the delivery process:
- define the user role and page state;
- establish shared tokens and components;
- create the screen in Figma;
- review the design against acceptance criteria;
- implement the approved direction;
- run visual and structural checks;
- record the result and remaining gaps
The saved design audit found no missing styles, missing fonts or broken instances within the scope reviewed. This example shows how a clipping issue was corrected in the shared component and checked again:
A documented acceptance check
- Criterion
- Shared controls should remain centred and unclipped across the reviewed screen widths
- Finding
- The theme-action icon was clipped inside its 20 × 20 px source frame
- Correction
- The shared component was updated to use a centred 24 × 24 px frame in both Default and Hover variants, rather than patched separately on each screen
- Recheck
- The saved Unified Light design audit recorded no visible clipping in the final set of screens reviewed, including dashboard checks at 1280 and 1920 px
AI-assisted delivery
Codex carried out a substantial part of the work: researching documentation, configuring the server, generating code, implementing the skin, building designs in Figma, documenting the repository and running automated checks
I set the objectives, constraints, expected output and acceptance criteria. I reviewed Codex’s work for defects and scope gaps, and requested changes when the result fell short of the intended product behaviour
Scope and limitations
This PoC did not establish company-wide adoption, production readiness, measured cost savings, multi-instance operation, completed Okta, HiBob or Slack integrations, or improved learning outcomes
Migration, preservation of historical records and audit-log completeness were not validated, and no formal auditor approval is claimed. The test installation was later removed. The saved design audit does not rule out runtime defects; this public demo cannot substitute for validation on a live LMS
I would reconsider ILIAS if interface changes disrupted core learning tasks or required enough extra engineering and design work to undermine the expected cost advantage. Open source was an option to investigate, not a choice to defend regardless of the evidence
What I would measure next
My recommendation would be to run a limited compliance-course pilot before considering a wider rollout. This would allow us to validate essential learner workflows, confirm that completion data is recorded correctly and identify usability issues with real employees
Before a pilot, I would establish baseline and target measures for:
- time required for an administrator to assign a course;
- learner success in finding and launching assigned learning;
- successful course starts and resumptions, with progress saved correctly;
- publishing and assignment errors;
- support requests related to course access and progress;
- keyboard focus, zoom and other accessibility checks;
- SCORM lifecycle reliability across representative packages
A transition would also require checking that progress and learning history matched across platforms, that recorded learning actions were complete and that completion evidence could be retrieved. Acceptance criteria for these checks would need to be agreed before migration
I would interview pilot participants about the difficulties they encountered. Engineering and security review, hosting costs and support requirements would also need assessment before a corporate rollout
Looking for product judgement backed by hands-on delivery?
I’m looking for a Product Owner or Product Manager role combining product judgement, business analysis and hands-on delivery
Credits & licences
ILIAS and its logo belong to their respective rights holders; this independent exploration does not imply endorsement. ILIAS licence · Inter licence · Open Sans licence · Open Sans notice · MacBook frame: Monkr · MIT licence