Book Libraries
Aladia had no concept of a book. Teachers could only attach files to individual lectures, one at a time. I designed a Book Library from zero: one place to upload, organize and reuse books across courses, lectures, subjects and live sessions.
Date:
Client:
Aladia
Industry:
EdTech
B2B & B2C SaaS
Services:
Content library design
In-lecture book reader
The problem: books were just attachments
Before the Book Library, a "book" on Aladia was just a file attached to a lecture. If a teacher needed the same textbook in three courses, they uploaded it three times. The copies had no link to each other, no details, and no connection to their subject. When the book was updated, the teacher had to remember every place it lived, and they always missed at least one.
Who it affected
A department head with over 200 teaching PDFs put it plainly:
"I have the same PDF uploaded 12 times across my courses. When I update it, I always forget at least one."
How I found the problem
I audited the existing workflow, mapped with the PM how books relate to subjects, teachers and courses, and watched teachers try to share one book across three courses. Every time, they uploaded a new copy.
Options I considered:
❌ A better upload button. It would make uploading faster, but teachers would still create copies.
✅ Make books real objects on the platform, living in a central library with their own details, subjects and team roles. Create once, link to any course.
This meant designing a new data model before any screen, following the same structure as Subject Areas and Exam Collections.
Decision 1: One place, one set of rules
The problem: books, subjects and exams all work in a similar way and connect to each other. If each had its own place and its own rules, teachers would have to learn three systems.
Options I considered:
🔴 A separate section for books, with its own permissions.
✅ Book Libraries in the Education tab, next to Subject Areas and Exam Collections, with the same four roles: Owner, Curator, Editor and Viewer.
Why: a teacher who understands one understands the others.
A detail I care about: when someone can't do something, the action simply isn't there, instead of showing as disabled with a warning. That makes the role system feel natural instead of bureaucratic.
Decision 2: Three paths, one form
The problem: teachers don't all have books in the same form. Some have a PDF, some can only point to a book for sale, and some write their own material.
What I designed: Add New Book opens with three paths that all lead to the same form:
Upload a PDF: the most common case.
Attach a purchase link: for copyrighted books that can't be shared as files. The teacher adds the ISBN and a link, and students see exactly which book to buy instead of nothing.
Create it manually: for teachers writing their own material.
Three small decisions that removed friction:
Cover images:
⛔ asking teachers to make a cover for every book would stall the flow.
✅ The system shows the first five pages of the PDF, and the teacher picks one as the cover with a single tap.Writing a book:
⛔ a new editor just for books.
✅ Reusing the Document Builder, the same editor used for exams. A teacher who has written an exam already knows how to write a book. AI sits inline on each block, like in Notion, not in a separate mode, so the teacher stays the author.Book details: teachers can type them in, or search by ISBN and have everything fill in automatically. Most teachers already know the ISBN of their books, so this became the most used route: 48% of books were added this way.
Decision 3: Let the connections come to the teacher
The problem: a book belongs to a subject, and a subject can have its own teacher. When adding a book to a course, teachers had to remember all these connections, and they usually didn't.
Options I considered:
🔴 Leave it to the teacher to add the related subject and invite the right people by hand.
🟢 Ask at the right moment, with one question at a time the teacher can accept or skip:
"This book belongs to a subject. Should that subject be added to the course too?"
"That subject has a teacher. Should they be invited?"
It works the other way round too: when a teacher adds a subject to a lecture and that subject already has books, the system asks: "This subject already contains books. Do you want to add them to your lecture?" The teacher can add all, pick some, or skip.
Page ranges per lecture: a textbook covers a whole year, but one lecture covers a few pages. So the teacher sets a page range for each lecture: chapter three this week, chapter four next. The book lives in the library once, and each lecture points to a different part of it.
What the student sees
All of this structure leads to one simple result for the student: the lecture page.
Every book assigned to the lecture appears there. Opening it launches the platform's built-in reader directly at the assigned pages.
🔴 Before: a 300-page PDF and a separate message saying which chapter to read.
🟢 Now: the teacher's decision arrives already applied.
From the student's side, the library, the subject links and the page ranges are invisible. There's a lecture, and the right reading is in it.
The result
The Book Library shipped as a completely new part of the platform, connected to courses, lectures, subjects, calendar events and live sessions.
48% of books were added through ISBN search, the fastest route.
Teachers upload a book once and use it everywhere, instead of keeping 12 copies.
What I learned
Because this was something completely new, I had to create the mental model, the navigation and the permissions at the same time: library → book → course → lecture → page. Once that structure was clear, every screen could follow from it.
Three lessons stayed with me:
For something new, the concept has to come before the interface.
Permissions feel natural when people simply don't see what they can't do.
A good default does more than a good form. One optional ISBN field saved more effort than any layout change could have.
