Three portals on one platform, for three roles that want opposite things: a learner who wants momentum, a professor who wants control, a supervisor who wants proof.
A corporate LMS usually solves for the administrator and lets the learner inherit whatever's left. Here the same data — batches, courses, chapters, tests, scores — has to serve three people whose questions barely overlap.
The design problem wasn't three sets of screens. It was one information model expressed at three grains: a student sees her next lesson; a professor sees the batch that's falling behind; a supervisor sees whether the programme is working at all.
The canvas is a warm off-white, not the usual cold grey — this is a place people spend an hour learning in, not a console they check. Crimson carries brand and active state. Every other colour in the interface belongs to a specific batch, so a learner recognises “React Batch” by hue before she reads the label.
This is the real build running below — click the rail: Dashboard, My Learning, Tests, Calendar, Notifications, TutorBot, Profile. Open a batch, take a test, watch a chapter.
Every enrolled batch carries its next lesson by name — “Context API Deep Dive”, 13 of 18 chapters — so the dashboard is a way back in, not a shelf to choose from.
Upcoming events show the days remaining, and a batch ending is styled as a deadline — red — while a test is neutral blue. Urgency comes from the calendar, not from nagging.
The one AI surface in the portal wears a visible gradient dot in the nav. A learner should always know when she's talking to a model rather than her supervisor.
The professor portal is a six-item rail with three deep authoring flows behind it. Supervisors inherit the same shell with creation removed and reporting promoted.
A batch is a course, a supervisor, a date range and a student roster picked from a pool. Four decisions that used to live in four unrelated admin pages, sequenced into one form with a live summary.
Question authoring, then a correction screen that moves through submissions one student at a time rather than presenting a spreadsheet of ungraded rows.
Professors build a reusable template of questions once; every batch reuses it. Comparable feedback across batches was impossible while every round was written from scratch.
The professor and supervisor portals exist as source rather than a runnable page, so this section maps them honestly instead of showing a mock-up of screens you can't click.
The student portal is the only one I'd defend as finished. The supervisor portal inheriting the professor shell was a delivery decision dressed as a design decision — it shipped three portals in the time two would have taken, but a supervisor's job is comparison, and comparison wants a layout of its own.
Role-based design is mostly restraint. The temptation is to give every role every capability behind permissions; the work is deciding what each role never has to see. That judgement, not the screen count, is what made three portals coherent.
Career prep for students 92 days from placement.