Subject Areas
Subjects on Aladia were rebuilt inside every course, and teachers had to be invited to each course by hand. I moved subjects into one shared Subject Area, so a subject is created once and reused everywhere, and its teacher, books and exams follow it into every course automatically.
Date:
Client:
Aladia
Industry:
EdTech
B2B & B2C SaaS
Services:
Data model design
Permission systems
The problem: built once, rebuilt everywhere
Every course had its own subjects. A teacher starting a new course had to recreate Mathematics, Italian and History from scratch. The Mathematics in one course had no connection to the Mathematics in another, and books or exams couldn't be linked to a subject at all.
Teachers had the same problem. A teacher could only be assigned to a subject inside one course. If they taught the same subject in eight courses, someone had to invite them eight separate times.
Who it affected
The person who felt this most was the academic coordinator, managing 12 courses and more than 50 subjects:
"I have Mathematics in 8 different courses. When a teacher goes on leave and I need to replace him everywhere, I have to do it 8 times."
The insight
A subject isn't a course-level idea. Mathematics is Mathematics wherever it's taught. The teacher is the same person, and the books and exams are the same resources.
Decision 1: Move subjects out of courses
Options I considered:
🔴 Keep subjects inside courses, and make copying them faster. Every copy would still drift apart, and the coordinator's problem would stay.
🟢 One shared Subject Area for each organization or freelance teacher. Create a subject once, assign its teacher, link books and exams, then add it to any course, and everything comes with it.
Creating a subject is deliberately light: a title, a teacher, an icon and a color. Subjects can also be organized by study level, like Mathematics for the first two years of a Liceo Scientifico, which matches how Italian schools actually teach.
One permission model everywhere: Subject Areas use the same four roles as Book Libraries and Exam Collections (Owner, Curator, Editor, Viewer), so teachers learn it once. And if someone can't do something, the action simply isn't there, instead of appearing disabled with an error.
Decision 2: One decision about who teaches what
The problem: a school may run dozens of courses, and the same teacher often teaches the same subject in many of them. The coordinator had to invite each teacher to each course by hand, and keep track of who was where.
The new rule: the coordinator assigns a teacher to a subject once, and the platform works out which courses they need to be in.
Three situations, three designed answers:
A subject is added to a course: its teacher is invited automatically.
⛔ An optional invite → ✅ mandatory, because a course teaching Mathematics without its Mathematics teacher is broken.The subject has no teacher yet: it still joins the course, so the coordinator isn't blocked while staffing is being decided.
A teacher is assigned later: the system shows every course that uses the subject and offers to invite the teacher to all of them at once. Otherwise the teacher would be missing from their classes, and nobody would notice until a class started.
This also solves the coordinator's leave problem: assigning a new teacher to the subject reaches every course that uses it, one change instead of eight.
Decision 3: Books and exams follow the subject
Once subjects lived outside courses, books and exams could be linked to them too. So adding a subject to a course could bring its content along.
Options I considered:
🔴 Add everything automatically. Fast, but teachers would lose control over their own course.
🟢 Ask one clear question at a time: "This subject has books. Do you want to add them to the course?" The same for exams. The teacher decides, so nothing is added without their say.
The same logic reaches down to lectures: when a subject with books is assigned to a lecture, the teacher can add all of them, choose some, or skip.
Now a fully built subject, with its teacher, books and exams, can be added to a new course in one action. The hard part wasn't the logic. It was making these moments feel helpful rather than interruptive.
Decision 4: One home for education content
Subject Areas, Book Libraries and Exam Collections work exactly the same way: reusable, linked, with the same roles.
Options I considered:
🔴 Three separate places in the navigation, one for each.
🟢 One Education tab, where teachers land once and branch into subjects, books or exams.
That's what makes them feel like one system instead of three tools. And it made the other features possible: the Book Library's subject links and the exams' subject context both depend on subjects living outside courses. Without this change, neither would have had anything to connect to.
The result
When a subject is added to a course:
the teacher is invited automatically in 82% of cases,
books are suggested in 67%,
exams in 54%.
Steps teachers used to forget now happen without them having to remember.
What I learned
None of these were features users asked for. They were friction I found by mapping the whole workflow, from subject to teacher to book to exam to course, and then designing the system to handle it quietly.
Sometimes the most useful thing a designer can change isn't on the screen at all. It's the structure underneath it.
