Designing a Scalable Admin System for the University’s Schedule of Classes
Role: UX Designer, owned the admin information architecture and interaction design
Timeline: 2 years
Core Team: PM, Business Analyst, 2 developers, Senior UX Designer, UX Researcher, Accessibility Product Owner
Overview
Project: Schedule of Classes (SOC) Admin System
Goal: Enable Registrar Staff to manage class schedule configuration without developer intervention.
Role: I owned the admin experience end to end, from information architecture through final screens. Our UX Researcher led interviews, and we shaped direction together as a team. I made the final design calls on structure and workflows.
Users: Registrar staff responsible for configuring how course information appears publicly
🚧 Key Challenges
Legacy systems and fragmented data sources
Tight engineering bandwidth and no existing design system
Designing an MVP for a small user base while planning for future scale
✅ The Solution at a Glance
Task-based interface organized around Registrar workflows
Self-service configuration without developer intervention
Scalable structure designed to support additional users and responsibilities
Project Background - An Essential Student-Facing System, Powered by Manual Work
USC's Schedule of Classes is a university-wide platform where students can explore available courses each semester. As the platform was being modernized, we had an opportunity to rethink how the Registrar's Office managed the information displayed publicly.
The existing process had several challenges:
Developer dependency: Even routine updates, such as adding a school or academic program, required a Jira ticket and developer intervention.
Operational delays: Registrar staff had to wait for developers to complete configuration changes.
Aging infrastructure: The existing platform was hosted on a legacy server scheduled for decommissioning.
Even small updates to the Schedule of Classes required developer intervention.
The Opportunity:
Design an admin system that enabled non-technical Registrar’s Office staff to manage SOC content confidently, reducing developer dependency, while remaining scalable and accessible over time.
Understanding Who Actually Owned the Workflow
(because we had interviewed the wrong users…)
Initially, we started our research by interviewing scheduling coordinators, who worked closely with course data. However, when we reviewed our findings with our business analyst, we discovered that they weren't the primary users of the new admin system. 😟
Scheduling coordinators were responsible for creating course data in the database, the Student Information System (SIS), while Registrar staff determined how that information appeared in the public Schedule of Classes.
This distinction changed our approach: Rather than designing around how course data was structured, we needed to design around the tasks Registrar staff would actually perform.
Organizing the Admin Experience Around Tasks, Not Data
Now that we knew who the real users are, this fundamentally changed who we were designing for and shifted the interface from data-driven structures to a task-based experience.
Early concept: data-based
Revised concept: task-based
Shifting From Data to Tasks
After reviewing the research with our UX Researcher and Senior UX Designer, I led the restructuring of the admin experience around the work Registrar staff needed to accomplish.
Early concepts reflected the underlying data structure, with fields for programs, prefixes, sessions, and courses. However, the Registrar staff were taking on completely new responsibilities previously handled by developers, and I wanted to simplify the workflow as much as possible.
We shifted toward a task-based interface organized around core workflows, making it easier for Registrar staff to identify where to begin and what actions they could perform.
Designing Around Registrar Workflows
We identified 5 core tasks that informed the information architecture:
View the current schedule configuration
Add new schools or programs
Edit existing schools or programs
Configure General Education courses
Manage recommended courses (deferred from the MVP)
💡 Takeaway
We chose a task-based structure because it:
Matched users' mental models: Organized navigation around recognizable responsibilities rather than technical data entities.
Reduced onboarding complexity: Helped Registrar staff take on unfamiliar responsibilities previously handled by developers.
Supported future growth: Established a structure that could accommodate additional administrative users and workflows over time.
Balancing Design Vision With Technical and Organizational Constraints
Working with engineers and business stakeholders, we made three key tradeoffs to deliver a sustainable MVP and balance usability, technical feasibility, and long-term maintainability.
🟠 Limited engineering resources → Material UI
Initial direction: Implement our designs using components from our preferred design library.
Technical constraint: A small engineering team, limited development capacity, and no established design system.
Our decision: Use Material UI rather than building custom components
Outcome: This helped us prioritize core workflows, maintain UI consistency, and reduce implementation and maintenance effort while working within Material UI's visual constraints.
🟠 Legacy data constraints → Rethinking GE filtering
Initial direction: Show only General Education (GE) prefixes when configuring GE courses, reducing unnecessary options.
Technical constraint: The Student Information System (SIS) did not reliably identify GE-related prefixes, so supporting this behavior would require custom filtering logic and ongoing maintenance.
Our decision: Keep all prefixes available, but make the selection searchable and identify GE-related prefixes with a “GE” or “Category” indicator.
Outcome: This preserved data integrity and predictable behavior while helping Registrar staff find relevant options.
🟠 MVP prioritization → Deferring Recommended Courses
Initial direction: Keep the Recommended Courses page from legacy SOC, featuring courses manually curated by schools and departments.
Constraint: The feature required ongoing admin maintenance despite low usage on the student-facing site.
Our decision: Defer Recommended Courses from the MVP, based on Google Analytics usage data and maintenance considerations.
Outcome: This allowed the team to focus on higher-impact workflows that supported day-to-day administrative needs better.
💡 Takeaway
Good product design isn't always about implementing the ideal interaction. It's about finding the best experience that remains usable, technically feasible, and sustainable over time.
Evolving My Approach to Accessibility
This project changed how I approached accessibility, from focusing on individual UI issues to considering accessibility earlier in the design process and across the system.
Accessibility in Practice
Working closely with developers and an accessibility product owner, I created implementation annotations covering:
Keyboard navigation: Tab and reading order
Semantic structure: Roles, labels, and headings
Alternative text: Appropriate use of image descriptions
Due to timeline constraints, the student-facing experience received more extensive accessibility testing, while the admin MVP underwent automated testing but limited manual review.
Impact and Outcomes
Enabling Admin Ownership
Before: Even small Schedule of Classes display changes required submitting Jira tickets and waiting on developer availability.
After: After launch, Registrar staff could manage SOC configuration directly, making updates independently without developer involvement. The design established a task-based system to accommodate future admin users.
2. Supporting Recovery Without Developer Intervention
Shortly after launch, the Registrar's Office accidentally activated the Summer 2026 term early.
Previously, correcting this would have required submitting a development ticket. Instead, staff were able to adjust the activation date directly in the admin system, restoring the intended schedule without developer intervention.
As our business analyst put it:
“I consider this a win for our new SOC admin interface.”
What I’d improve: Recovery worked, but the early activation shouldn’t have been that easy to trigger. Next time, I’d add a confirmation step that shows when a term will go live and what students will see, so prevention matters as much as recovery.
Design Lessons That Shaped How I Work Today
Designing beyond MVP for future scale
This project reinforced the importance of designing for future scale, even when delivering an MVP for a small number of users. I now consider how systems will grow over time, whether that be new users, new responsibilities, and edge cases, so foundational decisions don’t become constraints later.
Treating internal tools as real products
Designing an internal admin tool taught me that internal users deserve the same clarity and care as public-facing experiences. I approach admin interfaces with greater attention to clarity, prioritizing low cognitive load and recoverability, especially when users are taking on unfamiliar responsibilities.