Dublin Business School's Careers Hub needed a way to deliver work readiness training to thousands of students across all disciplines, asynchronously, without a facilitator, and in a format that students would voluntarily complete rather than click through as quickly as possible.

I was the sole instructional designer and Storyline developer on the project. Video and illustration assets were produced by a dedicated production team to briefs and specifications I wrote; I directed the visual and instructional requirements for each lesson. My role was to take 21 lesson scripts, each covering a different employability skill, and turn them into something genuinely worth a student's time. I owned the pedagogical strategy, the UI design, the Articulate Storyline build, the testing, and the SCORM deployment to Moodle.

The scripts were dense and content-heavy. The risk was producing what the industry calls "page-turning" e-learning: slides of text, a next button, and a multiple choice question at the end. That format is easy to build and easy to skip through. It does not change behaviour and it does not get finished voluntarily. 

The design challenge was how to make 21 lessons on topics like networking, communication, and professional presentation feel different from reading a handout, without the production overhead of full video-based content for every interaction.

Before building a single slide, I designed a pedagogical framework that every lesson would follow. Consistency was deliberate: once a student understood the structure from lesson one, they could navigate every subsequent lesson without cognitive load spent on orientation. The structure freed their attention for the actual content.

The Storyline home screen for one lesson, showing the Introduction, Knowledge and Challenge navigation structurealongside the triggers and conditional logic that controlled progression between sections.

The Knowledge section of each lesson used a progressive unlocking system: topic one was available on arrival, and subsequent topics only became accessible as students completed the previous one. This prevented students from jumping to the end, maintained a coherent learning sequence, and provided the system with a clear record of what each student had actually engaged with.

This required a network of variables and conditional triggers that tracked completion state across every topic in every lesson. Each trigger was individually configured and tested, because a student hitting a locked screen they could not resolve had no support mechanism in an asynchronous environment.

The Story View for one lesson, showing all slides and the conditional connections that governed navigation between Introduction, Knowledge topics, and the Challenge.

The interaction design goal was variety within a reliable container. The structure was the same every lesson. The interactions inside it were not. Each topic within the Knowledge section used a different mechanic depending on what the content needed: scenario-based decisions, drag-and-drop categorisation, tabbed explorers, interactive diagrams, and listening exercises with drag-to-activate audio.

The rule was that every mechanic had to serve the content rather than decorate it. A drag and drop activity for categorising question types made sense because the learning objective was recognising distinctions. A scenario with a binary decision made sense for ethical judgement content where the right answer was contextual.

Drag-to-activate listening exercise: students drag the record onto the gramophone to play a recording, then answer twenty true-or-false statements from memory, with no notes allowed.

The Story View for one lesson, showing all slides and the conditional connections that governed navigation between Introduction, Knowledge topics, and the Challenge.

The question behind a card: clicking a "?" opens a multiple-choice prompt with a supporting image, and a correct answer feeds back and unlocks the country on the board.

Gamified code-entry activity: students click each factor influencing communication to collect clues toward a secret code, with a set difficulty level, ilimited attempts, and a hint on hand.

Each lesson was built, tested internally, and refined before the next one began. This iterative approach meant that lessons built later in the project were consistently more efficient than earlier ones: more streamlined triggers, cleaner navigation logic, and bettercalibrated interaction difficulty. Improvements discovered in later lessons were then applied retroactively to earlier ones. Internal testing covered edge cases: what happened if a student clicked through too fast, navigated backwards unexpectedly, or tried to access a locked topic directly. Each scenario was tested deliberately before the lesson was signed off.

Feedback from SME-led student pilot sessions was analysed and fed back into the design, addressing specific points of confusion around navigation and challenge instructions that internal testing had not surfaced.

Each lesson was built, tested internally, and refined before the next one began. This iterative approach meant that lessons built later in the project were consistently more efficient than earlier ones: more streamlined triggers, cleaner navigation logic, and bettercalibrated interaction difficulty. Improvements discovered in later lessons were then applied retroactively to earlier ones. Internal testing covered edge cases: what happened if a student clicked through too fast, navigated backwards unexpectedly, or tried to access a locked topic directly. Each scenario was tested deliberately before the lesson was signed off.

Feedback from SME-led student pilot sessions was analysed and fed back into the design, addressing specific points of confusion around navigation and challenge instructions that internal testing had not surfaced.

Run student usability testing earlier, not after everything is built. The SME-led feedback sessions happened after all 21 lessons were complete. Running even informal student testing after the first two or three lessons would have surfaced navigation and instruction clarity issues much earlier, when fixing them was faster and cheaper than

Build a reusable component library before lesson one. By lesson 10, I had developed a set of interaction patterns and trigger configurations that worked reliably. Having those components ready from the start would have reduced build time significantly across the first half of the project.

A consistent structure is a feature, not a limitation. Early in the project I questioned whether repeating the same three-pillar structure across all 21 lessons would feel monotonous. In practice, the opposite was true. Students who knew what to expect navigated faster, spent more attention on content, and were less likely to drop off due to orientation confusion. Predictability in structure frees cognitive space for learning.