Project Overview
Why Inclusive Learning Hub exists
A conceptual product design and front-end prototype exploring what happens when a school stops running five disconnected systems and starts running one.
The Problem
Inclusive schools run on disconnected systems
Most schools serving both general education and special education students stitch together a separate LMS, SIS, curriculum platform, IEP/504 compliance tool, therapy scheduling system, and analytics dashboard — often from four or five different vendors that don't talk to each other. A teacher can't see a student's accommodations inside the gradebook. A therapist's session notes never reach the classroom. A parent gets a login for the grade portal, a different login for the special-education portal, and a phone call for everything else. The people closest to the student — teacher, case manager, paraprofessional, therapist, and family — are working from different pictures of the same child.
That fragmentation isn't a technology footnote. It's the reason accommodations get missed, service minutes go undelivered, and families feel like they're managing the system instead of being supported by it.
Product Vision
One inclusive school system, six points of view
Inclusive Learning Hub unifies learning management, student information, curriculum, special education management, therapy scheduling, and school analytics into a single platform — built around Universal Design for Learning from the first wireframe, not retrofitted later. Every role sees the same student record, filtered through the lens their job actually needs: an administrator sees compliance and operations, a teacher sees instruction and accommodations, a therapist sees caseload and service minutes, a family sees plain-language progress. Same student. Same truth. Different view.
Target Users
Built for six roles, one school
Administrators
School and district leaders who need compliance visibility and operational oversight without living in spreadsheets.
Teachers
General and special education teachers who need accommodations and progress data inside their daily instructional workflow.
Parents & Families
Families who deserve a plain-language window into their child's whole school experience, not a jargon-filled compliance portal.
Students
Learners who benefit from an accessible, motivating, age-appropriate view of their own courses and goals.
Paraprofessionals
Support staff who need fast, structured tools for daily data collection — not a form built for someone else's job.
Therapists
Speech, OT, and counseling providers who need caseload, scheduling, and compliance tools built for clinical work.
Platform Modules
Five systems, unified
🎓 Learning Management
Blended courses, modules, lessons, assignments, discussions, grading.
🗂️ Student Information
Enrollment, attendance, scheduling, grades, one longitudinal record.
📚 Curriculum Management
Standards-aligned maps, pacing, content authoring.
🧩 Special Education Management
IEPs, 504s, goals, accommodations, compliance timelines.
🩺 Therapy Scheduling & Services
Caseloads, session notes, service-minute compliance, virtual sessions.
📈 School Analytics
Executive dashboards, early-warning indicators, explainable data.
Key Design Principles
What the design had to be true to
👁️ One student, one record
No parallel "SPED system" — support data lives inside the same profile every role already uses.
♿ Accessible by default
Accommodations, UDL, and a full accessibility toolbar are core architecture, not an add-on module.
🗣️ Plain language for families
Compliance terms are translated, not assumed — a parent shouldn't need a glossary to read their own child's dashboard.
🔍 Explainable, not a black box
Every dashboard shows the "why," not just the number — alerts link straight to the underlying evidence.
🔄 Delivery-model agnostic
Instruction works whether it's led by a certified teacher, a substitute, a paraprofessional, or the student alone.
🧩 Right-sized per role
Each portal shows only what that role needs to act on today — not a shared mega-dashboard.
UDL Approach
Universal Design for Learning, structurally
💡 Engagement
Choice boards, interest-based content, flexible pacing, and a "Choose How to Respond" pattern built into every lesson.
👁️ Representation
Video, transcript, read-aloud, and visual supports present every lesson in more than one format by default.
✍️ Action & Expression
Written, audio, video, and visual response options are a standing feature of the lesson template, not a special-case accommodation.
Built-In Accommodation Approach
Accommodations follow the student, not the paperwork
Rather than storing accommodations as a static PDF attached to a compliance record, Inclusive Learning Hub treats them as live data: a teacher's lesson planner shows exactly which supports a student needs before the lesson starts; a lesson page shows which accommodations are "active" for that student; a paraprofessional's data-collection form is built around prompting levels and independence data, not a generic notes field. The goal is that an accommodation written into a plan actually shows up in the moment it's needed.
Blended Learning Model
In-person, online, or both — same instructional core
Courses are modeled once and can be delivered in-person, asynchronously online, or in a blended rotation, without rebuilding content. This is deliberate: schools facing staffing shortages, itinerant therapy schedules, or students who need a flexible pace shouldn't need a second version of the curriculum. The Grade 7 ELA course in this demo runs the same three-module sequence whether Patricia Nguyen is teaching live, a substitute is covering the room, or Jordan is working through it independently with his paraprofessional's support.
Dashboard Strategy
Charts only where they change a decision
Every chart in this demo was chosen because it answers a specific question a role actually asks: "Which students need intervention today?" "Are we delivering the therapy minutes we owe?" "Is a family engaging with the portal?" Dashboards are layered — a summary card surfaces the number, a chart shows the trend, and an "Attention Required" or alert list turns the number into a specific, clickable next action on a specific student. No chart exists purely for visual density.
Sample User Journey
How one flag becomes one coordinated response
1. Teacher identifies a decline
Patricia Nguyen notices Jordan's Grade 7 ELA assignment completion is slipping.
2. Teacher dashboard flags the student
Teacher Dashboard → surfaces Jordan under "Students Requiring Intervention."
3. Teacher reviews the student profile
One click opens Jordan's full Student Profile →.
4. Teacher sees accommodations & attendance
The Accommodations and Attendance tabs show what's already in place and what's changed.
5. Teacher records an intervention
A note and a support task are logged from the Lesson Planner →, tagging in extra scaffolds.
6. Paraprofessional receives a support task
Priya Patel sees the new task on her Support Tasks → list the same day.
7. Therapist sees a relevant goal update
Emily Castillo reviews progress on the Communication goal from her Goals → view.
8. Parent dashboard reflects it, plainly
Maria Thompson sees an understandable update on the Parent Overview → — no jargon required.
9. Administrator sees status update
Michael Torres's Administrator Dashboard → reflects the intervention as logged, not lost.
Feature Matrix
Which modules serve which role
| Module | Admin | Teacher | Parent | Student | Para | Therapist |
|---|---|---|---|---|---|---|
| Learning Management (courses/lessons) | ✓ | ✓ | ✓ | ✓ | ✓ | – |
| Student Information (attendance/scheduling) | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Curriculum Management | ✓ | ✓ | – | – | – | – |
| Special Education Management (IEP/504) | ✓ | ✓ | ✓ | ✓ (age-appropriate) | ✓ | ✓ |
| Therapy Scheduling & Services | ✓ | ✓ (visibility) | ✓ | ✓ (visibility) | ✓ (carryover) | ✓ |
| School Analytics | ✓ | ✓ (class-level) | – | – | – | ✓ (caseload-level) |
| Accessibility Toolbar | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
Product Roadmap
Where this concept would go next
Phase 1 — This Prototype
Six role-based portals, a shared student profile, a blended course/lesson experience, and a scheduling demo — all on mock data, proving the interaction model.
Phase 2 — Real Data Layer
A real backend and database, authentication, and role-based permissions, replacing the client-side mock data layer.
Phase 3 — Interoperability
OneRoster/QTI-style integrations for SIS sync and state reporting, plus SSO for districts.
Phase 4 — Predictive Insight
Explainable early-warning models for attendance, academic risk, and service-minute compliance, always with a human decision-maker in the loop.
Technology Used
How this prototype was actually built
Vanilla HTML, CSS, and JavaScript — no build step, no framework, no backend — sharing the same design system as the rest of this portfolio (design-system.css + portfolio.js). A project-local mock data layer (mock-data.js) drives every chart, table, and profile from one source of truth, and a project-local engine (script.js) provides the app-shell, role-aware navigation, accessibility toolbar, scheduling/conflict logic, and reusable UI components. This keeps the whole demo fast, dependency-free, and easy to host as a static site — appropriate for a portfolio prototype whose purpose is to demonstrate product thinking and front-end craft, not to run a real school.
A note on what this is
Inclusive Learning Hub is a conceptual portfolio prototype designed and built by Dr. Barbara Z. Franks to demonstrate product design, UX architecture, and front-end engineering for inclusive school systems. It is not a production system, contains no real student data, and is not affiliated with any real school, vendor, or platform. All names, figures, and testimonials are illustrative.