Designing the Teacher Experience for a School Management SaaS
Designing the Teacher Experience for a School Management SaaS
Product Logo
Overview
Overview
GradeX is a SaaS platform built to centralize school operations across teachers, students, parents, and administrators. The platform supports core functions such as attendance tracking, grading, communication, inventory requests, and staff workflows.
While the platform was comprehensive, I was responsible for designing the teacher-facing experience: the dashboards, tools, and flows that support daily classroom management, grading, and communication.
This case study explores how we designed a system capable of handling dense, institutional data while remaining usable for teachers who do not have a technical background.
GradeX is a SaaS platform built to centralize school operations across teachers, students, parents, and administrators. The platform supports core functions such as attendance tracking, grading, communication, inventory requests, and staff workflows.
While the platform was comprehensive, I was responsible for designing the teacher-facing experience: the dashboards, tools, and flows that support daily classroom management, grading, and communication.
This case study explores how we designed a system capable of handling dense, institutional data while remaining usable for teachers who do not have a technical background.
Observation & Problem Statement
Observation & Problem Statement
The project started with a dense PRD from the product owner. It covered the major functional requirements they requested; multiple dashboards, digital grading tools, lesson management, inventory requests, and leave applications.
There was no existing product or visual foundation to build from. No UI, no design system, nothing. Everything started from zero.
To get grounded, we ran a competitive analysis of platforms like Schoology, Alma, and Edmodo. We looked for patterns, what worked, and what didn’t. Common issues stood out quickly: cluttered dashboards, inconsistent navigation, and interfaces that assumed too much tech literacy.
Using those insights and the stakeholder documentation, I mapped out two key personas for the teacher-facing side:
Main Teachers: Full access to dashboards, grading tools, analytics, and administrative features.
Substitute Teachers: A toned-down experience focused on attendance and lesson schedules.
One major takeaway was obvious after my research, teaching always comes first, software second. The finished product couldn’t feel like an extra job. It needed to blend into the background and support their workflows without friction.
The project started with a dense PRD from the product owner. It covered the major functional requirements they requested; multiple dashboards, digital grading tools, lesson management, inventory requests, and leave applications.
There was no existing product or visual foundation to build from. No UI, no design system, nothing. Everything started from zero.
To get grounded, we ran a competitive analysis of platforms like Schoology, Alma, and Edmodo. We looked for patterns, what worked, and what didn’t. Common issues stood out quickly: cluttered dashboards, inconsistent navigation, and interfaces that assumed too much tech literacy.
Using those insights and the stakeholder documentation, I mapped out two key personas for the teacher-facing side:
Main Teachers: Full access to dashboards, grading tools, analytics, and administrative features.
Substitute Teachers: A toned-down experience focused on attendance and lesson schedules.
One major takeaway was obvious after my research, teaching always comes first, software second. The finished product couldn’t feel like an extra job. It needed to blend into the background and support their workflows without friction.
Frame The Challenge
Frame The Challenge
The core issue with designing such a platform was balance. The product owner wanted depth and data density. We as designers wanted clarity, focus, and speed. We needed to find a way to balance our users needs with that of our employer.
To do that we had to answer four big design questions:
Dashboard Density: How do we show large amounts of information without overwhelming users?
Information Hierarchy: What’s critical right now versus what can stay tucked away?
Functional Parity: How do we maintain consistent navigation across roles with different permissions?
Scalability: How do we ensure every design decision holds up across desktop, tablet, and mobile?
GradeX needed to feel powerful, not complicated. Every screen had to have a reason for existing.
The core issue with designing such a platform was balance. The product owner wanted depth and data density. We as designers wanted clarity, focus, and speed. We needed to find a way to balance our users needs with that of our employer.
To do that we had to answer four big design questions:
Dashboard Density: How do we show large amounts of information without overwhelming users?
Information Hierarchy: What’s critical right now versus what can stay tucked away?
Functional Parity: How do we maintain consistent navigation across roles with different permissions?
Scalability: How do we ensure every design decision holds up across desktop, tablet, and mobile?
GradeX needed to feel powerful, not complicated. Every screen had to have a reason for existing.
Wireframes
Exploring Possibilities
Exploring Possibilities
To keep the teacher experience simple and approachable, I focused on three design pillars during ideation: Information Architecture, UX Writing, and Cross-Sectional Consistency.
Information Architecture: The teacher module alone had over fifty unique screens. I grouped similar tasks to cut redundancy, and used progressive disclosure to keep the interface light. Critical dashboards displayed the essentials, attendance, upcoming lessons, and performance trends, while deeper analytics stayed one click away. Each dashboard card worked like a quick-view summary, helping users access information without cognitive overload.
Intentional UX Writing: Because most teachers weren’t tech-savvy, the copy had to be as intuitive as possible. Every label, prompt, and message was rewritten sometimes with the help of AI for clarity. The interface and copy worked together to guide users through their flow naturally. Even error states were designed to inform, not confuse.
Cross-Sectional Consistency: Since different designers handled different user roles, consistency across every section was essential. We built a lightweight internal design system to align on layout grids, spacing, and interaction logic. Weekly syncs helped keep all sections; teacher, student, parent, admin visually and structurally coherent. Every section looked and behaved like part of the same product family, not a cobbled together set of screens.
To keep the teacher experience simple and approachable, I focused on three design pillars during ideation: Information Architecture, UX Writing, and Cross-Sectional Consistency.
Information Architecture: The teacher module alone had over fifty unique screens. I grouped similar tasks to cut redundancy, and used progressive disclosure to keep the interface light. Critical dashboards displayed the essentials, attendance, upcoming lessons, and performance trends, while deeper analytics stayed one click away. Each dashboard card worked like a quick-view summary, helping users access information without cognitive overload.
Intentional UX Writing: Because most teachers weren’t tech-savvy, the copy had to be as intuitive as possible. Every label, prompt, and message was rewritten sometimes with the help of AI for clarity. The interface and copy worked together to guide users through their flow naturally. Even error states were designed to inform, not confuse.
Cross-Sectional Consistency: Since different designers handled different user roles, consistency across every section was essential. We built a lightweight internal design system to align on layout grids, spacing, and interaction logic. Weekly syncs helped keep all sections; teacher, student, parent, admin visually and structurally coherent. Every section looked and behaved like part of the same product family, not a cobbled together set of screens.
Build
Build
Once the ideation phase was complete, I built high-fidelity prototypes of the teacher-facing experience.
The core components included:
Home Dashboard: A unified view of attendance, active lessons, and student analytics.
Class Management: Detailed student lists, grading tools, and performance insights.
Assignments & Exams: Setup, submission, and review tools for coursework.
Inventory Requests: Quick access to supply requests.
Leave Applications: A clean, two-step request and approval flow.
All designs were responsive and content-driven, the layouts adapted intelligently instead of just stacking components vertically. The goal was to make sure the platform was usable and easy at any breakpoint.
Once the ideation phase was complete, I built high-fidelity prototypes of the teacher-facing experience.
The core components included:
Home Dashboard: A unified view of attendance, active lessons, and student analytics.
Class Management: Detailed student lists, grading tools, and performance insights.
Assignments & Exams: Setup, submission, and review tools for coursework.
Inventory Requests: Quick access to supply requests.
Leave Applications: A clean, two-step request and approval flow.
All designs were responsive and content-driven, the layouts adapted intelligently instead of just stacking components vertically. The goal was to make sure the platform was usable and easy at any breakpoint.
Hi-Fidelity Designs
Stress Test & Refinement
Stress Test & Refinement
After I was done with the high-fidelity designs for the teachers section and my colleagues were done with their own sections, we conducted remote usability tests with teachers, substitute teachers, students, parents and administrators from 20+ schools.
We tested around real workflows: marking attendance, submitting assignments, approving leave, managing supplies, and tracking lessons.
Feedback was majorly positive. Teachers found the dashboards clear and intuitive, but mentioned fatigue when scrolling through dense tables. I addressed the issue by:
Introducing alternating row colours for easier scanning.
Increasing vertical spacing for breathing room.
Adding a “Quick Actions” panel to minimize clicks.
These refinements were added into the design system and implemented collaboratively with developers to maintain accuracy during hand-off.
After I was done with the high-fidelity designs for the teachers section and my colleagues were done with their own sections, we conducted remote usability tests with teachers, substitute teachers, students, parents and administrators from 20+ schools.
We tested around real workflows: marking attendance, submitting assignments, approving leave, managing supplies, and tracking lessons.
Feedback was majorly positive. Teachers found the dashboards clear and intuitive, but mentioned fatigue when scrolling through dense tables. I addressed the issue by:
Introducing alternating row colours for easier scanning.
Increasing vertical spacing for breathing room.
Adding a “Quick Actions” panel to minimize clicks.
These refinements were added into the design system and implemented collaboratively with developers to maintain accuracy during hand-off.
Results & Learnings
Results & Learnings
GradeX launched successfully at the end of the six-month development cycle. Although we no longer had access to post-launch metrics, user testing outcomes and stakeholder feedback validated the system’s usability and clarity.
Key Learnings & Takeaway:
Designing for educators = extreme simplicity. Their attention is limited, and any added friction kills adoption.
Dashboards should tell stories, not dump data. Sequence and hierarchy matter more than decoration.
A design system built mid-flight demands adaptability. The system had to flex across multiple user hierarchies without visual fragmentation.
Collaboration beats solo runs. Constant alignment with PMs, devs, and other designers kept the experience cohesive and reduced redundancy.
GradeX launched successfully at the end of the six-month development cycle. Although we no longer had access to post-launch metrics, user testing outcomes and stakeholder feedback validated the system’s usability and clarity.
Key Learnings & Takeaway:
Designing for educators = extreme simplicity. Their attention is limited, and any added friction kills adoption.
Dashboards should tell stories, not dump data. Sequence and hierarchy matter more than decoration.
A design system built mid-flight demands adaptability. The system had to flex across multiple user hierarchies without visual fragmentation.
Collaboration beats solo runs. Constant alignment with PMs, devs, and other designers kept the experience cohesive and reduced redundancy.
Closing Thoughts
Closing Thoughts
GradeX wasn’t just another dashboard project, it was a vertically integrated software that taught me and I’m sure the other members of the design team restraint. The success of the teacher-facing side came from prioritizing human attention, not visual flair. The real challenge wasn’t packing in features, it was making a complex institutional tool feel easy for teachers who’d rather be teaching than clicking through software.
GradeX wasn’t just another dashboard project, it was a vertically integrated software that taught me and I’m sure the other members of the design team restraint. The success of the teacher-facing side came from prioritizing human attention, not visual flair. The real challenge wasn’t packing in features, it was making a complex institutional tool feel easy for teachers who’d rather be teaching than clicking through software.