Product Design Case Study
Designing Inclusive Learning Hub
How a fragmented stack of five school systems becomes one inclusive platform — without asking any role to learn software built for someone else's job.
The Educational Challenge
Schools serving both general education and special education students typically run an LMS, a student information system, a curriculum platform, an IEP/504 compliance tool, and a separate therapy scheduling system — often from different vendors, on different logins, with no shared student record. The result isn't just inconvenience: accommodations documented in one system never surface in the classroom tool where a teacher is actually planning a lesson; a therapist's session note never reaches the general education teacher; a family gets a login for grades and a phone call for everything else.
The design challenge was to prove that a single unified platform — not a stack of integrations — could serve every role around a student without becoming a bloated, everything-app that serves no one well.
Stakeholder Analysis
Six roles orbit every student, each with a genuinely different job-to-be-done:
- Administrators need compliance visibility and operational oversight across the whole school in minutes, not days.
- Teachers need accommodations and progress data inside their instructional workflow — not a separate portal they have to remember to check.
- Families need plain-language answers to "how is my child doing," not a compliance document.
- Students need an accessible, motivating view of their own learning that respects their age without being childish.
- Paraprofessionals need fast, structured daily data collection — prompting levels and independence data, not a blank notes field.
- Therapists need caseload, scheduling, and service-minute compliance tools built for clinical practice, not repurposed classroom software.
The design principle that fell out of this analysis: one student record, six lenses — never six separate records.
UDL & Accessibility Design Philosophy
Universal Design for Learning shaped the architecture, not just the visual style. Every lesson template carries multiple means of engagement, representation, and action/expression as standing fields — not a special-education-only feature bolted onto a general-education product. The platform ships with a real, full-featured accessibility toolbar (text sizing, high contrast, dark mode, dyslexia-friendly font, adjustable line spacing, a reading-focus mode, reduced motion, and genuine text-to-speech via the browser's Web Speech API) available to every role, because accessibility that only exists for one persona isn't really built in.
UX Design Process
- Role-first navigation — a distinct, purpose-built side rail per role rather than one universal menu everyone has to filter mentally.
- Consistent app-shell — the same header (search, notifications, messages, role switcher, help), the same card/table/chart vocabulary, and the same accessibility toolbar everywhere, so switching roles never feels like switching products.
- Calm, healthcare-adjacent visual system — soft blue, teal, sage green, and warm coral accents that stay professional for staff-facing screens and slightly warmer for the student and family experience, without ever feeling clinical or childish.
- Explainable dashboards — every summary metric links to the specific students or records behind it, so a number is always one click from an action.
Information Architecture
Six role-based portals sit on top of three shared surfaces that every role can reach: a Student Profile with twelve tabs spanning academics, attendance, IEP/504, goals, accommodations, therapy, and behavior; a Course & Lesson experience that runs identically in-person, online, or blended; and a Scheduling view that switches between student, teacher, therapist, paraprofessional, and room perspectives — with automatic conflict detection across all of them. A single mock data layer (24 students, 6 teachers, 4 paraprofessionals, 3 therapists, 8 courses) powers every chart, table, and profile, so the same student tells the same story no matter which portal you're standing in.
Data Model Design
The hardest modeling decision was where special-education data lives. The design rejected a parallel "SPED system" in favor of attaching goals, accommodations, and therapy services directly to the same student record every role already queries — a teacher's gradebook, a therapist's caseload, and a parent's dashboard all read from the identical underlying goal object, just rendered differently. That single decision is what makes the "one flag becomes one coordinated response" user journey (see the Project Overview) possible without any manual re-entry between systems.
Compliance & Governance Considerations
- Plan timelines are first-class data — review dates, annual review dates, and days-remaining calculations drive the Administrator's "Attention Required" alerts automatically.
- Service-minute compliance is computed, not eyeballed — required vs. delivered minutes roll up from individual sessions to a therapist's caseload to a schoolwide compliance number.
- Family-facing language is translated — the parent portal never surfaces raw compliance terminology without a plain-language explanation alongside it.
- Privacy by design in the prototype — this demo keeps all data client-side with no real student information; a production build would add authentication, role-based access control, and audit logging.
Implementation Strategy
Presented as if to a school board or Ministry of Education audience. A four-stage rollout would de-risk adoption:
- Stage 1 — Data migration & governance: map existing SIS/IEP data into the unified model; establish access-control policy before any live use.
- Stage 2 — Staff onboarding by role: role-specific training (not one universal training) so each group learns only the portal built for their job.
- Stage 3 — Pilot cohort: one grade band, both general and special education populations, measured against baseline coordination gaps (missed accommodations, late service-minute reporting, family confusion).
- Stage 4 — Scale with a compliance gate: phased expansion, with each new site required to demonstrate the plan-review and service-minute dashboards are populated correctly before go-live.
Expected Impact
Illustrative figures for demonstration.
- Fewer missed accommodations — because they surface inside the lesson, not just the compliance file.
- Faster plan-review turnaround — automatic day-count alerts replace manual tickler files.
- Higher family engagement — a portal families can actually read tends to get used; the demo's mock trend shows engagement climbing from 61% to 75% over six weeks.
- Cleaner service-minute compliance reporting — computed automatically instead of reconstructed at audit time.
Future Enhancements
- Real backend & authentication — replacing the client-side mock data layer with a database and role-based auth.
- OneRoster / QTI-style interoperability — for SIS sync and standards-aligned assessment exchange.
- Explainable early-warning models — attendance, academic-risk, and service-minute prediction, always decision-support rather than autopilot.
- Native mobile companion — especially for the paraprofessional data-collection workflow.
A platform that connects to the practice
This design applies the same instructional-leadership and inclusive-education principles found across this portfolio — UDL, accommodation fidelity, and plain-language family communication — and packages them as a coherent, buildable product.
Professional Reflection
Designing this platform sharpened a belief that runs through my leadership work: systems fail students when they fragment the adults around them. The full first-person reflection → explores what this build demonstrates about leading inclusive, accessible edtech design.