OBAE - Course portfolio system used by 1,300+ lecturers

At the end of every semester, each lecturer has to prove that a course did what it promised. That means showing what students should be able to do, how it was taught, how it was graded, and what the results were. Usually this lives in Word files, spreadsheets and email. It is slow to collect and hard to check. Obae puts the whole thing in one web system. A lecturer sets the learning goals of a course, links them to the assessments, enters the grades, and gets a finished course portfolio they can print. More than 1,300 lecturers now use it. I built the full system, from the data model to every screen.

My Approach 

I started from the order the work really happens in. A course has big goals. Those break into smaller goals. Each small goal is checked by an assessment. Each assessment gives a grade to each student. So I built the system as one chain, and every screen is one link in it. A lecturer moves from top to bottom and never has to think about where to go next.

The second decision was to not make anyone type what the university already knows. Courses, classes and students come from the campus system. Lecturers only add what the campus system does not have. With this many users, every field we remove is thousands of minutes saved.

Vision and Innovation

I wanted the portfolio to write itself. If the links in the chain are right, the final report is just the chain shown in a readable way. No one should copy numbers from one file to another. When a grade changes, the portfolio changes with it.

I also made the portfolio printable in two languages, because accreditation reviews often ask for both.

Identifying Unique Challenges

Different people need different things from the same data. A lecturer edits their own courses. A program head needs to see which portfolios are done and which are not. An admin looks after the data for the whole program. If everyone sees the same screen, the lecturer is lost and the program head cannot find the answer.

Scale made everything harder. 1,300 lecturers do the same task in the same few weeks, so the system gets busy all at once. Most of them are not technical, and there is no time to train each one. A confusing screen becomes a flood of questions. Grading was also a problem. A class can have dozens of students and several assessments, so typing each grade by hand is slow and easy to get wrong. And lecturers already have a campus account, so they will not accept another password to remember.

Resolving Complex Problems

Each role gets its own view of the system, built around its own job. The lecturer sees only their courses and their next step. The program head sees a monitoring page that shows progress across all courses. The admin sees the setup tools. Same data, different doors.

For grading, a lecturer can download a ready-made sheet for the class, fill it in, and upload it. The system checks it and saves the grades. They can still edit one grade by hand when needed.

For login, I connected the system to the campus account. A lecturer signs in the way they already do, and the system sends them to the right role.

For the busy weeks, I kept every page light and every step small, so a lecturer can finish one task quickly and leave. Because the campus data comes in automatically, there is less to type and less to get wrong.

Detailed Pages and Features

• Course goal setup: define the learning goals of a course and the smaller goals under them.

• Goal linking: connect each goal to the one above it and to the assessments that check it.

• Assessment setup: list the exams, assignments and projects for each course.

• Grading by sheet: download a class sheet, fill it in, and upload it back.

• Portfolio builder: pulls goals, assessments and grades into one report per course.

• Print in two languages: export the finished portfolio as a document.

• Program monitoring: shows the program head which portfolios are done.

• Campus data sync: brings in courses and classes so no one retypes them.

• Campus login with roles: one sign in, with the right screens for each person.

Architecture

The system is a standard web application with a clear split by role. Each role has its own set of pages, and each page does one job. The rules about who can see what live in one place, not spread across screens. That made it safe to add a new role or change a page without breaking the others, which matters when over a thousand people depend on it.

Conclusions

The lesson was that a report is only as good as the links behind it. My first plan was to design the final portfolio page. I got better results when I made sure each link in the chain was clean first. Once that was true, the report almost built itself. I also learned that at this scale, small things matter. One extra click, repeated 1,300 times, is a real cost. A good screen is one that fits the job of the person using it.