WS1.4 — Candidate Navigation Structures

WS1.4 — Candidate Navigation Structures

Purpose: Full structural specifications for 3 navigation candidates. Each candidate includes a complete navigation tree, screen placement map covering all 35 current screens, new screens introduced, merged/eliminated screens, billing placement, secondary user considerations, opportunities, and implementation notes. Inputs: WS1.1 (framework analysis), WS1.2 (workflow maps), WS1.3 (pre-filter and hybrid formation), Capability Map, Interview Report Date: March 2026

How to Read This Document

Each candidate is a hybrid — a primary organizing framework augmented with borrowed elements from other frameworks (see WS1.3 for how each hybrid was formed). The specifications are detailed enough to walk through real workflows in WS1.5.

Notation:

• (NEW) — a screen or view that does not exist today; requires new development
• ← from [Section] — an existing screen moved from its current location
• (MERGED into X) — an existing screen whose functionality is absorbed into another screen
• [Tab] — a tab within a multi-tab entity page, not a standalone screen

Screen numbering: The 35 screens are numbered consistently across all three candidates to enable comparison. The numbering matches the master list in the task description and the Capability Map.

Candidate A: Domain-First with Rich Entity Pages

1. Organizing Principle

Navigation is organized around domains of responsibility — the seven areas the admin naturally thinks in when describing her work (Interview Q4): Student Management, Semester Management, Content, Scheduling, Teacher Management, Billing, and Reporting. Within each domain, key entities (students, semesters, TAs) have rich multi-tab detail pages that consolidate related data from across the system into a single view. Workflow concepts (semester setup checklist, sequenced close) appear as features within the Semester Management domain, not as standalone navigation items.

2. Full Navigation Tree

├── Dashboard (NEW — operational overview with alerts and phase prompts)
│
├── Student Management
│   ├── Students                                    ← from People
│   │   └── [Student Detail Page] (NEW — rich multi-tab profile)
│   │       ├── [Tab: Profile] — name, contact, level, TA, gender, semester, tags
│   │       ├── [Tab: Submissions] — all submitted assessments, review status, TA feedback
│   │       ├── [Tab: Payments] (NEW) — subscription status, Stripe data, payment history, family plan, scholarship/deferment
│   │       ├── [Tab: Appointments] — past and upcoming 1:1 sessions
│   │       ├── [Tab: Semester History] (NEW) — every semester enrolled, level per semester, pass/fail, electives
│   │       └── [Tab: Actions] — promote, reset progress, deactivate + cancel subscription, resend registration, set temp password
│   ├── Submissions (Assessments)                   ← from Program
│   ├── Promoted Students                           ← from Reports
│   └── Failed Sign Ups                             ← from Reports
│
├── Semester Management
│   ├── Semesters                                   ← from top-level
│   │   └── [Semester Hub Page] (NEW — rich multi-tab semester view)
│   │       ├── [Tab: Overview] — dates with inline documentation, status toggles, auto-transition controls (NEW)
│   │       ├── [Tab: Setup Checklist] (NEW) — content/config completion status per content type and level
│   │       ├── [Tab: Enrollment] (NEW) — student list for this semester with levels, statuses, filtering
│   │       └── [Tab: Close Workflow] (NEW) — gated sequence: EOC review → promotions → payment setup → deactivation
│   ├── Welcome Package                             ← from Settings
│   ├── Email Management                            ← from Settings
│   ├── Tags                                        ← from Settings
│   └── Operations (bulk actions)                   ← from Settings
│
├── Content
│   ├── Video Lessons                               ← from Program
│   ├── Resources                                   ← from Program
│   ├── Recordings                                  ← from Program
│   ├── Tutorials                                   ← from Program
│   ├── MCQ Questions                               ← from Program
│   └── Quizzes                                     ← from Program
│
├── Scheduling
│   ├── Calendar View (NEW) — unified view of all live sessions + 1:1 appointments across TAs
│   ├── Live Sessions                               ← from Program
│   ├── Upcoming Appointments                       ← from Appointments
│   ├── TA Schedules                                ← from Appointments
│   └── Holidays                                    ← from Appointments (merged: system holidays + live session holidays from Students Management)
│
├── Teacher Management
│   ├── Teaching Assistants                         ← from People
│   │   └── [TA Detail Page] (NEW — rich multi-tab TA view)
│   │       ├── [Tab: Profile] — name, contact, timezone, status
│   │       ├── [Tab: Schedule] — weekly availability, holidays, timezone-aware view
│   │       ├── [Tab: Students & Groups] (NEW) — assigned students, groups, submission review queue
│   │       └── [Tab: Performance] (NEW) — response times, review counts, student outcomes
│   ├── Teacher Assignment Criteria                 ← from Settings
│   ├── TA Reports                                  ← from Reports
│   └── Student Groups (NEW — surfaced from TA detail pages into nav)
│
├── Billing & Payments (NEW section)
│   ├── Payment Overview (NEW) — subscription health, at-risk accounts, failed payments, expiring subs
│   ├── Payments (transaction history)              ← from Reports
│   ├── Payment Plans                               ← from Settings
│   ├── Coupons                                     ← from Settings
│   ├── Family Plans (NEW) — replaces Google Sheet
│   └── Scholarships & Deferments (NEW) — replaces Google Sheet
│
├── Reporting
│   ├── Student Report                              ← from Reports
│   ├── Referrals                                   ← from Reports
│   ├── Specific Reports                            ← from Reports
│   ├── Student Composition (NEW) — new vs. repeat vs. graduating breakdown
│   └── Logs                                        ← from Settings
│
├── Admin & System
│   ├── Admins                                      ← from People
│   ├── Settings (General)                          ← from Settings
│   ├── Notifications                               ← from Settings
│   └── Support Links                               ← from Students Management

3. Screen Placement Map

4. New Screens

5. Eliminated / Merged Screens

No screens are silently dropped. Every screen appears in the placement map. The "Students Management" grab-bag is the only screen that ceases to exist as a distinct page; its three tools are redistributed.

6. Hybrid Notes

7. Billing Placement

Student-level billing: The Student Detail Page includes a Payments tab showing subscription status, payment history (pulled from Stripe), family plan membership, scholarship/deferment flags, and actions (cancel subscription, adjust plan, apply coupon). The admin never leaves the student context for individual billing questions.

Aggregate billing: The Billing & Payments domain provides the Payment Overview screen (subscription health, failed payments, at-risk accounts), Payments transaction history (moved from Reports), Family Plans, and Scholarships & Deferments. This is the admin's billing command center for aggregate operations.

Billing configuration: Payment Plans and Coupons live in the Billing & Payments domain. They are configuration screens that define what checkout options exist, so they belong with billing operations rather than in a generic Settings catch-all.

Integration point: The Dashboard surfaces billing alerts (failed payments, expiring subscriptions) as tiles that link to either the Payment Overview or directly to the affected Student Detail Page's Payments tab.

8. Secondary User View

TA view: A TA logging in sees a reduced sidebar: My Students (their assigned students with submission review queue), My Schedule (their weekly availability and upcoming appointments), My Groups (their student groups), and Recordings (to review live session recordings). The 8-domain structure collapses to 4 items. The TA never sees Semester Management, Billing, Reporting, or Admin & System.

View-only admin: Sees the full sidebar structure but with action buttons disabled. Can browse all domains, view student profiles, review reports, and check billing data, but cannot create, edit, delete, or perform bulk operations. The domain labels provide discoverability — a view-only admin looking for "student payment status" can navigate to Student Management > Students > [student] > Payments tab using noun recognition alone.

Simplification mechanism: Role-based sidebar filtering. The navigation tree is the same structure; items are shown or hidden based on user_type. No dynamic restructuring, no phase changes — secondary users see a stable subset of the full nav.

9. Opportunities

1. Semester content cloning: The Semester Hub Page's Setup Checklist tab is the natural home for a "Clone from Previous Semester" action per content type. The checklist shows what was in the previous semester and offers one-click cloning. This directly addresses the admin's most dreaded task (Interview Q1, Q8).

2. Linked deactivation + subscription cancellation: The Student Detail Page's Actions tab can execute deactivation and Stripe subscription cancellation as a single action — currently a two-step process across two systems (Interview Q3).

3. TA workload balancing: The Teacher Management domain with its TA Detail Pages and Student Groups creates the data surface for a workload balancing view — see all TAs' student counts, response times, and submission backlogs side by side, enabling informed reassignment decisions.

4. Repeat student auto-assignment: Teacher Assignment Criteria moving to the Teacher Management domain puts it alongside the TA list and Student Groups, making it natural to add a rule for "assign repeat students to their previous TA" (Interview Q1).

5. Cross-semester student history: The Student Detail Page's Semester History tab creates the infrastructure for retention analytics — tracking which students return, which level they reach, and which semesters they drop out. This data currently requires manual tracking.

10. Implementation Notes

Nav-only changes (relocating existing screens to new sidebar sections):

• Video Lessons, Resources, Recordings, Tutorials, MCQ Questions, Quizzes → Content section
• Live Sessions → Scheduling section
• Upcoming Appointments, TA Schedules, Holidays → Scheduling section
• Tags, Welcome Package, Email Management, Operations → Semester Management section
• Teacher Assignment Criteria → Teacher Management section
• TA Reports → Teacher Management section
• Submissions → Student Management section
• Promoted Students, Failed Sign Ups → Student Management section
• Payments report → Billing & Payments section
• Admins, Settings, Notifications → Admin & System section
• Logs → Reporting section
• Support Links → Admin & System section

These are sidebar reorganization only — the screens themselves do not change. Estimated: 70% of the total placement changes are nav-only.

New development required:

• Student Detail Page (multi-tab with Stripe integration) — high effort, requires aggregating data from users, submissions, appointments, subscriptions, and Stripe API
• Semester Hub Page (multi-tab with setup checklist and close workflow) — high effort, requires enrollment views, content-status tracking logic, and gated workflow state management
• TA Detail Page (multi-tab with performance metrics) — medium effort, requires aggregating assignments, schedules, and review metrics
• Dashboard (alert logic and phase prompts) — medium-high effort, requires alert detection logic for failed payments, TA response times, submission pacing
• Payment Overview, Family Plans, Scholarships & Deferments — high effort, requires Stripe API integration and new data models
• Calendar View — medium effort, requires aggregating live sessions and appointments into a calendar UI
• Student Composition Report — low effort, queries on existing enrollment data

Candidate B: Hub-and-Spoke with Domain Sections

1. Organizing Principle

The dashboard is the operational nerve center — the admin's default starting point every session. It surfaces exceptions, alerts, and phase-aware prompts that link directly to resolution contexts in domain-organized spoke sections. The spoke sections use a domain-based organization similar to Candidate A, but with standard list/detail pages rather than rich entity pages. The key difference from Candidate A is emphasis: the dashboard does the work of surfacing what matters, so the spoke sections can be simpler. The system tells the admin what needs attention; the admin resolves it.

2. Full Navigation Tree

├── HUB: Dashboard (NEW — operational nerve center)
│   ├── Alert: "X students falling behind on submissions" (NEW)
│   │   └── → links to filtered Students list with submission details
│   ├── Alert: "X TAs with >48hr response time" (NEW)
│   │   └── → links to filtered Teaching Assistants list with review queues
│   ├── Alert: "X failed payments this week" (NEW)
│   │   └── → links to Payment Issues list with student context
│   ├── Alert: "Year 2: X of Y appointments used this week" (NEW)
│   │   └── → links to Upcoming Appointments filtered to Year 2
│   ├── Tile: "Semester [phase]: X items remaining" (NEW — phase-aware)
│   │   └── → links to Semester Setup Checklist or Close Tracker
│   ├── Alert: "X app issues reported" (NEW)
│   │   └── → links to Issue Queue
│   ├── Tile: Student body snapshot — new vs. repeat vs. graduating (NEW)
│   └── Quick actions: Search student, View today's appointments, Send notification
│
├── SPOKE: Students
│   ├── Students (list + search + detail)            ← from People
│   ├── Submissions (Assessments)                    ← from Program
│   ├── Student Report                               ← from Reports
│   ├── Promoted Students                            ← from Reports
│   └── Failed Sign Ups                              ← from Reports
│
├── SPOKE: Semesters
│   ├── Semesters (list + detail with inline docs)   ← from top-level
│   ├── Semester Setup Checklist (NEW) — what's configured, what's missing
│   ├── Semester Close Tracker (NEW) — gated sequence for end-of-semester
│   ├── Welcome Package                              ← from Settings
│   ├── Email Management                             ← from Settings
│   ├── Tags                                         ← from Settings
│   └── Operations (bulk actions)                    ← from Settings
│
├── SPOKE: Content
│   ├── Video Lessons                                ← from Program
│   ├── Resources                                    ← from Program
│   ├── Recordings                                   ← from Program
│   ├── Tutorials                                    ← from Program
│   ├── MCQ Questions                                ← from Program
│   └── Quizzes                                      ← from Program
│
├── SPOKE: Scheduling
│   ├── Calendar View (NEW) — all live sessions + 1:1 appointments across TAs
│   ├── Live Sessions                                ← from Program
│   ├── Upcoming Appointments                        ← from Appointments
│   ├── TA Schedules                                 ← from Appointments
│   └── Holidays                                     ← from Appointments (merged with Live Session Holidays from Students Management)
│
├── SPOKE: Teachers
│   ├── Teaching Assistants (list + detail)           ← from People
│   ├── Teacher Assignment Criteria                   ← from Settings
│   ├── TA Reports                                    ← from Reports
│   └── Student Groups (NEW — surfaced from TA detail pages)
│
├── SPOKE: Billing (NEW section)
│   ├── Payment Overview (NEW) — subscription health, at-risk accounts, failed payments
│   ├── Payments (transaction history)                ← from Reports
│   ├── Payment Plans                                 ← from Settings
│   ├── Coupons                                       ← from Settings
│   ├── Family Plans (NEW) — replaces Google Sheet
│   └── Scholarships & Deferments (NEW) — replaces Google Sheet
│
├── SPOKE: Reports
│   ├── Referrals                                     ← from Reports
│   ├── Specific Reports                              ← from Reports
│   ├── Student Composition (NEW) — new vs. repeat vs. graduating
│   └── Logs                                          ← from Settings
│
├── SPOKE: Admin
│   ├── Admins                                        ← from People
│   ├── Settings (General)                            ← from Settings
│   ├── Notifications                                 ← from Settings
│   ├── Support Links                                 ← from Students Management
│   └── Issue Queue (NEW) — student-reported app issues

3. Screen Placement Map

4. New Screens

5. Eliminated / Merged Screens

6. Hybrid Notes

7. Billing Placement

Student-level billing: The student detail page (standard list/detail, not a multi-tab entity page) is enhanced with a payment status field showing current subscription status and a link to view the student's record in the Billing spoke. The student detail page does not embed full billing data inline — the admin clicks through to the Billing spoke for detailed payment investigation. The Dashboard's failed payment alert links directly to the affected student's billing record in the Billing spoke.

Aggregate billing: The Billing spoke houses the Payment Overview screen (subscription health, failed payments, at-risk accounts), the Payments transaction history (moved from Reports), Family Plans, and Scholarships & Deferments. The Dashboard's "X failed payments this week" alert links to the Payment Overview with the failed payments list pre-filtered.

Billing configuration: Payment Plans and Coupons live in the Billing spoke. They are adjacent to the aggregate billing views, so the admin can see existing plans while configuring new ones.

Key difference from Candidate A: Billing data is not deeply embedded in student profiles. Instead, the Dashboard surfaces billing exceptions, and the Billing spoke provides the detailed resolution context. The admin flow is: Dashboard alert → Billing spoke → resolution, rather than Student Profile > Payments tab.

8. Secondary User View

TA view: Sees a simplified sidebar: Dashboard (filtered to show only their own alerts — their response time, their students' submission status), My Students (their assigned students with submission review queue), My Schedule (their availability and upcoming appointments), My Groups. The hub model benefits TAs especially — a TA who checks the dashboard on login immediately sees "3 submissions awaiting review >48hrs" with direct links. No need to navigate.

View-only admin: Sees the full spoke structure with action buttons disabled. The Dashboard shows all alerts in read-only mode — useful for support staff who need to see system health but cannot act. Can navigate to any spoke for investigation but cannot modify data.

Simplification mechanism: Role-based filtering on both the hub (which alerts show) and the spokes (which sections are visible, which actions are enabled). The spoke labels are stable noun-based names, so secondary users can navigate by recognition. The hub adds value proportional to the user's responsibility level.

9. Opportunities

1. Proactive problem detection: The Dashboard's alert logic is the foundation for early intervention — failed payments caught on Day 1 instead of Week 3, TA response delays flagged at 48 hours instead of after the student complains. This shifts the admin from reactive to proactive, which no amount of reorganization alone can achieve.

2. Phase-aware operational guidance: Dashboard tiles that say "Semester close approaching: 4 items need attention" with direct links to the relevant screens provide temporal context without restructuring the navigation. The admin gets workflow guidance without a rigid wizard.

3. TA self-service: TAs with dashboard access can see their own performance metrics and submission backlogs, reducing the admin's load of monitoring TAs and sending reminders manually (currently tracked in Google Sheets).

4. Issue reporting pipeline: The Issue Queue in the Admin spoke, surfaced as a Dashboard alert, creates a new student-to-admin communication channel. Currently students email or message individually; this centralizes issue tracking and enables the admin to see patterns (e.g., "5 students reported video playback issues this week").

5. Configurable alert thresholds: The alert-driven model naturally supports configurable thresholds — "flag TAs after 48 hours" could become "flag TAs after 36 hours" without structural changes. This makes the system adaptable to evolving operational standards.

10. Implementation Notes

Nav-only changes (same as Candidate A — relocating existing screens to new spoke sections):

• All 35 screens are repositioned in the sidebar. The same set of screens moves to the same logical domains as Candidate A.
• The spoke sections are structurally identical to Candidate A's domain sections. Estimated: 70% of the placement changes are nav-only.

New development required:

• Dashboard alert system — high effort: requires alert detection logic (submission pacing calculation, TA response time tracking, Stripe webhook integration for failed payments), alert persistence, threshold configuration, and deep-linking to filtered spoke views. This is the single largest engineering investment in Candidate B.
• Semester Setup Checklist — medium effort: requires content-status tracking per type per level per semester.
• Semester Close Tracker — medium effort: requires workflow state management and gate logic.
• Calendar View — medium effort: unified scheduling calendar.
• Payment Overview, Family Plans, Scholarships & Deferments — high effort: Stripe API integration, new data models.
• Issue Queue — medium effort: new data model for student-reported issues.
• Student Composition report — low effort: queries on enrollment data.
• Enhanced student/TA detail pages (additional fields, not multi-tab rebuild) — low-medium effort: adding payment status and response time fields to existing detail pages.

Key difference from Candidate A: The dashboard alert system is the high-effort centerpiece. Entity detail pages are simpler (enhanced fields, not multi-tab rebuilds), trading depth for the intelligence layer on the dashboard.

Candidate C: Entity-Centric with Contextual Navigation

1. Organizing Principle

The interface is organized around three primary entities — Students, Semesters, and Teachers — each with a comprehensive multi-tab entity page where most admin work happens. An entity selector and global search are the primary navigation mechanisms. Cross-cutting concerns (Billing, Reports, Admin tools) have their own lightweight sections for aggregate work that does not attach to a single entity. The top-level navigation is minimal; depth lives on entity pages. The admin's question is not "what domain am I in?" or "what needs attention?" but "which student, semester, or TA am I working with?"

2. Full Navigation Tree

├── Dashboard (NEW — lightweight alert surface with entity quick-search)
│
├── Students (entity list → entity pages)
│   └── [Student Entity Page] (NEW — comprehensive multi-tab profile)
│       ├── [Tab: Profile] — name, contact, level, TA, gender, semester, tags
│       ├── [Tab: Submissions] — all submitted assessments, review status, TA feedback
│       ├── [Tab: Payments] (NEW) — subscription, payment history, Stripe data, family plan, scholarship/deferment
│       ├── [Tab: Appointments] — past and upcoming 1:1 sessions
│       ├── [Tab: Semester History] (NEW) — every semester, level, pass/fail, electives
│       └── [Tab: Actions] — promote, reset, deactivate + cancel subscription, resend registration, set temp password
│
├── Semesters (entity list → entity pages)
│   └── [Semester Entity Page] (NEW — comprehensive semester hub)
│       ├── [Tab: Overview] — dates with inline documentation, status toggles, auto-transition controls
│       ├── [Tab: Content Status] (NEW) — checklist of all content types with per-level upload status
│       │   ├── Video Lessons                        ← from Program (managed in semester context)
│       │   ├── Submissions (Assessments)            ← from Program (managed in semester context)
│       │   ├── Resources                            ← from Program (managed in semester context)
│       │   ├── Recordings                           ← from Program (managed in semester context)
│       │   ├── Tutorials                            ← from Program (managed in semester context)
│       │   ├── MCQ Questions                        ← from Program (managed in semester context)
│       │   └── Quizzes                              ← from Program (managed in semester context)
│       ├── [Tab: Enrollment] (NEW) — student list for this semester
│       ├── [Tab: Scheduling] — live sessions and session schedule for this semester
│       │   └── Live Sessions                        ← from Program (managed in semester context)
│       ├── [Tab: Automation] — email templates, tags, triggers for this semester
│       │   ├── Email Management                     ← from Settings (managed in semester context)
│       │   └── Tags                                 ← from Settings (managed in semester context)
│       ├── [Tab: Welcome Package]                   ← from Settings (managed in semester context)
│       └── [Tab: Close Workflow] (NEW) — gated sequence: EOC → promotions → payments → deactivation
│
├── Teachers (entity list → entity pages)
│   └── [TA Entity Page] (NEW — comprehensive TA hub)
│       ├── [Tab: Profile] — name, contact, timezone, status
│       ├── [Tab: Schedule] — weekly availability, holidays, timezone-aware view
│       │   └── TA Schedules                         ← from Appointments (managed in TA context)
│       ├── [Tab: Students & Groups] (NEW) — assigned students, groups, submission review queue
│       ├── [Tab: Performance] (NEW) — response times, review counts, student outcomes
│       │   └── TA Reports                           ← from Reports (managed in TA context)
│       └── [Tab: Assignment Rules]
│           └── Teacher Assignment Criteria           ← from Settings (managed in TA context)
│
├── Cross-Entity: Scheduling
│   ├── Calendar View (NEW) — all live sessions + 1:1 appointments across all TAs
│   ├── Upcoming Appointments                        ← from Appointments
│   └── Holidays                                     ← from Appointments (merged with Live Session Holidays from Students Management)
│
├── Cross-Entity: Billing (NEW section)
│   ├── Payment Overview (NEW) — subscription health, failed payments, at-risk accounts
│   ├── Payments (transaction history)               ← from Reports
│   ├── Payment Plans                                ← from Settings
│   ├── Coupons                                      ← from Settings
│   ├── Family Plans (NEW) — replaces Google Sheet
│   └── Scholarships & Deferments (NEW) — replaces Google Sheet
│
├── Cross-Entity: Reports
│   ├── Student Report                               ← from Reports
│   ├── Promoted Students                            ← from Reports
│   ├── Failed Sign Ups                              ← from Reports
│   ├── Referrals                                    ← from Reports
│   ├── Specific Reports                             ← from Reports
│   ├── Student Composition (NEW) — new vs. repeat vs. graduating
│   └── Logs                                         ← from Settings
│
├── Cross-Entity: Operations
│   └── Operations (bulk actions)                    ← from Settings (includes Level 0 promotion from Students Management)
│
├── Admin Tools
│   ├── Admins                                       ← from People
│   ├── Settings (General)                           ← from Settings
│   ├── Notifications                                ← from Settings
│   └── Support Links                                ← from Students Management

3. Screen Placement Map

4. New Screens

5. Eliminated / Merged Screens

Note: "ABSORBED" means the screen's functionality is embedded as a tab on an entity page. The underlying data and CRUD operations persist — the change is navigational context, not functionality loss.

6. Hybrid Notes

7. Billing Placement

Student-level billing: The Student Entity Page includes a Payments tab as a first-class tab, showing subscription status, full payment history (from Stripe), family plan membership, scholarship/deferment flags, and inline actions (cancel subscription, adjust plan, apply coupon). This is the deepest billing integration of any candidate — the admin sees everything about a student's financial relationship without leaving the student context.

Aggregate billing: The Cross-Entity: Billing section houses Payment Overview, Payments transaction history, Family Plans, and Scholarships & Deferments. This is for aggregate operations — "how many failed payments system-wide?" — that do not start from a specific student.

Billing configuration: Payment Plans and Coupons live in the Cross-Entity: Billing section. They are system-wide configuration items that don't attach to a single entity.

Key difference from Candidates A and B: In Candidate C, student-level billing is the deepest and most integrated of any candidate because the entity page is the primary workspace. The admin doesn't navigate to a Billing section and then find the student — they navigate to the student and find billing right there. The cross-entity Billing section is only for aggregate views and configuration, not for individual student billing work.

8. Secondary User View

TA view: Sees three items: My Entity Page (their own TA Entity Page showing profile, schedule, students/groups, and performance — read-only on performance), Student List (filtered to their assigned students, with each student linking to a read-only Student Entity Page showing submissions, profile, and appointments), and Dashboard (filtered to their own alerts only). The entity model works naturally for TAs because TAs are themselves an entity — their workspace is literally their own entity page.

View-only admin: Sees the full navigation structure with all entity pages accessible in read-only mode. The entity model is strong for view-only admins because the primary interaction pattern is reading and investigating, which is exactly what entity pages optimize for. A support staff member can pull up a Student Entity Page, see payments, submissions, appointments, and history, and answer the student's question without needing write access.

Simplification mechanism: Role-based entity page filtering. TAs see a subset of student entity page tabs (no Payments, no Actions). View-only admins see all tabs but no action buttons. The navigation structure is identical; the depth and actions available differ by role.

9. Opportunities

1. Search-first navigation for power users: The entity model with global search enables the fastest possible path to any student, semester, or TA. The admin types a name and is on the entity page in two actions (search, click). No section navigation, no sidebar traversal. This matches how the admin already works — she knows which student she needs; the system should get her there instantly.

2. Contextual cross-entity linking: A Student Entity Page can link to the student's TA Entity Page, which links to the TA's other students, which links to a student who has a similar issue. The entity model creates a navigable graph of relationships, enabling investigation patterns that sidebar navigation cannot support.

3. Semester-as-workspace for setup: The Semester Entity Page's Content Status tab transforms semester setup from "visit 8 separate content screens" into "work through tabs on one page." Content cloning, status tracking, and configuration all happen without leaving the semester context. This is the most consolidated setup experience of any candidate.

4. Student 360-degree view for support staff: A support staff member (view-only admin) can answer almost any student question — billing, submissions, appointments, semester status — from a single Student Entity Page. This reduces escalation to the primary admin for routine support queries.

5. TA self-management: A TA's entity page is a natural self-service workspace — they can see their schedule, their students, their performance metrics, and their submission review queue all in one place. If the admin grants limited write access (e.g., updating availability), TAs can manage their own schedules without admin intervention.

10. Implementation Notes

Nav-only changes (limited in Candidate C):

• Moving Admins, Settings, Notifications, Support Links to Admin Tools — sidebar-only change
• Moving Payments report, Referrals, Failed Sign Ups, Promoted Students, Specific Reports, Logs to Cross-Entity: Reports — sidebar-only change
• Moving Payment Plans, Coupons to Cross-Entity: Billing — sidebar-only change
• Moving Operations to Cross-Entity: Operations — sidebar-only change
• Moving Upcoming Appointments, Holidays to Cross-Entity: Scheduling — sidebar-only change

Estimated: Only 40% of placement changes are nav-only. The remaining 60% involve embedding existing screens as tabs on entity pages, which requires new page architecture even if the underlying CRUD interfaces are reused.

New development required:

• Student Entity Page (multi-tab with Stripe integration) — high effort: the most complex single deliverable across all candidates. Requires aggregating data from users, submissions, appointments, subscriptions, enrollment history, and Stripe API. Six tabs, each essentially a focused view of data from different backend services.
• Semester Entity Page (multi-tab with content management, enrollment, automation, setup checklist, close workflow) — very high effort: the most ambitious screen in any candidate. Embeds content management for 7 content types, email management, tags, welcome package, and a gated workflow. This is essentially a mini-application.
• TA Entity Page (multi-tab with schedule, groups, performance) — high effort: requires aggregating schedules, assignments, review metrics, and assignment rules.
• Global search with entity resolution — medium effort: search across students, semesters, TAs by name, email, or ID with type-ahead and entity-type filtering.
• Dashboard (lightweight alerts) — medium effort: simpler than Candidate B's hub because alerts are secondary navigation, not the primary workspace.
• Payment Overview, Family Plans, Scholarships & Deferments — high effort: same as other candidates.
• Calendar View — medium effort: same as other candidates.
• Student Composition Report — low effort: same as other candidates.

Candidate C has the highest total development effort. The three entity pages are each substantial engineering projects. However, they can be built incrementally — the Student Entity Page first (highest impact), then the Semester Entity Page, then the TA Entity Page — with the cross-entity sections available from Day 1 using nav-only changes.

Cross-Candidate Comparison: Key Structural Differences

Where the 35 Screens Land Differently

Structural Signatures

Settings Redistribution Across All Candidates

All three candidates fully dissolve the current 11-item Settings catch-all. Here is where each Settings item lands:

Students Management Grab-Bag Dissolution Across All Candidates

All three candidates dissolve the "Students Management" grab-bag (#14). Its three tools are redistributed identically:

Consolidated Improvements and New Capabilities

All three candidates introduce capabilities that do not exist in the current admin backend. The following is a summary of what's new, organized by capability rather than by candidate:

Count of new capabilities: 18 across all candidates. All three candidates introduce the same core improvements; they differ in where and how deeply each capability is integrated.

The fundamental question for WS1.5 is not "which candidate has the most features?" (they are largely equivalent) but "which candidate's structural emphasis produces the best workflow outcomes?" — specifically, which emphasis (domain organization, operational awareness, or entity depth) reduces screen-hopping, matches the admin's mental model, and accommodates billing most naturally across all 6 workflows.

Next Step

These three candidate structures are the input to WS1.5 — Workflow Walkthroughs, where each candidate will be evaluated by walking through the 6 mapped workflows from WS1.2. The walkthroughs will measure screen count, click count, information completeness, and context-switch frequency for each candidate, producing the quantitative comparison needed to select a final structure.