Case Studies

Gradisys

A role-based school management platform designed around the different workflows of students, faculty, program chairs, and registrars.

Role:
Product DesignFrontend Development
Timeline:
Late 2025–20266 months
Platform:
WebDesktop
Industry:
EducationB2B
fig 1. Gradisys at a glance — The four role-based portals as one school management product.
02

Context

Gradisys is a school management platform designed for Paranaque City College and its local government stakeholders. The current project includes a public college website and four role-based portals for students, faculty, program chairs, and registrars.

The project began with a need to make enrollment and related academic work more organized. Instead of treating enrollment, submissions, subject management, scheduling, faculty assignments, and academic records as separate screens, we approached them as parts of one connected system.

The current implementation is a functional frontend demo and remains approximately halfway through its intended scope. Backend integration, full system architecture, workflow validation, and pilot testing have not been completed. The longer-term direction is a modular product that could be adapted for other educational institutions.

fig 2. Role-based navigation — The navigation sidebars for the student, faculty, program chair, and registrar portals.
03

The Problem

The core challenge was creating one coherent product for people with different responsibilities, information needs, and levels of authority. A visual refresh of the college's older interfaces would not be enough. The system needed a clearer structure for academic work and a way for information to move between roles without forcing everyone into the same dashboard.

Users

Students focus on enrollment, submissions, subjects, and schedules. Faculty manage teaching schedules, assigned subjects, and student information. Program chairs coordinate subjects, faculty assignments, schedules, and conflicts across a program. Registrars manage registration and academic records at the institution level.

Constraints

The frontend needed to demonstrate a credible product direction before the backend, permission model, and full system architecture were complete. Requirements came through the product manager, client stakeholders, and contacts familiar with college operations; direct workflow validation with each role remains part of the next phase.

fig 3. Role & responsibility map — How each role participates in the connected academic workflows.
04

Role & Approach

Owned

I owned the product and interface direction and implemented the frontend demos. My work covered information hierarchy, role-specific portal composition, shared component patterns, responsive behavior, and browser-based iteration.

Contributed

I used a tight design and implementation loop: understand the role, establish information priority, explore the visual structure, build the working interface, then evaluate it in the browser. Real content, responsive behavior, and component constraints became part of the design review rather than implementation details discovered later.

Collaborated

I worked with a former colleague, other collaborators, and a product manager who maintained the client relationship. The product manager and contacts familiar with the college's operations translated stakeholder needs into requirements and institutional context.

Discovery

The initial product direction was informed by stakeholder requirements and operational knowledge from people connected to the college. Formal validation with students, faculty, program chairs, and registrars has not yet taken place, so the current portals should be treated as working product hypotheses rather than proven workflows.

fig 4. Design-implementation loop — From role requirements to hierarchy, interface, prototype, and iteration.
05

Key Design Decisions

01

Role-specific portals

Students, faculty, program chairs, and registrars participate in the same academic system, but each role owns different tasks and decisions. One generic dashboard would expose too much irrelevant information and flatten those differences.

Decision

Create a dedicated portal for each role, with its navigation and hierarchy organized around that user's responsibilities.

Why

A student needs a personal view of enrollment, subjects, and submissions. Faculty need teaching and student workflows. Program chairs need program-level coordination. Registrars need institution-level records and operational control. The product should share a system without sharing one hierarchy.

Tradeoff

Four portals require more design and maintenance than one dashboard. They also create a stronger dependency on clear data ownership, permissions, and handoffs between roles.

Result

The demo gives each role a focused entry point while keeping all four experiences within one Gradisys product family.

06

The Solution

The solution is a family of working role-based portal demos. Shared foundations give Gradisys a consistent product language, while each portal prioritizes the records, actions, and level of oversight its user needs.

fig 5. Student portal — The student portal stays personal and action-oriented, with enrollment, submissions, subjects, and schedules close at hand.
fig 6. Faculty portal — The faculty portal connects teaching schedules and assigned subjects with the students affected by that work.
fig 7. Program chair portal — The program chair portal widens the view to program-level planning, faculty assignments, and schedule conflicts.
fig 8. Registrar portal — The registrar portal supports denser institution-level work around registration and academic records.
07

System & Engineering

Design and implementation developed together. Building the demos in the browser exposed responsive behavior, information density, interaction states, and component reuse early. It also revealed when the visual foundation was not resolved enough, at which point I returned to the design canvas before continuing. The goal was not to replace design with code, but to create a tighter loop between workflow definition, focused visual exploration, implementation, and evaluation. Shared foundations support maintainability, while role-specific composition keeps the product useful for different responsibilities.

fig 9. Student dashboard — The student dashboard demonstrating Gradisys's shared layout and component foundations.
fig 10. Faculty load — The faculty load interface showing teaching assignments within the shared system.
fig 11. Program chair subjects — The program chair subject-management interface using shared product patterns.
fig 12. Registrar dashboard — The registrar dashboard applying shared foundations to institution-level work.
08

Outcome & Reflection

Delivered

Functional frontend demos for the public college website and the Student, Faculty, Program Chair, and Registrar portals. The implemented scope works in the browser for stakeholder demonstrations and represents approximately half of the intended project.

Results

The client selected our proposal over a competing team with an existing platform. The working demo turned broad institutional requirements into a product direction stakeholders could navigate and evaluate directly. This is an early project result, not evidence of production adoption or user outcomes.

Biggest Win

Showing that four distinct role experiences could operate as one coherent product, rather than presenting stakeholders with disconnected screens or static concepts.

Fell Short

Backend integration, full system architecture, permissions, workflow validation, and pilot testing remain unfinished. A planned pilot before the enrollment and class period did not proceed.

Learned

Multi-role design starts with responsibility, not dashboards. I need to understand what each role owns, what information it needs, which decisions it can make, and where its work affects another role. The interface follows from those relationships.

Would Improve

If work resumed, I would first validate the enrollment workflow and its handoffs with actual users. I would then formalize permissions, statuses, exception cases, and information architecture before expanding the interface. In parallel, I would establish a clearer design foundation so shared components and role variants follow deliberate rules rather than emerging screen by screen.

How It Influenced My Work

Gradisys sharpened how I use frontend implementation as a design tool. A working interface exposes real constraints early, but speed can make an unvalidated solution feel finished. The better process keeps the browser in the loop without skipping workflow research and validation.

09

Credits

Built in collaboration with Joie Medina and Neil Medina, who invited me to join their project team.

Gradisys proved a credible product direction: one academic system can support distinct role-based experiences without becoming four disconnected products. The next phase is to validate whether the workflows and shared foundations are as useful in practice as they are coherent in the prototype.