Product Owner + Frontend Workflow Lead

OAS

A multi-role university oral assessment administration system

Oral assessment administration system where I worked as Product Owner and led the core multi-role scheduling workflow. I owned requirement structuring, the most complex admin-examiner-student flow, and later refactoring and integration of the central scheduling page in a 12-person team.

Multi-role WorkflowProduct OwnershipTeam LeadershipClient-facing DeliveryNext.jsSpring Boot

Tech Stack

Next.jsSpring BootWorkflow UIScheduling LogicRole PermissionsAgile Delivery

Client-facing large-team project

OAS had to replace spreadsheet- and email-driven oral assessment administration with a workflow that could manage scheduling, examiner allocation, student booking, marking, and result release. The project also ran under changing requirements and large-team integration pressure.

Overview

OAS (Oral Assessment System) is a university oral assessment administration system designed for multi-role collaboration. I turned an assessment process that had been spread across email, spreadsheets, and manual coordination into one manageable, trackable workflow covering scheduling, examiner allocation, student booking, marking, and result release.

Problem Context

The real difficulty in university oral assessment administration is not simply finding a time slot. The process is not a straightforward one-to-many booking problem. Most common scheduling and booking tools are built around one organizer opening time slots for many people to choose from. Oral assessment administration is closer to a one-to-many-to-many coordination problem: course administrators need to create times and venues, examiners need to select the slots they can take under specific constraints, and those slots then become options that students can interact with and book. This means the system has to manage relationships across multiple roles, multiple slot groups, multiple examiners, and multiple venues rather than a single organizer serving multiple attendees.

As a result, real oral assessment administration often falls back to spreadsheets and manual coordination. That approach is flexible, but it also creates risks: scheduling conflicts, accidental edits, unclear permission boundaries, and administrative breakdowns right before exams. Coordinators also still need to handle student grouping data, rubric alignment, and final result transfer back into existing teaching platforms. OAS was built to replace that fragmented setup with one manageable and trackable multi-role workflow.

Scope

I carried two main workstreams in OAS.

The first was the product workstream. I handled requirement elicitation, requirement consolidation, feature prioritization, backlog management, sprint rhythm, client communication, and team alignment. I also turned the project’s epics, user stories, acceptance criteria, and Kanban structure into an executable delivery line.

The second was the core user-flow delivery workstream. I led the UI/UX and frontend integration of the system’s most important multi-role scheduling flow across admins, examiners, and students. This was one of the most central and most complex workflows in OAS.

What I Drove

This project moved forward in a 12-person team with a real client, and the requirements did not stay fixed. Role structure, CSV scope, scheduling behavior, and API shape all changed during development. On the product side, my job was not just to record requirements, but to keep turning post-workshop changes into a delivery line the team could estimate, track, and implement. That included epics, user stories, acceptance criteria, backlog structure, Kanban, and sprint rhythm, as well as breaking client changes back down into executable work so the team could keep moving in one direction instead of drifting into disconnected tasks.

On the engineering side, I led OAS’s core multi-role scheduling user flow. In this flow, admins create and manage timeslots, examiners choose the slots they can take under defined constraints, and admins then release bookable options to students. The work here was not just about screens. It was about interaction order, visibility rules, validation logic, and workflow boundaries across roles. Concretely, my scope covered timeslot management, examiner selection, publish and withdraw actions, and post-release protections such as capacity validation, slot locking, and restrictions on already-booked data. In the later stage, I also completed the integration work around batch creation, single creation, examiner assignment, publish, and withdraw so the workflow could properly connect to the backend, testing, and final showcase.

Key Decisions

With requirements continuing to shift, I chose to first organize features and workflows into epics, user stories, acceptance criteria, backlog structure, and sprint rhythm, instead of letting the team move directly through loosely defined tasks while the shape was still unstable. This added upfront alignment cost, but it gave the team a much clearer delivery direction while things were still changing.

The core of OAS was never the timeslot list itself. It was whether the workflow across admins, examiners, and students could actually hold together. I treated the problem as one complete workflow covering slot creation, examiner selection, release, and student booking, rather than as separate admin and booking screens. That made the system much closer to real oral assessment administration, but it also meant the frontend had to carry more role boundaries and state logic.

In this kind of administrative system, publishing is not just a button click. It is a state transition that changes what can and cannot be modified. I designed publish and withdraw as part of the main workflow and made post-release protections part of that same boundary. Once data had entered a student-affecting state, it could no longer be treated like a normal editable draft. This made the flow and validation logic more complex, but it also made the system behave in a way that is much closer to what real academic administration can accept.

Challenges

This project was not delivered under stable requirements. Role structure, CSV scope, scheduling behavior, and API shape all changed during development. The hard part was not that requirements changed. It was that after each client workshop, scope, workflow structure, and delivery priorities could all be rearranged. On the product side, my job was to quickly turn those changes into epics, user stories, acceptance criteria, backlog structure, and sprint rhythm so the 12-person team could continue moving along one product line rather than being repeatedly scattered by new requests.

The core flow I owned was not a single scheduling page. It was the interaction order and operational boundaries across admins, examiners, and students. Admins needed to create and manage slots, examiners needed to select slots under constraints, and students could only see bookable options after release. The flow also had to deal with venues, durations, examiner capacity, slot availability, and restrictions on data that had already affected students. The difficult part was not the number of screens. It was turning those role differences, state transitions, and action limits into a UI/UX model that was clear and operable.

This was a 12-person team project, and integration costs became high in the later stage. A relatively loose task-pickup style stopped scaling well into integration. Some outputs remained close to prototype level. At the same time, backend timing issues and ongoing requirement changes were still present. The hard part became closing the gap between partial screens and a workflow that could actually connect to backend state, validation logic, test scenarios, and showcase content. In the later stage, I kept filling in the integration logic around the main flow so the workflow could move from partial functionality to something genuinely deliverable.

Current Outcome

On the product side, I established and maintained OAS’s requirement and delivery structure so that even under changing requirements, the team still had clear priorities, rhythm, and executable scope.

On the delivery side, I led the implementation of OAS’s most important multi-role scheduling workflow, covering admin-side timeslot management, examiner selection, publish and withdraw actions, and the validation and protection logic that applies after release. That workflow could then properly connect to backend behavior, testing, and showcase scenarios.

By the final showcase stage, stakeholders were no longer seeing disconnected pages. They were seeing one complete product flow that could be followed and verified from scheduling and booking through marking and result presentation.

12-person

Team Context

PO + FE

Ownership

Scheduling

Core Flow

Explore more work

View all projects