Studia
At a glance
- Role
- Systems analysis, UI design, front-end
- Team
- 5 students
- Timeline
- 4 months · Feb to May 2025
- Platform
- Full-stack web application
Challenge
Connect academic administration and course activity without flattening their different responsibilities.
My contribution
I structured the use-case inventory and modeled registration and assessment states, then contributed UI foundations and selected role workflows.
Evidence boundary
This is a requirements-led systems case study, not a claim of research validation or measured product impact.
01 · Starting point
One academic journey was split across two product contexts.
As an HCMUS student, I moved between the university portal for administrative work and Moodle for course activity. InfoStudia began as an opportunity hypothesis: what if registration, schedules, course delivery, assessment, and records shared one role-aware product model?
Starting observation
One academic journey was split across two interface contexts.
Administration context
Academic portal
- Course registration
- Academic records
- Tuition
Course activity context
Moodle / LMS
- Learning materials
- Assignments and quizzes
- Announcements
InfoStudia concept
A shared course context with role-aware access.
- Registration connected to schedule
- Course activity in the same product
- Views shaped by responsibility
Fragmented context
A course appeared in more than one system.
Connected consequence
One action should change what comes next.
Different responsibility
The same data needed different controls.
02 · Requirements
Thirty use cases became five product capabilities.
The specification was comprehensive, but a numbered use-case list was too implementation-oriented to become navigation directly. I regrouped the functions around user goals and the shared academic objects they changed.
- 3+1
- Actors
- 30
- Specified use cases
- 5
- Capability groups
- 1
- Shared course object
Student, Lecturer, Academic Affairs, plus Guest
Primary and alternative flows
A portfolio-level product model
Different actions by role and state
| Capability | Representative use cases | Product meaning |
|---|---|---|
| Identity & access | Login, logout, profile, role control | Establish who can see and change each academic object. |
| Academic planning | Semester publication, registration, schedules | Connect institutional setup to the student's plan. |
| Course delivery | Materials, deadlines, course notifications | Keep teaching activity attached to the right course context. |
| Assessment & participation | Exams, grading, attendance, evaluation | Represent timed, review-dependent, and recoverable states. |
| Records & administration | Results, tuition, discipline, users | Preserve institutional records and governance over time. |
Evidence
Insight
Design response
03 · Dependencies
The product was one semester lifecycle viewed through different responsibilities.
Mapping the semester as a sequence exposed dependencies that a page inventory could not: an offering must exist before registration, registration changes schedule and access, assessment can wait for review, and closing the term must preserve the record.
Cross-role sequence
One semester, several responsibilities.
Scroll horizontally to follow the lifecycle on a smaller screen.
| Role | 01Plan | 02Register | 03Study | 04Assess | 05Result |
|---|---|---|---|---|---|
| Academic Affairs | Configure semesters and course offerings | Govern the published offering | Maintain semester and course context | Control assessment context | Control result visibility |
| System | Represent roles and offerings | Check capacity and credit limit | Update the student schedule | Autosave and auto-submit at expiry | Expose pending, hidden, or available state |
| Lecturer | Work from an assigned course context | No registration action | Manage course materials | Create and grade assessments | Publish or keep results hidden |
| Student | See published academic context | Select an open course | Use the updated schedule and materials | Complete the assessment | See an explicit availability state |
The navigation could group features. The lifecycle had to explain their consequences.
04 · Critical workflow
A single Enroll action concealed several business rules.
The documented flow required the system to show open offerings, validate the selection, handle full classes and credit-limit failures, support cancellation during the allowed period, and update the student's schedule after success.
Evidence
Insight
Design response
Interactive requirement trace
One enrollment action, five rule-driven outcomes.
The sample values are illustrative. The interaction is limited to the documented rules: registration availability, course capacity, credit limit, schedule update after success, and the cancellation window.
Alternative scenarios
Course offering
Software Architecture
4 credits
- Registration
- Active
- Capacity
- 21 / 32 enrolled
- Credit load
- 12 / 20 credits
- Cancellation
- Within permitted window
Ready to enroll. The registration period is active, capacity is available, and the resulting credit load stays within the limit.
Image placeholder · Registration
Image placeholder · Updated schedule
Documented rule
01Capacity
Registration must handle a course offering that is already full.
Interface implication: A full-capacity state needs a specific, visible reason.
Documented rule
02Credit limit
The system checks whether the selected load exceeds the allowed limit.
Interface implication: Credit totals and a blocking explanation need to accompany the action.
Documented rule
03Schedule update
A successful registration changes the student schedule.
Interface implication: Confirmation should make the resulting schedule change explicit.
05 · Permissions
One course stayed recognizable while responsibility changed.
Consistency did not mean giving every role the same course page. It meant preserving the course identity and system status while adapting metadata, navigation, actions, and table columns to each person's responsibility.
One course · Three responsibility views
The course identity stays fixed. Permissions change around it.
Switch roles to see how the same course object exposes the metadata and actions each responsibility requires.
Student view
Follow the assigned course, access learning activity, and review personal academic progress.
- Schedule
- Published class time
- Lecturer
- Assigned lecturer
- Learning
- Materials and assessments
- Records
- Attendance and grades
Permitted actions
Student responsibility view selected.
- Guest 01
- Public information and authentication
- Student 02
- Registration, schedule, courses, assessments, and records
- Lecturer 03
- Assigned courses, materials, assessments, attendance, and grading
- Academic Affairs 04
- Semesters, offerings, people, schedules, access, and notifications
Image placeholder · Student
Image placeholder · Lecturer
Image placeholder · Academic Affairs
These reserved frames keep the role comparison in place without publishing source screens. Guest remains in the role model, but the visual comparison focuses on the three authenticated operational roles.
| Role | Needs to understand | Permitted actions |
|---|---|---|
| Student | Time, lecturer, materials, deadlines, results | Learn, submit, attend, evaluate |
| Lecturer | Roster, materials, assessments, attendance | Publish, schedule, grade, communicate |
| Academic Affairs | Semester, capacity, staffing, course status | Configure, assign, publish, govern |
06 · Interaction logic
The screen was only one state in a longer transaction.
Assessment made the value of state modeling especially visible. Leaving the page, reaching the time limit, waiting for manual grading, or hiding a result all required different feedback and recovery, not one generic empty state.
Assessment state model
The interface must explain what happens before, during, and after an exam.
- Access01
Not available
The assessment cannot be started before it becomes available.
Availability is explicit
- Access02
Available
The student can enter the assessment within its defined window.
Start action is enabled
- Attempt03
In progress
Work is preserved while the student completes the assessment.
Autosaved
- Submission04
Submitted
Submission can be deliberate or triggered automatically when time expires.
Timer expiry → auto-submit
- Marking05
Awaiting grade
The attempt is complete, but a result is not yet available to the student.
Pending is not an error
- Visibility06
Result state
The result is shown as hidden or available rather than leaving an empty view.
Hidden / available
| Documented rule | Experience risk | Interface implication |
|---|---|---|
| Leaving mid-assessment preserves the current work. | A student cannot tell whether an answer is safe. | Show a persistent saved status and a clear resume path. |
| The system submits when the time limit ends. | Submission can feel unexpected or irreversible. | Keep time visible and warn before the transition. |
| Multiple choice can be automatic; written answers wait for review. | No immediate score can look like a failure. | Use an explicit awaiting-review state instead of a blank result. |
| Lecturers or Academic Affairs may hide a result. | Unavailable data can appear broken or missing. | Explain availability and who controls the next transition. |
07 · Delivery
Architecture turned backend behavior into interface obligations.
The coded course project used a React and MUI client with state and Axios layers, backed by NestJS controllers and services, Mongoose and MongoDB, plus storage and email integrations. That made permission, validation, latency, and failure part of the product design.
- 01
Presentation expresses intent
React and MUI render the role-specific navigation, forms, course workspaces, tables, and action states.
- 02
Application state preserves context
Client state and Axios carry the current role, request state, selected data, and feedback across the API boundary.
- 03
Services enforce business rules
NestJS DTOs, controllers, and services validate input, apply permissions, and coordinate academic operations.
- 04
Data and integrations close the loop
MongoDB preserves records while storage and SMTP support documents, images, password recovery, and notifications.
| Architecture concern | System responsibility | UX consequence |
|---|---|---|
| Role-based access | Authorize routes and operations by role. | Hide irrelevant actions and explain permission boundaries. |
| DTO and service validation | Reject invalid input without corrupting data. | Keep entered values and attach errors to the responsible field or rule. |
| MongoDB and Mongoose | Reflect one academic object across roles. | Show the same status consistently in student, lecturer, and admin views. |
| API, storage, and email | Complete work outside the immediate click. | Represent loading, success, failure, retry, and delayed notification. |
08 · Outcome
The strongest outcome was a coherent model, not a usability metric.
The team delivered a software design package and full-stack codebase spanning student, lecturer, and Academic Affairs work. The most defensible design outcome is the translation from operational rules into a structured role-based product.
What worked
Requirements became visible product structure.
Largest limitation
System correctness was not user validation.
Next iteration
Test the three highest-risk workflows first.
A complete feature list does not automatically create a coherent product.