Exam Module
Aladia had no exam system: no builder, no proctoring, no grading. I designed the whole thing from a blank canvas: three exam formats, AI-assisted question creation, live proctored exams, and a grading model that works across courses with completely different scoring scales.
Date:
Client:
Aladia
Industry:
EdTech
B2B & B2C SaaS
Services:
Live proctoring UX
Grading system design
The problem
Teachers on Aladia needed to create exams, run them with supervision, and grade them, all inside the platform. None of that existed yet.And Aladia serves very different institutions. An Italian liceo grades from 18 to 30, while a corporate course grades from 0 to 100. The same system had to work for both.
The user's challenge
Teachers often reuse the same exam in several courses, and may supervise forty students at once during a live exam.
Students take exams from home, with their camera, microphone and screen monitored, where a bad WiFi connection can look like cheating.
How I found the problem
Most LMS platforms put exams inside courses. It's the obvious structure, and it ships faster.
But Aladia had already hit this problem twice, with Books and with Subjects. When content lived inside a course, every course ended up with its own copy. Fix a typo in one, and the others still have it. Over time, the copies stopped being the same thing at all.
What I learned: the hardest part wasn't the exam itself. It was keeping one exam consistent across many courses, many grading rules, and many students.ù
Decision 1: The exam lives outside the course
Options I considered:
🔴 Exams inside courses, like most LMS platforms. Simple and fast to build, but a teacher using the same final exam in five courses would end up with five copies to maintain.
🟢 Exam Collections at the profile level. An exam is created once and used anywhere.
Each course adds its own schedule, proctoring rules and grading scale on top, without ever touching the exam itself. The exam only knows raw points. Each course decides how those points become a grade.
Why it matters: this one decision made everything else possible. The same exam can run in a course graded 18–30 and one graded 0–100 on the same afternoon. Changing a course's grading scale updates every exam in it instantly, without editing a single question. And a teacher with forty students across three courses maintains exactly one version of each exam
Decision 2: The course decides the grade, not the exam
Every institution grades differently. An Italian liceo grades from 18 to 30, a school might use A+ to F, and a corporate course may only need pass or fail. And because exams live outside courses, the same exam can appear in all of them.
Options I considered:
🔴 Save the grading scale inside the exam. Every institution would need its own copy, which is the exact problem Decision 1 solved.
🔴 One fixed scale for the whole platform. Simple, but wrong for most institutions.
🟢 The exam stays neutral and only knows raw points. Each course decides how points become a grade.
What I designed: three settings inside each course.
Grading scale: the course sets its maximum score (30, 10, 100…) and pass percentage, and exam points scale automatically. Advanced grading adds custom levels like A+ to F.
Weights per exam type: a Final can count far more than a Quiz.
Which attempt counts: Highest by default, because it rewards improvement without punishing a student for trying again. A stricter course can choose Latest or Average.
Why it works: none of these settings touch the exam. Changing a course's scale rescales every exam in it instantly, without editing a single question.
Decision 3: Supervising 40 students without watching 40 screens
On exam day, one teacher may supervise forty students at once, each at home with a camera and a shared screen. Nobody can watch forty video feeds continuously.
Options I considered:
🔴 One shared room for everyone. Students could see or hear each other, and the teacher would get one long recording to scroll through.
🔴 A simple list of student names. The teacher would have to click into each student to check on them.
🟢 One breakout room per student, shown in a grid, with the rooms that need attention highlighted.
What I designed:
The rooms are created automatically from the participant list, so the teacher sets up nothing on the day.
Monitor Exam shows one row per student: webcam and exam screen side by side.
Rooms are sorted into three tabs: Open, Closed (students who submit move out of the way automatically) and Proctoring alerts.
A room lights up the moment something needs attention, like a raised hand or a flag.
The key idea: a teacher can't scan forty rooms, but they can react to the two or three that light up. And each student's session is recorded separately, so every attempt has its own file.
Small decisions that remove work:
If the exam is longer than its calendar slot, the end time extends automatically, instead of cutting the student's time or showing an error.
The entry window (how long students have to start) grows with the exam's length, so the teacher never has to set it.
When grading, AI suggests a score for open questions, and the teacher accepts or changes it.
Decision 4: The system flags, the human decides
Students take exams from home, with camera, microphone and screen monitored. In that situation, a technical problem can look like cheating. A student whose WiFi drops shouldn't be treated as suspicious.
Options I considered:
🔴 End the exam automatically when a violation is detected. Too harsh, and often wrong.
🔴 Show one generic error message. Confusing for the student, and it reads as suspicious behavior.
🟢 Flag and notify, never end. The student is told in the moment, the incident is logged, and the teacher decides.
What I designed: a specific, calm state for each failure:
Camera or microphone disconnected → prompt to reconnect
WiFi drops → the exam pauses and shows that it's reconnecting
Leaving fullscreen (Esc or F11) → prompt to return to the exam
Naming exactly what happened protects the student as much as it protects the exam.
The same thinking runs through the whole student experience:
Scoped rechecks: students select the specific questions they want reviewed and explain why, instead of disputing the whole exam. This keeps a recheck from becoming a second full grading every time.
Controlled chat: students can reach the teacher mid-exam, but only for clarification and support, so chat can't become a way to get hints.
Oral exams got their own one-to-one flow, instead of a video call attached to a written exam.
Performance: one number teachers can trust
A teacher with several courses may have a hundred students or more. Exam results alone don't show who needs help, and neither does attendance. A student can attend every class and fail every exam. Another can skip classes and still score well, until the material gets harder. Checking two separate lists for every student, every week, simply doesn't happen, so students who slip get noticed too late.
What I designed: Performance, one number that combines both signals: Attendance 30% + Exams 70%. A teacher can scan a class and immediately see who's doing well and who needs a conversation.
Options I considered:
🔴 Let each course set its own formula, like grading. But then a "75" in one course would mean something different from a "75" in another, and nobody could compare.
🟢 One fixed formula everywhere, so the number always means the same thing.
Exams carry the larger share on purpose: attendance shows engagement, exams show what a student can actually do, and engagement shouldn't outweigh competence.
The result
A complete exam system, from creation to live proctoring to grading and rechecks, designed where nothing existed before.
One exam, many courses: each course applies its own grading rules without anyone editing the exam.
The most structurally complex system on the platform, built to work across very different academic contexts.
What I learned
It all traces back to one early decision: keeping the exam separate from the course. That's what lets the same exam run under completely different grading rules, and what keeps performance comparable everywhere.
Almost every detail exists because a simpler version broke down against a real edge case during design. The happy path was never the hard part.
