Sometimes a feature that sounds simple on paper becomes a much larger design and development challenge once you consider how people will actually use it.
That was the case when I needed to introduce a new multi-section course structure into an existing online safety training platform.
The platform already supported more than 70 online courses. Learners could open a course, work through a presentation and supporting materials, complete a quiz and receive a certificate after passing.
That experience worked for the majority of the training library. Replacing the existing course system or forcing every course into a new structure would have created complexity where it was not needed.
But one particular course needed something different.
The problem: one course no longer fit the existing structure
Instead of one continuous presentation followed by one final quiz, this course needed to be divided into several distinct sections.
Each section contained a specific range of course material and ended with its own quiz. Learners needed to pass one section before continuing to the next, and only after successfully completing every section should the overall course be considered complete and a certificate become available.
That was the technical requirement.
The bigger design question was how to make the new structure immediately understandable to the learner.
Adding complexity to the system did not mean the learner should have to experience that complexity.
The interface suddenly had more questions to answer
The original course experience had a relatively simple journey: review the course material, take the quiz, pass the course and receive a certificate.
Multiple sections introduced an entirely new set of questions:
- Which section am I currently working on?
- How much of the course have I completed?
- What happens after I pass this quiz?
- Can I return to something I already completed?
- Can I accidentally skip ahead?
- If I revisit an earlier section, does that become my current point of progression again?
- Where do I go when I am ready for the next quiz?
Rather than answering those questions through instructions scattered throughout the course, I wanted the interface itself to communicate as much of that information as possible.
Explaining the journey before asking someone to take it
The first addition was a short introductory modal when a learner first enters a sectioned course.
Instead of expecting someone to discover the rules through trial and error, the modal explains the structure before they begin.
It tells the learner that:
- The training is divided into multiple sections.
- Each section contains course material followed by a quiz.
- A score of at least 85% is required to continue.
- Completed sections can be revisited for review.
- The certificate becomes available after every section has been successfully completed.
The modal is intentionally an introduction rather than something that repeatedly interrupts the learner.
Once it has done its job, the course interface takes over the responsibility of communicating progress and next steps.
Explain the system once. Then design the interface so people do not need the instructions again.
Turning the side menu into a course roadmap
The course navigation also needed to change because the learner was no longer moving through one continuous experience.
The side menu became a small roadmap for the course.
Each section is displayed individually, with clear states showing whether it has been completed, is currently available or remains locked.
That gives learners a persistent answer to two important questions: where am I, and what comes next?
That is the same underlying reason navigation matters on much simpler websites too. A person should be able to understand where they are and where they can go next without having to reconstruct the system in their head. I explore that more broadly in Why Website Navigation Matters More Than You Think.
Viewing a section and progressing through the course are not the same thing
This created one of the more important state-management decisions in the project.
The section a learner is currently viewing is not necessarily the same as the section they have currently unlocked.
Imagine a learner has completed Sections 1 and 2 and unlocked Section 3.
If they return to Section 1 to review something, Section 1 becomes the section they are viewing. But Section 3 is still their actual point of progression.
Those cannot be treated as the same piece of state.
Where someone is looking and how far they have progressed are two different questions.
The URL therefore identifies the section currently being viewed, while the learner's saved course progress determines how far they have actually progressed.
A URL such as ?section=0can display the first section, but it does not move the learner's saved progress backwards.
This makes completed content reviewable without allowing navigation to rewrite progression.
Locked states needed to represent real permissions
Separating viewing state from progression also created an important safeguard.
Future sections remain locked according to the learner's saved progress rather than simply trusting the section number in the URL.
That means navigation is not just a visual treatment.
The interface reflects the actual course state stored for that learner, while the backend continues to validate which section they are permitted to complete.
Changing a URL should never be enough to manufacture progress.
Completed sections should still be useful
Once a section has been completed, it remains available for review.
That was particularly important for safety training, where someone may want to return to earlier material and double-check information before continuing.
But reviewing a completed section does not mean retaking its quiz.
The interface identifies the section as complete and treats it as reviewable rather than presenting the learner with another quiz action.
Guiding learners without trapping them
For the learner's current section, the quiz remains available through the course navigation when they are ready to take it.
The presentation itself contains predetermined checkpoints indicating when the learner should complete the section quiz.
That means the interface does not need to force someone through every slide again simply to regain access to a quiz button.
This matters particularly for returning learners. If someone leaves the course and comes back later, or wants to review part of their current section, they should not have to mechanically click through material they have already seen just to find their next action.
Guidance should help someone move forward. It should not make them fight the interface to get there.
Progress needed to mean something
A course-level progress indicator was another important addition.
With a single-quiz course, completion is relatively binary. The course is either still in progress or complete.
A multi-section course has meaningful milestones between those two states.
For a four-section course, completing one section represents 25% course completion. Two sections represent 50%, three represent 75% and completing all four represents 100%.
Importantly, a section only contributes to that progress after its quiz has been passed.
The progress bar is therefore based on completed sections rather than presentation slides.
Slide position can tell us where someone is within a presentation. It cannot necessarily tell us whether they successfully completed that part of their training.
Progress should represent the meaningful completion event, not simply the easiest activity to count.
The data model had to understand sections too
The interface could not support this properly without changes underneath it.
Previously, a learner's course record could store an overall quiz score and answers because a normal course had one primary quiz attempt associated with completion.
A sectioned course needs more granular information.
The learner's course record now contains section progress that can associate a particular section with information such as:
- Section order
- Quiz result
- Submitted answers
- Completion status
- Completion date
The system can therefore understand not only that a learner is halfway through a course, but why they are halfway through it.
One new course structure should not break 70 existing courses
This was not a new platform being built from scratch around one course.
It was an extension of a live training platform with more than 70 existing courses.
Backward compatibility was therefore one of the biggest development considerations.
The master course identifies whether it uses the sectioned structure.
If it does not, the existing course and quiz experience continues to operate as before. If it does, the application selects the appropriate section and quiz while continuing to reuse as much of the existing course, quiz and completion infrastructure as possible.
The goal was to extend the system where the new experience needed it, not rebuild everything simply because one course was different.
Keeping the course ID and learner course ID separate
The new structure also made an existing architectural distinction even more important.
The platform has both a master course and an individual course assignment belonging to a learner.
The master course ID identifies the course itself and is used to retrieve its content and configuration.
The learner's UserCourse ID identifies that learner's specific assignment and contains information such as their progression, quiz results, answers and eventual certificate.
Once multiple sections and learner-specific progression were introduced, keeping those identities separate became critical.
Quiz submission needed backend validation too
When a learner submits a section quiz, the frontend cannot simply announce that the section has been completed and move on.
The submission includes information identifying the learner's course and the specific section being completed, along with the quiz result and answers.
The backend verifies that the requested section belongs to the course and that it is actually the learner's currently available section before recording the result.
If the learner does not achieve the required 85%, the section remains incomplete.
If they pass, the next section becomes available.
When the final section is successfully passed, the overall course can move into the existing completion and certificate process.
Reaching the final section is not the same as completing it
That distinction sounds small, but it matters enormously in the completion logic.
Simply arriving at the final section cannot trigger course completion.
The learner has to actually pass it.
Being at the end of a course and successfully completing the course are not the same state.
Successful completion, rather than merely viewing the final section, is therefore what triggers the certificate flow.
Completion also had to preserve the journey that created it
The final section introduced another subtle data problem.
Section submission records the final section result and establishes that all of the sections have been passed. The existing overall course-completion process then handles the broader information used elsewhere in the platform, including completion and certificate data.
The overall completion update could not overwrite the learner's newly updated section history.
The fresh section progress therefore needs to remain part of the final learner course record.
Completing the whole course should preserve the individual milestones that produced that completion.
The final screen needed to feel like course completion
The completion experience was considered from the same perspective as the rest of the interface.
After several sections and several quizzes, the learner should not arrive at a screen that feels as though they merely completed another isolated quiz.
They completed the entire course.
The final experience can acknowledge that first, then provide a summary of the sections and their results before presenting the existing certificate and post-course actions.
Why I didn't build an entirely separate course player
It would have been possible to create a separate component, separate quiz system, separate completion flow and separate data model specifically for sectioned courses.
But that would have introduced a lot of duplicated complexity.
Instead, the implementation extends the pieces that already work and introduces differences only where the new learning experience actually requires them.
The same philosophy applies to the interface.
The learner does not need to understand the architecture behind the course.
They need to know where they are, what they have completed, what is available next and what action they should take.
Making the system more sophisticated without making the experience harder
Looking at the finished experience, each addition has a specific job.
- The introductory modal explains the journey once.
- The section navigation provides orientation.
- Locked states prevent accidental progression.
- Completed sections remain available for review.
- The quiz action appears when it is relevant.
- The progress bar represents meaningful course completion.
- The URL controls what is being viewed without rewriting actual learner progression.
- The backend validates what the learner is permitted to complete.
- The final completion experience brings the individual sections back together as one finished course.
What began as a requirement to “split a course into sections” ultimately became an exercise in designing state, navigation, progression, feedback and flexibility together.
The most important outcome was not simply that the platform could technically support multiple quizzes.
It was that the additional complexity of the course did not have to become additional complexity for the learner.
Understand where you are. Know what comes next. Always have an obvious path forward.