Reflection
What it means to design for the whole team around a child
A first-person look back at building Inclusive Learning Hub — what I learned about designing one product for six very different roles, and what this work says about leading inclusive, accessible school systems.
Starting from the student, not the department
Every edtech tool I've used or evaluated in eighteen years of K-12 and online leadership starts from a department: "the SIS," "the IEP system," "the LMS." I wanted to start somewhere else — from Jordan, a real-feeling seventh grader with strengths, an IEP, a paraprofessional, a speech therapist, and a mother checking in after work. Once I put one student at the center and asked "who touches this child's day, and what do they each actually need to see," the six-portal structure fell out almost on its own. The organizing question was never "what modules does the system have" — it was "who is standing around this kid, and are they looking at the same picture."
Why "one student, one record" was the whole design
The single hardest and most important decision in this build was refusing to create a parallel special-education data structure. It would have been easier, honestly, to bolt an "IEP module" onto a generic SIS. Instead, Jordan's goals, accommodations, and therapy minutes live on the exact same student object his teacher's gradebook reads from. That constraint made every other design decision harder — and made the product honest. If accommodations only lived in a compliance file, I'd be building the same fragmentation I was trying to fix, just with nicer visuals.
Designing for families, not around them
I've sat across the table from parents who nodded through an IEP meeting because the language made disagreement feel unqualified. That memory shaped the parent portal more than any UX pattern did. "Present levels" became "how Jordan's doing right now." "Service minutes" became a simple bar comparing what's owed to what's delivered. The rule I held myself to: if a plain-language rewrite would insult a parent's intelligence, I hadn't actually simplified anything — I'd just cut information. The goal was clarity, not simplicity for its own sake.
UDL and accessibility as infrastructure, not a feature flag
It would have been easy to build a nice general product and then add "an accessibility toolbar" as one more sidebar item. I deliberately built the toolbar into the shared engine every single page depends on, and built UDL's three principles into the lesson template itself rather than as an optional accommodation. That ordering — infrastructure first, feature second — is the difference between a school that has an accessibility statement and a school where accessibility is just how things work. I wanted the product to model the second one.
Designing six portals without designing six products
The temptation with role-based software is to let each portal drift into its own visual language, since each team asks for what they need in isolation. I fought that by building one shared app-shell — the same rail pattern, the same card and chart vocabulary, the same header — and only letting the accent color and the content change by role. A teacher and a therapist should feel like they're using the same product, just standing in a different room of it, not like they've opened two different apps that happen to share a login screen.
What this demonstrates about leading inclusive edtech
My doctoral research centers on how leadership behaviors shape outcomes for the adults inside a school system; this project is the same conviction applied to software. A platform that fragments the adults around a student — teacher, therapist, paraprofessional, family — will fragment that student's experience no matter how good any single feature is. Leading inclusive, accessible technology means insisting on the harder architectural choice (one record, not six) even when the easier path would ship faster. That's the same judgment call I'd bring to leading a school system, a curriculum team, or a product roadmap.
Where this goes next
The Project Overview lays out the roadmap toward a real backend, interoperability, and predictive insight. But the part I'd protect above all in any future build is the one that's hardest to see in a demo: the data model that refuses to separate a student's academic story from their support story.