School scheduling app UX/UI review
A hands-on UX/UI review of a school flex-period scheduling app, tested across the student, teacher, and admin roles and delivered as prioritized findings and recommendations.
- Role
- UX/UI review for a client
- Year
- 2026
- Status
- Delivered
- Links
- Nielsen heuristics
- Persona walkthroughs
- Live prototype testing
The engagement
A solo developer built a web app for flex periods: the stretch of the school day where students choose (or get assigned) where to go. Students reserve seats with teachers, teachers manage their rosters, and an admin view watches the whole period. The question was whether it was ready for real schools: what breaks, what confuses, and what is missing.
What I did
I tested the live app hands-on in all three roles, the way its real users would meet it. On top of that ran a Nielsen-heuristic audit through two lenses, a teacher's and a UX engineer's, plus first-person walkthroughs: a student trying to sign up in a hurry, a coordinator running the period day to day, and a principal looking for oversight. Every finding was verified against the live build before it went in the review, and anything that did not reproduce was dropped.
What the review surfaced
One blocking bug: a student could book the same time slot twice. One silent failure: a teacher adding a student who was already assigned elsewhere appeared to work but did nothing. A color system carrying too many meanings: the same green marked both "student chose this" and "teacher placed them here." And the finding that mattered most for adoption: there was no way for a teacher to pull students into their room, so most students defaulted into the catch-all space and the app read as optional. The structural recommendation: the single admin view was serving two different audiences, the coordinator who runs the period and the leadership team that needs oversight, and fully serving neither. I recommended splitting it into a coordinator console and a leadership dashboard.
The deliverable
A formatted written review: a standalone heuristic audit, findings grouped by the app's actual tabs so each one maps to a screen the developer can open, a priorities table, and a short list of open questions to settle in a follow-up call. Written to be actionable by a developer working alone.
Why a teacher's review
A decade of running classrooms means I test as the people who will actually use the product: the student with ninety seconds between classes, the teacher mid-period, the coordinator responsible for every student in the building. Pairing that with an engineering lens is the point of the service.