Building Role-Based Student, Teacher, and Admin Experiences in EchoEd

A role-based product should involve more than hiding navigation links.

Students, teachers, and platform administrators have different goals, data needs, privacy constraints, and consequences attached to their actions. EchoEd’s recent UI/UX work separates these roles into three
canonical product areas:

• /learn for students
• /teach for teachers
• /admin for platform administrators

The attached demo videos show each experience in its current form.

Student Learn

The Student experience prioritizes continuation over navigation complexity.

The /learn home composes existing course, progress, badge, certificate, and learner-product APIs to show:

• The next governed learning action
• Current courses and progress
• Available learning
• Progress summaries
• Badges and certificates

Course overviews use a reusable curriculum component for units and lessons. Lesson entry still goes through the existing start-course and progress APIs, so the UI cannot bypass backend sequencing rules.

Final assessment submissions use a shared confirmation dialog. Lesson completion exposes saving and failure states rather than optimistically assuming persistence.

No backend contracts were changed for the Student phase.

Teacher Teach

The Teacher experience introduces a canonical route family:

/teach
/teach/classes
/teach/classes/:id
/teach/curriculum
/teach/courses/:courseId/preview
/teach/assignments
/teach/learners/:learnerId

The Teacher home focuses on classes, learner progress, and curriculum. Class detail composes existing section APIs into overview, roster, assignment, progress, and discussion views.

Learner detail is scoped through class-roster context. Assignment creation uses confirmation and preserves form values after API failures.

The UI does not expose persistent feedback, manual review, or destructive discussion moderation because those workflows do not yet have sufficiently scoped backend contracts.

Platform Admin

The Admin experience uses canonical routes for overview, users, organizations, courses, badges, and reports.

Important implementation decisions include:

• User lists omit unnecessary fields.
• Role mutations wait for API confirmation before updating the UI.
• Self-role changes and self-deletion are blocked in the interface.
• Destructive actions use exact consequence language.
• Organization visibility remains constrained by current membership-scoped APIs.
• Course oversight does not grant Content Studio authoring.
• Super Admin capabilities are based on verified authorization, not role-name assumptions.
• Unsupported moderation and lifecycle controls remain absent.

During seeded browser testing, the user-detail flow exposed a backend issue: FastAPI accepted the user ID as a string while SQLAlchemy compared it with a UUID column.

The repair typed detail and update parameters as uuid.UUID. We also moved the static /api/users/students route before /api/users/{user_id} so the dynamic route could not shadow it.

Regression tests now cover both behaviors.

Shared UX and Accessibility

All three areas reuse the same production foundations:

• Semantic design tokens
• Role-aware shell navigation
• Route guards
• Shared loading and state components
• Confirmation dialogs with focus trapping and restoration
• Keyboard-operable controls
• Visible focus indicators
• Reduced-motion behavior
• Semantic desktop tables
• Stacked mobile record layouts
• Legacy deep-link compatibility

The frontend improves presentation and workflow clarity, but backend authorization remains authoritative.

Current Verification

Frontend unit tests: 245 passing
Backend tests: 224 passing
Seeded Playwright scenarios: 3 passing
Production build: passing
Strict OpenSpec validation: passing

The Playwright suite currently covers the seeded Student workflow, the Platform Admin workflow, and rejection of an unauthorized Student deep link into Admin.

Known Gaps

Several workflows need stronger backend contracts before the UI can safely support them:

• Persistent teacher feedback
• Scoped teacher review
• Authenticated discussion moderation
• Platform-wide organization oversight
• Account suspension and restoration
• Administrative audit events
• Badge lifecycle management
• Explicit Super Admin permission inheritance
• Privacy-minimized Admin user response schemas

These are documented gaps, not frontend placeholders.

Community Review

I would value feedback from people working across education and software:

1. Do the boundaries between Learn, Teach, and Admin match real responsibilities?
2. Which Teacher information should be visible at class level versus learner level?
3. What information should a platform administrator never see in a broad user list?
4. Which workflows should receive deeper screen-reader and keyboard testing?
5. Which backend gap would you prioritize before expanding the next UI phase?

The Student, Teacher, and Platform Admin production phases are complete for EchoEd’s currently supported APIs.

The full UI/UX overhaul is still underway. Content Studio, organization-admin self-service, Community, parent, and viewer experiences remain outside these completed phases.