CCU
Office of International Affairs Application System
A review system with clear information architecture at the intersection of case types and review roles, built to extend an existing Design System.
Role
Product Designer
Timeline
3 months | 2024
Skills
Adobe, Photoshop, Illustrator, HTML, CSS, JS
Impact
University-wide users covered.
Over four years, my company designed and launched seven university systems for Chung Cheng University, this being one of them.
Built on a scalable Design System that keeps operating logic consistent across systems.
Product Overview
One system within Chung Cheng University's system ecosystem, covering three case types under the Office of International Affairs: scholarship, study abroad, and non-degree exchange applications. Users include students and administrative staff across three review levels, department, college, and the international office. Review responsibilities at each level differ by case type.
System Ecosystem
These seven systems together serve 12,000+ users across the university. Six of them, VACS Cloud Software Platform, Student Assessment System, Staff Approval System, IP Allocation System, Office of International Affairs Application System, and Tuition and Fees System, share one scalable Design System.
Problem
Problem Identified
Fragmented Processes
Scholarship, study abroad, and non-degree exchange applications were originally processed separately, through paper forms or standalone online systems, with no unified digital workflow.
Inconsistent Review Content
Review processes were not standardized across case types. The same review role handled different content depending on the case type.
Goals
Unified System Integration
The three case types, previously handled separately, were consolidated into a single system. Interaction conventions and operating patterns from the existing Design System were retained, rather than introducing a separate, incompatible logic.
Precise Information Architecture
Each role sees only the cases and functions relevant to its responsibilities and review authority. Even where review processes differ, the information architecture reflects these differences accurately.
Solution
Role-based permissions are applied within each case type, automatically determining which review stages and functions the logged-in user can see. The underlying interaction pattern follows the existing Design System.
This structure also keeps interaction consistent across roles, so no case type requires an extra click to expand content. The decision anticipated staff moving between roles over time. The way the system works stays the same regardless of role, reducing the adjustment needed after a transfer.
Review is the core task for every role, so it appears without needing to expand anything. Announcements originally had a separate entry under each case type, but given how infrequently they were used, they were consolidated into a single shared entry, with case type selected through a dropdown in the main work area rather than repeating a low-use feature three times in the side navigation.
Role \ Case Type
Scholarship Application
Study Abroad Application
Non-Degree Exchange Student
Department
Department Review
Department Review
Department Review
College
College Review
-
-
International Office
International Office Review
Approved ListInternational Office Review
Partner Institution List Departure and Return RecordInternational Office Review
Design
Key statistics are visualized to accelerate administrative management and execution.
Case type serves as the top-level navigation structure. Role permissions determine which review stages and functions each case handler can see within each case type.
Complex case handling processes were digitized through the online system, reducing time-consuming manual administrative work.
The form was divided into sections and organized into chunks to reduce cognitive load.
Students can easily manage their submitted applications.
Reflection
A shared Design System does not scale by making every system look identical. It scales by preserving the consistency users experience directly: naming, interaction, and components. Information architecture is left to each system to define according to its own business complexity.
The International Office system is where this principle was put to the test. There is no standard answer for which dimension should structure the top level of the navigation; that decision has to come from the business logic itself. Case type determines the differences in the review chain. Placing it above role is what allows the information architecture to reflect the actual business logic.
This project showed me that shared rules keep systems consistent in appearance, but how each system should be understood still depends on designers and teams working through the decision together, arriving at a workflow that serves the user.