WS1.1 — Navigation Framework Analysis

Purpose: Deep analysis of six organizational frameworks for redesigning the QuranFlow admin backend navigation. Each framework is evaluated on its organizing philosophy, application to the current 35+ screen system, assumptions about the user, strengths, risks, affinity with the current structure, and natural opportunities. A comparison matrix at the end scores all six against key evaluation criteria.

Inputs: Admin Capability Map (35+ screens, 9 nav sections), Admin Navigation Interview Report (pain points, mental model, workarounds), Redesign Plan (framework descriptions)

Date: March 2026

Context: What We Are Reorganizing

The current admin backend has 9 top-level sections containing 35+ distinct screens:

DASHBOARD (1 screen) — passive system overview
SEMESTERS (1 screen) — enrollment period management
PROGRAM (8 screens) — Video Lessons, Submissions, Resources, Live Sessions, Recordings, Tutorials, MCQ Questions, Quizzes
PEOPLE (4 screens) — Students, Teaching Assistants, Admins, Students Management (a misnamed grab-bag)
REPORTS (7 screens) — Student Report, TA Reports, Payments, Promoted Students, Failed Sign Ups, Referrals, Specific Reports
APPOINTMENTS (3 screens) — Upcoming Appointments, TA Schedules, Holidays
SETTINGS (11 screens) — Notifications, Tags, Payment Plans, Coupons, Settings, Operations, Email Management, Welcome Package, Teacher Assignment Criteria, Logs, Support Links

The interview revealed that single admin workflows routinely span 5-9 screens across multiple sections, that the Settings section is a "catch-all" for misplaced items, that the Dashboard provides no actionable information, and that billing — the admin's biggest pain point — has zero backend presence.

Framework 1: Object-Based (Current State)

Principle

Object-based navigation organizes the interface around data types or database entities. Each top-level section corresponds to a noun — Students, Semesters, Lessons, Reports — and contains all CRUD operations for that entity type. The user navigates by asking "what kind of thing am I working with?" and then going to the section that houses that thing. This is the most common pattern in developer-built admin panels because it mirrors the underlying database structure: one table, one section.

Application to QuranFlow

This is the current state. The navigation maps almost directly to the backend's controller and table structure:

Students (the users table filtered by user_type=3) live under PEOPLE
Video Lessons (the lessonsnew / lessonsvideos tables) live under PROGRAM
Semesters (the semester table) are a top-level section
Appointments (the appointments table) are a top-level section

Representative items and their current placement:

Item	Current Section	Why it's here
Payment Plans	SETTINGS	It's a configuration entity (`payment_plans` table)
Welcome Package	SETTINGS	It's semester resource upload — but placed by exclusion, not logic
Teacher Assignment Criteria	SETTINGS	It's a rule set for TA matching — placed in Settings as catch-all
TA Schedules	APPOINTMENTS	It's schedule data for TAs — grouped with appointment data

Proposed Navigation Structure

├── Dashboard
│
├── Semesters
│
├── Program
│   ├── Video Lessons
│   ├── Submissions (Assessments)
│   ├── Resources
│   ├── Live Sessions
│   ├── Recordings
│   ├── Tutorials
│   ├── MCQ Questions
│   └── Quizzes
│
├── People
│   ├── Students
│   ├── Teaching Assistants
│   ├── Admins
│   └── Students Management (grab-bag)
│
├── Reports
│   ├── Student Report
│   ├── TA Reports
│   ├── Payments
│   ├── Promoted Students
│   ├── Failed Sign Ups
│   ├── Referrals
│   └── Specific Reports
│
├── Appointments
│   ├── Upcoming Appointments
│   ├── TA Schedules
│   └── Holidays
│
├── Billing (NEW)
│   ├── Subscription Overview (NEW) — student subscription list with Stripe data
│   ├── Payment Plans                ← from Settings
│   ├── Coupons                      ← from Settings
│   ├── Family Plans (NEW) — replaces Google Sheet tracking
│   └── Scholarships & Deferments (NEW) — replaces Google Sheet tracking
│
├── Settings
│   ├── Notifications
│   ├── Tags
│   ├── Settings (General)
│   ├── Operations
│   ├── Email Management
│   ├── Welcome Package
│   ├── Teacher Assignment Criteria
│   ├── Logs
│   └── Support Links               ← from Students Management grab-bag

How This Addresses Key Needs

This structure is the minimal-disruption option — it preserves the current layout and adds only where gaps exist. Billing gap (Q5, Q9): A new top-level Billing section is added, pulling Payment Plans and Coupons out of Settings and adding new screens for subscriptions, family plans, and scholarships. However, billing remains disconnected from student profiles — you still must navigate away from People to see payment data. Consolidated student profile (Q2): Not addressed. The Students detail page remains shallow; payment, appointment, and submission data live in separate sections. Semester setup fragmentation (Q1): Not addressed. Setup still spans Semesters, Program (8 screens), Settings (Welcome Package, Email Management, Tags, Teacher Assignment Criteria), and Appointments — the same 11+ screens across 4+ sections. Dashboard problem (Q6, Q7): Not addressed structurally. The Dashboard screen exists but the object model provides no mechanism for alert logic or contextual prompts — that would require bolting on capabilities foreign to the framework. Settings catch-all (Q6): Marginally improved. Payment Plans and Coupons move to Billing, but Welcome Package, Teacher Assignment Criteria, Email Management, and Operations remain in Settings despite belonging to other domains.

Assumptions About the User

The object-based model assumes the admin thinks in database terms: "I need to edit a student" or "I need to create a lesson." It assumes the user can decompose any task into its constituent data objects and knows which object to start with. It also assumes that tasks are simple enough to complete within a single object context — create a student, edit a lesson, view a report.

This assumption breaks down when tasks are relational rather than entity-scoped. Setting up a semester is not a "semester task" — it requires touching video lessons, submissions, resources, live sessions, quizzes, welcome packages, email templates, tags, teacher assignment criteria, and TA schedules. The object model forces the admin to manually traverse the object graph that the system does not expose.

Strengths

Simplicity and predictability. The structure is stable — sections do not change based on context, time, or phase. Any user can learn "students are under People" and that knowledge holds forever.
Developer alignment. The structure mirrors the code architecture, making it easy to add new features — a new table gets a new screen in its logical section. This is why the current system has 35+ screens without becoming architecturally incoherent, even if it is operationally painful.
Familiar to secondary users. TAs and view-only admins who rarely use the backend can navigate by noun recognition without understanding workflows.

Risks

Single workflows span 5-9 screens across sections. The interview confirmed this directly: semester setup requires touching screens across SEMESTERS, PROGRAM, SETTINGS, and APPOINTMENTS [Q1]. Student support requires jumping between PEOPLE, REPORTS, APPOINTMENTS, and external tools [Q2]. This is not an edge case — it is the primary operating mode.
The Settings section has become a dumping ground. Items like Welcome Package (which is semester content), Teacher Assignment Criteria (which is TA management), and Payment Plans (which is billing) are in Settings because they don't fit cleanly into any object-based section [Q6]. The object model produces orphans that accumulate in a catch-all.
No natural home for billing. The admin's single biggest pain point — payment and billing management [Q5, Q9] — is entirely absent from the backend. The object model would create a "Payments" section, but billing is inherently relational: it connects students, semesters, subscriptions, and external Stripe data. A flat object section would not solve the cross-referencing problem.
The grab-bag "Students Management" screen. This screen contains Level 0 promotion tools, Live Session Holidays, and Support Links Management — none of which are student management [Q6]. It exists because the object model had nowhere else to put these items.

Affinity with Current State

This is the current state. 100% of the existing structure survives because the framework describes what already exists. The question is not whether it survives but whether it should.

Natural Opportunities

Minimal. The object-based model does not naturally enable new capabilities — it enables new entities. Adding billing would mean adding a Billing section with CRUD screens for subscriptions, payment plans, and scholarships. But the model does not enable the relational capabilities the admin needs: seeing a student's payment status on their profile, linking deactivation to subscription cancellation, or surfacing failed payments on a dashboard. These require breaking the object-per-section boundary, which is exactly what the object model resists.

Framework 2: Domain-Based (From Interview)

Principle

Domain-based navigation organizes the interface around areas of responsibility — coherent bundles of activity that a role owner manages as a unit. Instead of grouping by data type, it groups by accountability: everything the admin needs for "student management" lives together, even if the underlying data spans multiple tables. The organizing question shifts from "what kind of thing is this?" to "whose job is this?" or "what part of the operation does this belong to?"

Application to QuranFlow

The admin proposed seven domains in interview Q4. Applying these to the current 35+ screens:

Student Management — everything that affects individual students:

Students list and profiles (from PEOPLE)
Student Report (from REPORTS)
Promoted Students (from REPORTS)
Submissions review (from PROGRAM — because submissions are a student activity, not "content")
Student payment/billing data (new — currently in Stripe/Sheets)

Semester Management — the container that governs enrollment and time:

Semesters (currently its own top-level section)
Welcome Package (from SETTINGS — it's onboarding content tied to a semester)
Email Management (from SETTINGS — automation emails are semester-scoped)
Operations / bulk actions (from SETTINGS — bulk promotions and registrations are semester events)
Tags (from SETTINGS — tags are created per semester)

Content — passive material students consume:

Video Lessons (from PROGRAM)
Resources (from PROGRAM)
Recordings (from PROGRAM)
Tutorials (from PROGRAM)
MCQ Questions and Quizzes (from PROGRAM)

Scheduling — all live interactions:

Live Sessions (from PROGRAM — moved because these are scheduled events, not passive content)
Upcoming Appointments (from APPOINTMENTS)
TA Schedules (from APPOINTMENTS)
Holidays (from APPOINTMENTS — plus Live Session Holidays from the grab-bag)

Teacher Management — everything about TAs:

Teaching Assistants list (from PEOPLE)
Teacher Assignment Criteria (from SETTINGS)
TA Reports (from REPORTS)
Student Groups (currently accessible only through TA detail pages)

Reporting — all analytics and exports:

Payments report (from REPORTS)
Failed Sign Ups (from REPORTS)
Referrals (from REPORTS)
Specific Reports (from REPORTS)
Logs (from SETTINGS)

Admin / Misc — system-level configuration:

Admins (from PEOPLE)
Settings (from SETTINGS)
Notifications (from SETTINGS)
Support Links (from the grab-bag)
Coupons and Payment Plans (from SETTINGS — or moved to a Billing domain)

Proposed Navigation Structure

├── Dashboard (NEW — rebuilt as operational overview)
│
├── Student Management
│   ├── Students                         ← from People
│   ├── Student Report                   ← from Reports
│   ├── Promoted Students                ← from Reports
│   ├── Submissions (Assessments)        ← from Program
│   ├── Student Billing (NEW) — per-student payment status, subscription, Stripe data
│   └── Failed Sign Ups                  ← from Reports
│
├── Semester Management
│   ├── Semesters                        ← from top-level Semesters
│   ├── Welcome Package                  ← from Settings
│   ├── Email Management                 ← from Settings
│   ├── Operations (bulk actions)        ← from Settings
│   ├── Tags                             ← from Settings
│   └── Semester Close Workflow (NEW) — promotion, payment setup, deactivation sequence
│
├── Content
│   ├── Video Lessons                    ← from Program
│   ├── Resources                        ← from Program
│   ├── Recordings                       ← from Program
│   ├── Tutorials                        ← from Program
│   ├── MCQ Questions                    ← from Program
│   └── Quizzes                          ← from Program
│
├── Scheduling
│   ├── Live Sessions                    ← from Program
│   ├── Upcoming Appointments            ← from Appointments
│   ├── TA Schedules                     ← from Appointments
│   └── Holidays                         ← from Appointments (merged with Live Session Holidays from Students Management)
│
├── Teacher Management
│   ├── Teaching Assistants              ← from People
│   ├── Teacher Assignment Criteria      ← from Settings
│   ├── TA Reports                       ← from Reports
│   └── Student Groups (NEW — surfaced from TA detail pages into nav)
│
├── Billing & Payments (NEW)
│   ├── Payment Overview (NEW) — failed payments, expiring subscriptions, past-due accounts
│   ├── Payment Plans                    ← from Settings
│   ├── Coupons                          ← from Settings
│   ├── Family Plans (NEW) — replaces Google Sheet
│   ├── Scholarships & Deferments (NEW) — replaces Google Sheet
│   └── Payments (transaction history)   ← from Reports
│
├── Reporting
│   ├── Referrals                        ← from Reports
│   ├── Specific Reports                 ← from Reports
│   ├── Student Composition Report (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 grab-bag

How This Addresses Key Needs

Billing gap (Q5, Q9): Billing becomes a first-class top-level domain with its own section, housing Payment Plans and Coupons (moved from Settings), new screens for family plans, scholarships, and deferments (replacing Google Sheets), and a Payment Overview screen for at-a-glance billing health. Student-level billing also appears in Student Management, so the admin can see a student's payment status without leaving that domain. Consolidated student profile (Q2): Student Management groups Students, Student Report, Submissions, Promoted Students, and a new Student Billing screen. While these are still separate screens, they are now siblings in a single nav section rather than scattered across People, Reports, and Program. The foundation for a rich student profile is laid. Semester setup fragmentation (Q1): Semester Management groups Semesters, Welcome Package, Email Management, Tags, and Operations — all the configuration screens that previously lived in Settings. Content and Scheduling remain separate domains, so setup still touches 3 sections (Semester Management, Content, Scheduling) instead of 4+, and each section is more coherent. A Semester Close Workflow screen can enforce sequencing. Dashboard problem (Q6, Q7): The Dashboard is marked for rebuild as an operational overview, but the domain framework itself does not prescribe alert logic — this would need to be layered on (which is why Hub-and-Spoke is a natural complement). Settings catch-all (Q6): Fully dissolved. Every item from Settings moves to its logical domain — Welcome Package to Semester Management, Teacher Assignment Criteria to Teacher Management, Payment Plans to Billing, etc. The "Students Management" grab-bag is also eliminated: Level 0 promotion goes to Semester Management (Operations), Holidays merge with Scheduling, and Support Links go to Admin.

Assumptions About the User

The domain model assumes the admin thinks in terms of ownership areas — "I'm doing student stuff right now" or "I'm in semester mode." It assumes the user can reliably identify which domain a task belongs to and that domains are mutually exclusive enough that items don't feel like they belong in two places simultaneously.

This model matches a user who is a generalist operator — someone who wears multiple hats and switches between them throughout the day. The admin confirmed this mental model directly: she described organizing by "domains of responsibility" when asked how she would restructure navigation [Q4]. The key cognitive skill required is domain classification, not entity identification (object model) or task sequencing (workflow model).

Strengths

Direct match to the admin's stated mental model. This is the only framework the admin herself proposed [Q4]. Every other framework is an external imposition; this one emerged organically from how she describes her work. This is the strongest possible evidence for mental model fit.
Eliminates the Settings catch-all. Welcome Package moves to Semester Management. Teacher Assignment Criteria moves to Teacher Management. Payment Plans and Coupons move to Billing or Admin. The domain model dissolves the catch-all by providing legitimate homes for every orphan [Q6].
Separates Students and Teachers. The current PEOPLE section groups all user types together, but the admin explicitly treats student management and teacher management as different domains of responsibility [Q4]. A student issue and a TA scheduling issue are unrelated workflows that happen to share a database table.
Naturally accommodates billing as a new domain. Billing can be added as an eighth domain — or distributed across Student Management (individual payment status) and a dedicated Billing section (configuration, family plans, scholarships). Either way, it has a logical home [Q5, Q9].

Risks

Domain boundaries are subjective. Submissions are student activity and TA work and content-adjacent. Live Sessions are content and scheduling. Where an item lands depends on whose perspective you take. The admin's classification is clear, but a different admin might draw different boundaries.
Cross-domain workflows still exist. Semester setup touches Semester Management, Content, Scheduling, and Teacher Management — four domains. The domain model reduces section hopping (from 4+ current sections to 4 domains), but does not eliminate it. The improvement is incremental, not transformative [Q1].
Secondary users (TAs, view-only admins) may not share the domain model. A TA looking for "my students' submissions" would need to know that submissions live under Student Management, not under Content or a TA-specific area. The domain model is optimized for the primary admin's perspective [Redesign Plan, Candidate A risks].
Seven to eight top-level sections is a lot. While each section is more coherent than the current structure, the total section count is similar (9 currently vs. 7-8 proposed). The risk is that the reorganization feels like reshuffling rather than simplification if the section count doesn't drop.

Affinity with Current State

Moderate. The PROGRAM section largely survives as "Content" (minus Live Sessions and Submissions). APPOINTMENTS survives as "Scheduling" (plus Live Sessions). REPORTS partially survives as "Reporting" (minus items redistributed to Student and Teacher Management). SEMESTERS is absorbed into a richer Semester Management domain. PEOPLE is split into two separate domains. SETTINGS is dissolved entirely. Roughly 40-50% of the current placement survives; the rest moves to a more logical home.

Natural Opportunities

Semester Management hub. Grouping all semester-related configuration into one domain naturally enables a semester setup checklist — a single page showing what has been configured and what is still needed. This directly addresses the interview finding that semester setup requires 9+ screens across 4+ sections [Q1].
Teacher Management as a standalone domain. This naturally enables TA performance dashboards, workload balancing views, and centralized schedule management — capabilities the admin currently handles via Google Sheets [Q2].
Inline documentation per domain. Because each domain corresponds to a responsibility area, documentation can be structured around "here's everything you need to know about managing students" rather than scattered tooltips. This addresses the interview finding that navigation "lacks documentation and logic" [Q6].

Framework 3: Workflow/Task-Based

Principle

Workflow-based navigation organizes the interface around what the user is trying to accomplish. Instead of presenting a static menu of sections, it presents a menu of tasks or processes: "Set Up New Semester," "Handle Student Issue," "Close Semester and Promote." Each task is a guided sequence that brings the user through the relevant screens in the correct order, pre-populating context and eliminating the need to know where things live. The organizing question is not "what thing do I need?" or "what domain am I in?" but "what am I trying to do?"

Application to QuranFlow

The current 35+ screens would be reorganized into guided workflows. Representative task flows:

"Set Up New Semester" — a wizard-style sequence:

Create semester record (dates, name) with inline explanations of each date field
Clone or upload content (videos, submissions, resources, quizzes) — system shows what was in the previous semester and offers to copy
Configure live sessions and schedules
Set up welcome package
Configure automation emails with preview of triggers
Assign TAs and set criteria
Open registration
Checklist view showing completion status

This single workflow replaces what currently requires touching: Semesters, Video Lessons, Submissions, Resources, Live Sessions, Quizzes, Welcome Package, Email Management, Tags, Teacher Assignment Criteria, and TA Schedules — 11 screens across 4 sections [Q1].

"Handle Student Issue" — contextual investigation flow:

Search/select student
See consolidated profile (level, TA, submissions, payments, appointments, semester history)
Take action (promote, reset, deactivate, adjust payment)
Log resolution

"Close Semester / Promote Students" — sequenced end-of-semester process:

Review EOC assessment results
Handle edge cases (teacher discretion, threshold students)
Finalize promotion decisions
Set up payments for continuing students (after promotions, not before — addressing the interview pain point [Q3])
Deactivate departing students with linked subscription cancellation
Archive semester

"Manage Appointments This Week" — operational view:

Calendar view of all upcoming sessions across TAs
Flag conflicts and gaps
Reschedule or cancel inline

Proposed Navigation Structure

├── Dashboard (NEW — task launcher + active workflow tracker)
│
├── Semester Setup Wizard (NEW — guided multi-step flow)
│   ├── Step 1: Create/Edit Semester       (uses: Semesters)
│   ├── Step 2: Upload/Clone Video Lessons (uses: Video Lessons ← from Program)
│   ├── Step 3: Upload/Clone Submissions   (uses: Submissions ← from Program)
│   ├── Step 4: Upload/Clone Resources     (uses: Resources ← from Program)
│   ├── Step 5: Upload/Clone Tutorials     (uses: Tutorials ← from Program)
│   ├── Step 6: Upload/Clone MCQ Questions & Quizzes (uses: MCQ Questions, Quizzes ← from Program)
│   ├── Step 7: Configure Live Sessions    (uses: Live Sessions ← from Program)
│   ├── Step 8: Set Up Welcome Package     (uses: Welcome Package ← from Settings)
│   ├── Step 9: Configure Email Automation (uses: Email Management ← from Settings)
│   ├── Step 10: Set Up Tags               (uses: Tags ← from Settings)
│   ├── Step 11: Assign TAs & Criteria     (uses: Teacher Assignment Criteria ← from Settings, Teaching Assistants ← from People)
│   ├── Step 12: Configure TA Schedules    (uses: TA Schedules ← from Appointments)
│   ├── Step 13: Set Holidays              (uses: Holidays ← from Appointments)
│   └── Step 14: Open Registration — checklist summary + go-live
│
├── Student Support Flow (NEW — contextual investigation)
│   ├── Search/Select Student              (uses: Students ← from People)
│   ├── Consolidated Student View (NEW) — profile, submissions, payments, appointments, history
│   │   (merges data from: Students, Student Report ← from Reports, Submissions ← from Program,
│   │    Payments ← from Reports, Upcoming Appointments ← from Appointments)
│   ├── Student Billing View (NEW) — subscription, payment history, Stripe data
│   └── Take Action — promote, reset, deactivate + cancel subscription, adjust payment
│
├── Semester Close Workflow (NEW — sequenced end-of-semester)
│   ├── Step 1: Review EOC Assessments (NEW)
│   ├── Step 2: Handle Edge Cases (NEW) — teacher discretion, threshold students
│   ├── Step 3: Finalize Promotions        (uses: Promoted Students ← from Reports, Operations bulk promote ← from Settings)
│   ├── Step 4: Set Up Payments for Continuing Students (NEW — after promotions, not before)
│   ├── Step 5: Deactivate Departing Students (NEW — linked deactivation + Stripe cancellation)
│   └── Step 6: Archive Semester           (uses: Semesters)
│
├── Manage Appointments (NEW — weekly operations view)
│   ├── Calendar View (NEW) — all sessions + 1:1 appointments across all TAs
│   ├── Upcoming Appointments              ← from Appointments
│   ├── TA Schedules                       ← from Appointments
│   └── Holidays                           ← from Appointments
│
├── Daily Monitoring (NEW — reactive operations)
│   ├── Submission Review Queue (NEW) — TAs with >48hr backlog, students falling behind
│   ├── Payment Alerts (NEW) — failed payments, expiring subscriptions
│   ├── Recordings                         ← from Program
│   └── App Issue Reports (NEW)
│
├── Direct Access (fallback for ad-hoc tasks)
│   ├── Students                           ← from People
│   ├── Teaching Assistants                ← from People
│   ├── Admins                             ← from People
│   ├── Student Report                     ← from Reports
│   ├── TA Reports                         ← from Reports
│   ├── Payments (transaction history)     ← from Reports
│   ├── Failed Sign Ups                    ← from Reports
│   ├── Referrals                          ← from Reports
│   ├── Specific Reports                   ← from Reports
│   ├── Video Lessons                      ← from Program
│   ├── Submissions (Assessments)          ← from Program
│   ├── Resources                          ← from Program
│   ├── Live Sessions                      ← from Program
│   ├── Tutorials                          ← from Program
│   ├── MCQ Questions                      ← from Program
│   ├── Quizzes                            ← from Program
│   └── Students Management (grab-bag — tools redistributed to workflows)
│
├── Billing Configuration
│   ├── Payment Plans                      ← from Settings
│   ├── Coupons                            ← from Settings
│   ├── Family Plans (NEW)
│   ├── Scholarships & Deferments (NEW)
│   └── Subscription Overview (NEW)
│
├── System Admin
│   ├── Settings (General)                 ← from Settings
│   ├── Notifications                      ← from Settings
│   ├── Operations                         ← from Settings
│   ├── Logs                               ← from Settings
│   ├── Support Links                      ← from Students Management grab-bag
│   └── Email Management                   ← from Settings (also embedded in Semester Setup)

How This Addresses Key Needs

Billing gap (Q5, Q9): Billing is woven into workflows and has a persistent Billing Configuration section. Student Support Flow includes a Student Billing View with Stripe data. Semester Close Workflow includes payment setup as Step 4, sequenced after promotions (directly fixing the Q3 pain point). Daily Monitoring surfaces payment alerts proactively. Consolidated student profile (Q2): The Student Support Flow creates a Consolidated Student View that merges profile, submissions, payments, appointments, and semester history into a single investigation context — the most direct answer to Q2 of any framework. However, this view only exists within the workflow; ad-hoc access requires the Direct Access fallback. Semester setup fragmentation (Q1): Eliminated by design. The Semester Setup Wizard is a single 14-step guided flow that replaces the current 11-screen, 4-section journey. Content cloning is offered at each step. A checklist tracks completion. This is the framework's signature strength. Dashboard problem (Q6, Q7): The Dashboard becomes a task launcher and active-workflow tracker; Daily Monitoring captures the alert-driven items from Q7 (TA response times, failed payments, students falling behind). Together they replace the passive dashboard with an action-oriented surface. Settings catch-all (Q6): Fully dissolved. Every Settings item is absorbed into a workflow step (Welcome Package, Email Management, Tags, Teacher Assignment Criteria become steps in Semester Setup), a billing section (Payment Plans, Coupons), or System Admin (Settings, Logs, Operations, Notifications). The "Students Management" grab-bag is dissolved: Level 0 promotion becomes part of Semester Close Workflow.

Assumptions About the User

The workflow model assumes the admin's tasks are predictable, repetitive, and sequenceable. It assumes that most work can be decomposed into a finite set of known procedures, and that presenting tools in procedural order reduces errors and cognitive load. The user does not need to know the system's internal structure — only what they want to accomplish.

This model assumes a user who benefits from structure and guardrails. It is strongest for infrequent, high-stakes tasks (like semester setup, which happens a few times a year) and weakest for frequent, ad-hoc tasks (like checking a student's status, which is unpredictable and variable).

Strengths

Directly eliminates multi-screen workflows. The interview's most consistent finding was that single tasks span 5-9 screens [Q1, Q2, Q3]. A workflow model eliminates this by definition — the workflow is the unit of navigation, not the screen. Semester setup would become a single navigational act instead of 11 separate screens.
Solves the sequencing problem for semester close. The admin identified that Stripe payment setup happens before promotion decisions are finalized, causing cascading corrections [Q3]. A workflow can enforce the correct sequence: promotions first, then payments. The system prevents the error rather than relying on the admin to remember the right order.
Reduces the documentation burden. Each workflow step can include inline guidance about what the field does and what downstream effects it has. The admin requested "clear inline documentation explaining what each feature does and how it affects other processes" [Q9] — workflows are a natural container for this.
Accommodates content cloning naturally. The "Set Up New Semester" workflow is the natural place for a "clone from previous semester" action — it presents the choice at exactly the moment the admin needs it, rather than requiring the admin to navigate to each content type and remember to clone [Q1, Q8].

Risks

The primary admin is a power user who may feel constrained. She has deep institutional knowledge and navigates the current system rapidly despite its flaws. Guided wizards can feel patronizing to experts. The Redesign Plan explicitly flags this: "Power users may feel constrained" [1.3]. If the workflow is mandatory rather than optional, it may slow her down for tasks she can already do quickly.
Edge cases resist codification. The interview revealed that semester close involves teacher discretion overrides, students near submission thresholds, late submissions, and semester length variations [Q3]. These edge cases are handled through judgment calls, not standard procedures. A rigid workflow cannot accommodate every branching path without becoming a flowchart-style decision tree that is harder to maintain than the current system.
Ad-hoc tasks have no workflow. "Check what TA a student is assigned to" or "Look up how many scholarships we have this semester" are not tasks with predefined steps — they are lookups. A pure workflow model forces these into a workflow container or leaves them homeless. The admin's daily work includes a significant amount of ad-hoc investigation [Q2, Q7].
Maintenance cost is high. When processes change (and the interview shows they change — semester length varies, automation rules evolve, new edge cases emerge [Q3]), every workflow must be updated. This is more expensive than updating a data screen, because workflows encode sequencing and logic, not just layout.
No clear home for billing configuration. Billing touches multiple workflows (student support, semester close, daily monitoring) but is not itself a workflow. Payment Plans, Coupons, family plans, and scholarships are configuration data that needs a persistent home outside any single workflow [Q5].

Affinity with Current State

Low. Almost nothing survives in its current form. The 9 top-level sections disappear entirely, replaced by a set of task flows. Individual screens may persist as steps within workflows, but their navigation context changes completely. The admin would need to relearn how to find everything. The PROGRAM section's 8 screens would be disaggregated across multiple workflows (some in semester setup, some in daily monitoring). SETTINGS would be dissolved. REPORTS might survive as a standalone area for ad-hoc queries, but most reporting would be embedded in the workflows that produce the data.

Natural Opportunities

Semester setup checklist with progress tracking. A workflow naturally produces a completion state — "7 of 11 steps complete" — that the current system cannot provide. This would eliminate the "extensive double-checking" the admin currently does after semester setup [Q8].
Sequenced semester close. The correct order of operations (EOC review, then promotion decisions, then payment setup, then deactivation) can be enforced by the workflow, preventing the premature payment setup that currently causes cascading corrections [Q3].
Onboarding for new admins. If the primary admin is unavailable (vacation, transition), a workflow-based system is self-documenting — new users follow the steps rather than needing institutional knowledge. This addresses the implicit bus-factor risk of having a single admin with all system knowledge.

Framework 4: Phase-Based / Temporal

Principle

Phase-based navigation adapts the interface based on where the organization is in its operational cycle. For QuranFlow, this means the semester lifecycle: setup, active, and close. During each phase, the tools relevant to that phase are promoted to prominence — prominent placement, larger tiles, top of the sidebar — while tools irrelevant to the current phase are demoted or hidden. A persistent layer remains available for tasks that do not vary by phase. The organizing question is "what time is it?" — the system's temporal state determines what the admin sees.

Application to QuranFlow

The interview confirmed three distinct phases with distinct tool needs [Q1, Q2, Q3]:

Setup Phase (before semester start):

Semester configuration (dates, status, registration) — prominent
Content management (video upload, submission setup, resources, quizzes) — prominent
Welcome Package — prominent
Email Management (automation schedule) — prominent
TA Schedules and Assignment Criteria — prominent
Tags — prominent
Demoted: Student Report, TA Reports, Promoted Students, Submissions review (no submissions yet)

Active Phase (during semester):

Student profiles and support — prominent
Submissions review — prominent
Appointments management — prominent
TA schedules (view, not setup) — prominent
Dashboard with alerts (failed payments, TA response times, students behind) — prominent
Demoted: Semester configuration, Welcome Package, bulk operations

Close Phase (end of semester):

Student Report and EOC assessment — prominent
Promotion tools (individual and bulk) — prominent
Payment setup for continuing students — prominent
Deactivation workflow — prominent
Semester status transition — prominent
Demoted: Content upload, Welcome Package, registration settings

Persistent Layer (always available regardless of phase):

Student lookup and profiles
TA list
Admin accounts
Settings
Reports (some are relevant in any phase)
Billing / payment data (relevant across all phases)

Proposed Navigation Structure

The sidebar adapts based on the current semester phase. Items marked [prominent] are promoted to the top of the sidebar with visual emphasis during that phase. Items marked [demoted] are collapsed into a "More" group or shown with reduced visual weight. The Persistent Layer is always visible regardless of phase.

SETUP PHASE (before semester start):

├── Setup Checklist (NEW) — phase-aware progress tracker [prominent]
│
├── Semester Configuration [prominent]
│   ├── Semesters
│   ├── Welcome Package                  ← from Settings
│   ├── Email Management                 ← from Settings
│   └── Tags                             ← from Settings
│
├── Content Upload [prominent]
│   ├── Video Lessons                    ← from Program
│   ├── Submissions (Assessments)        ← from Program
│   ├── Resources                        ← from Program
│   ├── Recordings                       ← from Program
│   ├── Tutorials                        ← from Program
│   ├── MCQ Questions                    ← from Program
│   └── Quizzes                          ← from Program
│
├── Scheduling Setup [prominent]
│   ├── Live Sessions                    ← from Program
│   ├── TA Schedules                     ← from Appointments
│   ├── Holidays                         ← from Appointments
│   └── Teacher Assignment Criteria      ← from Settings
│
├── TA Assignment [prominent]
│   ├── Teaching Assistants              ← from People
│   └── Student Groups (NEW)
│
├── ── ── [demoted below fold] ── ── ──
│   ├── Student Report                   ← from Reports [demoted — no students yet]
│   ├── TA Reports                       ← from Reports [demoted]
│   ├── Submissions review               [demoted — no submissions yet]
│   ├── Upcoming Appointments            ← from Appointments [demoted]
│   └── Promoted Students                ← from Reports [demoted]
│
├── Persistent Layer (always visible — see below)

ACTIVE PHASE (during semester):

├── Dashboard (NEW — rebuilt with alerts) [prominent]
│   ├── Students falling behind (NEW)
│   ├── TA response time flags (NEW)
│   ├── Failed payment alerts (NEW)
│   └── Appointment utilization (NEW)
│
├── Student Support [prominent]
│   ├── Students                         ← from People
│   ├── Student Report                   ← from Reports
│   ├── Submissions (Assessments)        ← from Program
│   └── Student Billing (NEW) — per-student payment/subscription data
│
├── Scheduling [prominent]
│   ├── Live Sessions                    ← from Program
│   ├── Upcoming Appointments            ← from Appointments
│   ├── TA Schedules (view mode)         ← from Appointments
│   └── Holidays                         ← from Appointments
│
├── Content (view/edit) [standard]
│   ├── Video Lessons                    ← from Program
│   ├── Resources                        ← from Program
│   ├── Recordings                       ← from Program
│   ├── Tutorials                        ← from Program
│   ├── MCQ Questions                    ← from Program
│   └── Quizzes                          ← from Program
│
├── ── ── [demoted below fold] ── ── ──
│   ├── Welcome Package                  ← from Settings [demoted — setup complete]
│   ├── Email Management                 ← from Settings [demoted]
│   ├── Operations                       ← from Settings [demoted — no bulk actions mid-semester]
│   └── Semester Configuration           [demoted — already configured]
│
├── Persistent Layer (always visible — see below)

CLOSE PHASE (end of semester):

├── Semester Close Checklist (NEW) [prominent]
│
├── Assessment & Promotion [prominent]
│   ├── Student Report                   ← from Reports
│   ├── EOC Assessment Review (NEW)
│   ├── Promoted Students                ← from Reports
│   └── Operations (bulk promote)        ← from Settings
│
├── Payment Setup [prominent] — sequenced AFTER promotions
│   ├── Payment Plans                    ← from Settings
│   ├── Continuing Student Billing (NEW) — set up Stripe for next semester
│   └── Deactivation Workflow (NEW) — linked deactivation + subscription cancel
│
├── Student Support [standard]
│   ├── Students                         ← from People
│   ├── Submissions (Assessments)        ← from Program
│   └── Student Billing (NEW)
│
├── Semester Transition [prominent]
│   ├── Semesters — archive current, prepare next
│   └── Auto-Transition Trigger (NEW)
│
├── ── ── [demoted below fold] ── ── ──
│   ├── Content Upload                   [demoted — not uploading during close]
│   ├── Welcome Package                  ← from Settings [demoted]
│   ├── Recordings                       ← from Program [demoted]
│   └── Tutorials                        ← from Program [demoted]
│
├── Persistent Layer (always visible — see below)

PERSISTENT LAYER (always visible in all phases):

├── Students                             ← from People
├── Teaching Assistants                  ← from People
├── Admins                               ← from People
├── Billing & Payments
│   ├── Payment Overview (NEW) — failed payments, subscription health
│   ├── Payment Plans                    ← from Settings
│   ├── Coupons                          ← from Settings
│   ├── Family Plans (NEW)
│   ├── Scholarships & Deferments (NEW)
│   └── Payments (transaction history)   ← from Reports
├── Reports
│   ├── TA Reports                       ← from Reports
│   ├── Failed Sign Ups                  ← from Reports
│   ├── Referrals                        ← from Reports
│   └── Specific Reports                 ← from Reports
├── System
│   ├── Settings (General)               ← from Settings
│   ├── Notifications                    ← from Settings
│   ├── Logs                             ← from Settings
│   └── Support Links                    ← from Students Management grab-bag

How This Addresses Key Needs

Billing gap (Q5, Q9): Billing appears in the Persistent Layer (always available) with a full section including Payment Overview, Payment Plans, Coupons, Family Plans, and Scholarships. During Close Phase, billing is elevated to a prominent position for continuing-student payment setup. During Active Phase, the Dashboard surfaces payment alerts. This is the most contextually nuanced billing treatment — it adapts its prominence to when billing matters most. Consolidated student profile (Q2): Partially addressed. During Active Phase and Close Phase, Student Support groups Students, Student Report, Submissions, and a new Student Billing screen. These are co-located in the sidebar during the phases when student investigation is most frequent. However, a true consolidated single-page profile is not inherent to the framework. Semester setup fragmentation (Q1): Directly addressed. During Setup Phase, every screen needed for semester configuration is promoted to the top of the sidebar: Semester Configuration, Content Upload, Scheduling Setup, and TA Assignment. The admin no longer hunts across sections — the phase brings all setup tools together. A Setup Checklist tracks progress. Dashboard problem (Q6, Q7): During Active Phase, the Dashboard is the primary prominent element, rebuilt with the exact alerts from Q7: students falling behind, TA response times, failed payments, appointment utilization. The phase model naturally makes the dashboard prominent when its alerts are most actionable. Settings catch-all (Q6): Fully dissolved. Each Settings item is redistributed to its phase-relevant location: Welcome Package and Email Management to Setup Phase's Semester Configuration, Teacher Assignment Criteria to Scheduling Setup, Payment Plans to Close Phase and Persistent Layer Billing, etc. The "Students Management" grab-bag is dissolved: its tools are absorbed into the phases where they are used.

Assumptions About the User

The phase model assumes the admin's work is strongly correlated with the semester lifecycle — that the tools needed in week 1 of setup are fundamentally different from those needed in week 8 of active teaching, which are different from those needed during close. It assumes the admin will benefit from having irrelevant tools hidden rather than feeling disoriented by a changing interface.

This model assumes a user who works in distinct modes and who would appreciate the system "knowing" what they need. It is strongest for a single power user who understands the phases and weakest for secondary users who do not track the semester lifecycle and would be confused by navigation that changes on them.

Strengths

Directly reflects the admin's three-phase mental model. The interview structured the admin's pain points around setup [Q1], active semester [Q2], and semester close [Q3]. The admin naturally thinks in these phases — she described distinct tool needs for each. The phase model formalizes what she already does mentally: "It's setup time, so I need content upload tools."
Reduces cognitive load by hiding irrelevant tools. During active semester, the admin does not need to see semester configuration, welcome package setup, or bulk promotion tools. Hiding these reduces the number of items to scan in the nav, making it easier to find what is currently relevant. With 35+ screens, even good organization creates visual overload — the phase model addresses this through reduction, not just reorganization.
Naturally surfaces seasonal tasks. Semester close involves tasks the admin does 2-3 times per year. In the current system, these tools (promotion, deactivation, payment setup) are scattered and easy to forget. The phase model brings them forward exactly when needed, functioning as an implicit checklist [Q3].

Risks

Phases overlap in practice. The admin confirmed that semester close preparation begins while the current semester is still active [Q3]. The close phase and the setup phase for the next semester can overlap — the admin may be promoting students from the ending semester while uploading content for the new one. A strict phase model forces the admin to choose one phase, losing access to the other's tools, or maintains both simultaneously, negating the simplification benefit.
The system must know what phase it is in. This requires either automatic detection (based on semester dates) or manual toggling by the admin. Automatic detection is fragile — the interview revealed that semester status switching is already "manual and risky" and that "accidentally leaving an old semester active corrupts student profiles" [Q1]. Automated phase detection adds another layer of state that can go wrong. Manual toggling adds friction.
Secondary users would be confused by a changing nav. A TA who logs in during setup phase sees different tools than during active phase. A view-only admin reviewing reports might not see the report they need because it is "demoted" in the current phase. The phase model is optimized for the primary admin's workflow and potentially hostile to everyone else [Redesign Plan, Framework D risks].
Ad-hoc tasks are phase-independent. "Look up a student's payment status" or "check a TA's schedule" are needed in any phase. If these are in the persistent layer, the persistent layer becomes large, undermining the phase model's simplification benefit. If they are phase-dependent, the admin must switch phases to access them, adding friction [Q2].
Billing is not phase-specific. Failed payment follow-up happens during any phase. Payment plan configuration happens during setup and close. Student payment lookups happen during the active phase. Billing cannot be cleanly assigned to a single phase, making it an awkward fit [Q5].

Affinity with Current State

Low to moderate. The current structure is entirely phase-independent — every section is always visible. The phase model would require dismantling the current sections and reassigning every screen to a phase (or the persistent layer). Some current groupings would survive within a phase (the PROGRAM screens would largely map to setup phase), but the navigational container changes entirely. The persistent layer might resemble a simplified version of the current nav, but the overall experience would feel fundamentally different.

Natural Opportunities

Phase-aware dashboard prompts. Even if the phase model is not adopted as the primary navigation structure, the concept of phase-aware prompts is valuable. A dashboard that says "Semester close approaching: 4 items need attention" borrows from this framework without imposing its costs. This can be implemented as a feature within any other framework.
Automatic semester status transitions. The admin requested auto-activation/deactivation based on start date [Q1]. A phase-based system requires temporal awareness, which naturally produces the infrastructure needed for automatic transitions. Building the phase model forces the system to understand where it is in the lifecycle, enabling automation that the admin explicitly requested.
Seasonal onboarding. If the admin is training a replacement or delegating tasks, phase-based navigation says "here's everything you need to do right now" — a much smaller surface area to learn than "here's everything the system does."

Framework 5: Entity-Centric / CRM-Style

Principle

Entity-centric navigation starts from the premise that most admin work is centered on a specific entity — a particular student, a specific semester, a given TA. Instead of organizing by data type, domain, or task, the interface organizes around entity selection: the admin identifies who or what they are working with, and the system presents a comprehensive page showing everything about that entity. Each entity page is a mini-application with tabs or sections covering all related data — profile, submissions, payments, appointments, history. The organizing question is "who or what am I dealing with?"

Application to QuranFlow

The current 35+ screens would collapse into a small number of entity types, each with rich detail pages:

Student Entity Page (replaces parts of: Students, Student Report, Submissions, Payments, Appointments):

Tab: Profile — name, contact, gender, level, TA, semester, tags
Tab: Submissions — all audio submissions with status, review history, ability to delete/reset
Tab: Payments — subscription status, plan, payment history, coupon, scholarship/deferment flags (currently in Stripe/Sheets)
Tab: Appointments — all scheduled and past appointments, TA, rescheduling history
Tab: Semester History — every semester enrolled, level per semester, pass/fail, electives
Tab: Actions — promote, deactivate (linked to subscription cancel), reset progress, resend registration

Semester Entity Page (replaces parts of: Semesters, Video Lessons, Submissions, Resources, Live Sessions, Recordings, Tutorials, MCQ Questions, Quizzes, Welcome Package, Email Management, Tags):

Tab: Overview — dates, status, registration settings, with inline documentation of effects
Tab: Content Status — checklist of all content types with upload status per level (videos: 5/6 levels done, etc.)
Tab: Enrollment — student list for this semester with levels, statuses
Tab: Automation — email schedules, triggers, preview
Tab: Welcome Package — resources for onboarding

TA Entity Page (replaces parts of: Teaching Assistants, TA Schedules, TA Reports, Student Groups):

Tab: Profile — name, contact, timezone, status
Tab: Schedule — weekly availability, holidays, timezone-aware view
Tab: Students & Groups — assigned students, groups, submission review queue
Tab: Performance — response times, submission review counts, student outcomes

Cross-cutting sections (not entity-specific):

Search / entity selector — the primary navigation mechanism
Billing overview — failed payments, family plans, scholarships, deferments across all students
Reports — aggregate analytics not tied to a single entity
Admin Tools — system settings, notifications, operations, logs

Proposed Navigation Structure

├── Global Search (NEW — primary navigation mechanism, always accessible)
│
├── Students (entity list → entity pages)
│   └── [Student Entity Page] (NEW — rich detail page per student)
│       ├── Tab: Profile                 (uses: Students ← from People)
│       ├── Tab: Submissions             (uses: Submissions ← from Program)
│       ├── Tab: Payments (NEW) — subscription status, history, Stripe data, family plan, scholarship/deferment
│       ├── Tab: Appointments            (uses: Upcoming Appointments ← from Appointments)
│       ├── Tab: Semester History (NEW) — every semester, level, pass/fail, electives
│       └── Tab: Actions — promote, reset progress, deactivate + cancel subscription, resend registration
│       (merges data from: Students, Student Report ← from Reports, Submissions ← from Program,
│        Payments ← from Reports, Promoted Students ← from Reports, Upcoming Appointments ← from Appointments)
│
├── Semesters (entity list → entity pages)
│   └── [Semester Entity Page] (NEW — comprehensive semester hub)
│       ├── Tab: Overview                (uses: Semesters)
│       │   ├── Dates, status, registration settings with inline documentation
│       │   └── Auto-transition controls (NEW)
│       ├── Tab: Content Status (NEW) — checklist of all content with upload status per level
│       │   ├── Video Lessons            ← from Program
│       │   ├── Submissions (Assessments)← from Program
│       │   ├── Resources                ← from Program
│       │   ├── Recordings               ← from Program
│       │   ├── Tutorials                ← from Program
│       │   ├── MCQ Questions            ← from Program
│       │   └── Quizzes                  ← from Program
│       ├── Tab: Enrollment (NEW) — student list for this semester with levels, statuses, filtering
│       ├── Tab: Automation              (uses: Email Management ← from Settings, Tags ← from Settings)
│       ├── Tab: Welcome Package         (uses: Welcome Package ← from Settings)
│       └── Tab: Scheduling              (uses: Live Sessions ← from Program)
│
├── Teachers (entity list → entity pages)
│   └── [TA Entity Page] (NEW — comprehensive TA hub)
│       ├── Tab: Profile                 (uses: Teaching Assistants ← from People)
│       ├── Tab: Schedule                (uses: TA Schedules ← from Appointments)
│       │   └── Includes holidays        (uses: Holidays ← from Appointments)
│       ├── Tab: Students & Groups (NEW) — assigned students, groups, submission review queue
│       │   (uses: Student Groups, currently only on TA detail pages)
│       ├── Tab: Performance (NEW) — response times, review counts, student outcomes
│       │   (uses: TA Reports ← from Reports)
│       └── Tab: Assignment Rules        (uses: Teacher Assignment Criteria ← from Settings)
│
├── Cross-Entity Sections
│   ├── Dashboard (NEW — rebuilt as operational alert surface)
│   │   ├── Students falling behind (links to filtered student list)
│   │   ├── TA response time flags (links to filtered TA list)
│   │   ├── Failed payment alerts (links to student entity pages)
│   │   ├── Appointment utilization (links to scheduling view)
│   │   └── Semester status prompts (links to semester entity page)
│   │
│   ├── Billing Overview (NEW)
│   │   ├── Subscription Health (NEW) — aggregate view of all active subscriptions
│   │   ├── Failed Payments (NEW) — list with links to student entity pages
│   │   ├── Payment Plans                ← from Settings
│   │   ├── Coupons                      ← from Settings
│   │   ├── Family Plans (NEW) — replaces Google Sheet
│   │   └── Scholarships & Deferments (NEW) — replaces Google Sheet
│   │   (Payments transaction history ← from Reports — embedded here)
│   │
│   ├── Scheduling Overview (NEW — cross-entity calendar)
│   │   ├── Calendar View (NEW) — all live sessions + 1:1 appointments across all TAs
│   │   ├── Upcoming Appointments        ← from Appointments
│   │   └── Holidays (system-wide view)  ← from Appointments
│   │
│   ├── Reports (aggregate analytics not tied to a single entity)
│   │   ├── Student Report               ← from Reports (also accessible from Student Entity Page)
│   │   ├── Failed Sign Ups              ← from Reports
│   │   ├── Referrals                    ← from Reports
│   │   ├── Specific Reports             ← from Reports
│   │   ├── Student Composition (NEW) — new vs. repeat vs. graduating
│   │   └── Promoted Students            ← from Reports (also accessible from Student Entity Page)
│   │
│   ├── Operations
│   │   ├── Bulk Promote (Year 1 → Year 2)    ← from Settings (Operations)
│   │   ├── Bulk User Registration             ← from Settings (Operations)
│   │   └── Data Migration                     ← from Settings (Operations)
│   │
│   └── Admin Tools
│       ├── Admins                       ← from People
│       ├── Settings (General)           ← from Settings
│       ├── Notifications                ← from Settings
│       ├── Logs                         ← from Settings
│       └── Support Links                ← from Students Management grab-bag

How This Addresses Key Needs

Billing gap (Q5, Q9): Billing is addressed at two levels. At the entity level, every Student Entity Page has a Payments tab showing subscription status, payment history, family plan membership, scholarship/deferment flags, and Stripe data — this is the admin's primary billing use case ("what is this student's payment situation?"). At the aggregate level, a Billing Overview section provides subscription health dashboards, failed payment lists, and configuration screens for Payment Plans, Coupons, Family Plans, and Scholarships. This dual approach means the admin never leaves the student context for individual billing questions and has a dedicated section for billing operations. Consolidated student profile (Q2): This is the framework's defining strength. The Student Entity Page is precisely what the admin requested: level, TA, gender, semester history, submission count, payment status, appointments — all on one page with tabs. Every piece of student data currently scattered across People, Reports, Program, Appointments, and Stripe is consolidated into a single entity page. This is the most complete answer to Q2 of any framework. Semester setup fragmentation (Q1): The Semester Entity Page puts dates, content status (with per-level completion tracking), enrollment, automation (email + tags), welcome package, and scheduling on a single tabbed page. What currently requires 11 screens across 4 sections becomes a single entity page. The Content Status tab functions as a built-in checklist showing what has been uploaded and what is missing. Dashboard problem (Q6, Q7): The Dashboard is rebuilt as a cross-entity alert surface. Each alert links directly to the relevant entity page with context preserved — clicking "3 failed payments" opens a filtered student list where each student links to their entity page with the Payments tab active. The entity model makes these deep links natural because every alert resolves to an entity. Settings catch-all (Q6): Fully dissolved. Every item from Settings is absorbed into an entity page tab (Teacher Assignment Criteria → TA Entity Page, Welcome Package → Semester Entity Page, Email Management → Semester Entity Page, Tags → Semester Entity Page) or a cross-entity section (Payment Plans → Billing Overview, Logs → Admin Tools). Nothing remains in a catch-all.

Assumptions About the User

The entity model assumes most admin work begins with knowing who or what they are working with. "A student emailed with a problem" — the admin starts by finding that student. "I need to set up the spring semester" — the admin starts by selecting that semester. The user needs the skill of entity identification and search, not domain classification or workflow sequencing.

This model is strongest for support-style work where the trigger is an entity (a student, a TA) and weakest for aggregate or cross-entity work where the trigger is a question ("how many students are behind?" or "what's the overall payment status?"). It assumes the admin already knows which entity to start with.

Strengths

Directly solves the "consolidated student profile" request. The admin's most specific wish in the interview was seeing "level, TA, gender, semester history, submission count, and payment status" on one screen [Q2]. The entity model delivers this by definition — the Student Entity Page is exactly what she described. This is the framework with the highest resolution match to the admin's most concrete request.
Solves the semester setup fragmentation. The Semester Entity Page puts dates, content status, enrollment, automation, and welcome package on a single page with tabs. What currently requires 11 screens across 4 sections [Q1] becomes a single entity page with sections. The admin would never need to navigate away from the semester context to complete setup.
Eliminates organizational disputes. There is no debate about whether Live Sessions belongs under Content or Scheduling — it appears on the Semester Entity Page (as part of content status) and on the TA Entity Page (as part of schedule). Items can appear in multiple entity contexts without creating ambiguity about "where it lives." The entity model transcends categorization by making everything relational.
Matches how the admin already resolves student issues. The interview described the student support workflow as: find student, check their profile, check their submissions, check their payments (in Stripe), check their appointments [Q2]. This is already entity-centric navigation — the admin is doing it manually across 5 screens and 2 external tools. The framework formalizes what she already does.

Risks

Cross-entity and aggregate tasks are awkward. Semester close involves reviewing all students' EOC assessments, promoting multiple students, setting up payments for a cohort. These are not single-entity tasks — they require bulk views and bulk actions that do not naturally live on any single entity page. The admin would need to repeatedly return to a list, select an entity, act, return to the list, select another [Q3].
Bulk operations need a separate home. Operations like "bulk promote Year 1 to Year 2" (CSV upload), "bulk user registration," and "data migration" are cross-entity by nature. The entity model must supplement entity pages with aggregate/operations screens, creating a hybrid that dilutes the framework's purity. The current Operations screen [from SETTINGS] has no entity to attach to.
"I don't know which entity to start with." When the admin's task is "check if any students are falling behind on submissions" [Q7], there is no entity to select — the task is an aggregate scan. The same applies to "check TA response times" and "review failed payments." These trigger the admin's daily work but are not entity-scoped. The framework needs a separate entry point for these patterns.
Development effort is the highest of any framework. Each entity page is essentially a mini-application with multiple tabs, inline actions, and data pulled from many tables and external services. Building a comprehensive Student Entity Page that includes profile, submissions, payments (from Stripe), appointments, and semester history is a significant engineering investment [Redesign Plan, Candidate C risks]. The current system's simple list/detail pages would all need to be replaced.

Affinity with Current State

Low. The current structure organizes by data type with shallow detail pages. The entity model requires deep detail pages that consolidate data from across the system. No current section survives intact — each is disaggregated and redistributed across entity pages. The Students list page survives as the entry point to Student Entity Pages, but the detail page it links to would be completely rebuilt. Similarly for Semesters and TAs. The PROGRAM section (8 screens) is entirely absorbed into Semester Entity Pages. The SETTINGS section is dissolved. The REPORTS section partially survives as a cross-cutting area.

Natural Opportunities

Rich student profiles with action integration. The entity model naturally enables "promote this student, cancel their subscription, and deactivate their account" as a single-page interaction. This directly addresses the interview finding that student deactivation is a disconnected two-step process (backend + Stripe separately) [Q3].
Semester setup as a single-page experience. The Semester Entity Page naturally produces a content-status checklist that shows what is configured and what is missing — directly addressing the "extensive double-checking" pain point [Q8].
TA workload visibility. The TA Entity Page naturally surfaces assigned student counts, submission review backlogs, and response times — data the admin currently tracks in Google Sheets [Q2].
Search-first navigation. The entity model naturally privileges search over browsing, which benefits power users who know what they are looking for. The admin could type a student name and immediately see their entire history, rather than navigating through menus.

Framework 6: Hub-and-Spoke / Dashboard-Driven

Principle

Hub-and-spoke navigation places a central dashboard at the center of the admin experience. This dashboard is not a passive overview (like the current one) but an active operational nerve center that detects exceptions, surfaces alerts, and links directly to the context where action is needed. The "hub" answers the question "what needs my attention right now?" Each alert or tile on the dashboard is a "spoke" that links to the relevant screen with context preserved — clicking "3 failed payments" takes the admin directly to a filtered list of those 3 students with payment actions available. The spoke sections still exist for direct access when the admin knows where to go, but the hub is the primary entry point for most reactive work.

Application to QuranFlow

The Hub (Dashboard) — rebuilt from scratch based on interview Q7:

Alert / Tile	Data Source	Spoke Destination
"5 students falling behind on submissions"	Submission count vs. expected pace	Filtered student list with submission details
"2 TAs with >48hr response time"	Submission review timestamps	TA list filtered to flagged TAs with review queues
"3 failed payments this week"	Stripe webhook / API	Payment issue list with student profiles and Stripe links
"Year 2: 4 of 12 appointments used this week"	Appointment data	Appointment calendar filtered to Year 2
"Semester close: 6 items remaining"	Phase-aware checklist	Semester configuration with incomplete items highlighted
"2 app issues reported by students"	Student issue reports (new feature)	Issue queue with student context

Spoke Sections (secondary nav, for direct access):

Students — standard list with search
Semesters — list with setup status
Content — video lessons, resources, recordings, tutorials, quizzes
Scheduling — live sessions, appointments, TA schedules, holidays
Teachers — TA list, assignment criteria, groups
Billing — payment overview, family plans, scholarships, deferments, payment config
Reports — all analytics and exports
Admin — settings, notifications, operations, logs

The spoke sections resemble a simplified domain-based structure. The key difference is that the dashboard, not the sidebar, is the primary workspace.

Proposed Navigation Structure

├── HUB: Dashboard (NEW — rebuilt as 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 profiles
│   ├── Alert: "Year 2: X of Y appointments used this week" (NEW)
│   │   └── → links to Upcoming Appointments filtered to Year 2
│   ├── Tile: "Semester [setup/close]: X items remaining" (NEW)
│   │   └── → links to Semester setup checklist
│   ├── Alert: "X app issues reported by students" (NEW)
│   │   └── → links to Issue Queue (NEW)
│   ├── Tile: Student body snapshot (NEW) — new vs. repeat vs. graduating
│   └── Quick actions: Search student, View today's appointments, Send notification
│
├── SPOKE: Students
│   ├── Students (list + search)         ← from People
│   ├── Student Report                   ← from Reports
│   ├── Promoted Students                ← from Reports
│   └── Failed Sign Ups                  ← from Reports
│
├── SPOKE: Semesters
│   ├── Semesters (list + setup status)
│   ├── Semester Setup Checklist (NEW) — what's configured, what's missing
│   ├── Welcome Package                  ← from Settings
│   ├── Email Management                 ← from Settings
│   ├── Tags                             ← from Settings
│   └── Operations (bulk actions)        ← from Settings
│
├── SPOKE: Content
│   ├── Video Lessons                    ← from Program
│   ├── Submissions (Assessments)        ← 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              ← from People
│   ├── Teacher Assignment Criteria      ← from Settings
│   ├── TA Reports                       ← from Reports
│   └── Student Groups (NEW — surfaced from TA detail pages)
│
├── SPOKE: Billing (NEW)
│   ├── 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 grab-bag
│   └── Issue Queue (NEW) — student-reported app issues

How This Addresses Key Needs

Billing gap (Q5, Q9): Billing is addressed at two layers — the hub and the spoke — making it the most natural billing integration of any framework. The Dashboard surfaces billing exceptions proactively: failed payment alerts, expiring subscriptions, and past-due installments appear as tiles the admin sees immediately on login, eliminating the need to remember to check Stripe. The Billing spoke provides the persistent home for configuration and investigation: Payment Overview shows subscription health at a glance, Payment Plans and Coupons move from Settings, and new screens for Family Plans and Scholarships replace Google Sheets. The admin explicitly requested failed payment alerts on the dashboard [Q7] — this framework makes that the central organizing principle. Consolidated student profile (Q2): Partially addressed at the spoke level. The Students spoke groups Students, Student Report, Promoted Students, and Failed Sign Ups. Submissions remain in the Content spoke; Payments are in the Billing spoke. The hub model does not inherently produce a consolidated student page — but it is fully compatible with rich student detail pages (Entity-Centric concepts can be layered in). The hub's contribution is that clicking a dashboard alert like "3 students falling behind" takes the admin directly to those students with context preserved. Semester setup fragmentation (Q1): The Semesters spoke groups the semester record with Welcome Package, Email Management, Tags, and Operations — all previously scattered across Settings. Content and Scheduling remain in their own spokes, so setup still touches 3 spokes (Semesters, Content, Scheduling). However, the Dashboard adds a "Semester setup: X items remaining" tile that provides the checklist/progress-tracking the admin needs without requiring a guided wizard. This borrows the workflow concept as a dashboard feature. Dashboard problem (Q6, Q7): This is the framework's defining strength. The Dashboard is rebuilt from scratch as the admin's operational nerve center, directly implementing her Q7 wish list: app issues, appointment utilization, TA response time alerts, failed payment alerts, students falling behind. Every tile links to a filtered view in a spoke section with context preserved. The admin shifts from reactive (learning about problems when students email) to proactive (the system surfaces problems before they escalate). Settings catch-all (Q6): Fully dissolved. The spoke sections use a domain-like organization that distributes every Settings item to its logical home: Welcome Package and Email Management to Semesters, Teacher Assignment Criteria to Teachers, Payment Plans and Coupons to Billing, Logs to Reports, Support Links to Admin. The "Students Management" grab-bag is eliminated: Level 0 promotion goes to Semesters (Operations), Holidays merge into Scheduling, Support Links go to Admin.

Assumptions About the User

The hub model assumes most admin work is reactive — responding to issues that have already occurred or are about to occur. The system detects problems and presents them; the admin resolves them. This shifts the admin from a proactive navigator ("I'll go check if anyone has failed payments") to a reactive responder ("the system tells me 3 payments failed"). The user needs the skill of triage — assessing alerts and deciding what to act on — rather than navigation — knowing where to find things.

This model is strongest when the system has enough data and logic to reliably detect exceptions. It is weakest when the admin needs to do planned, proactive work (like semester setup) that is not triggered by an alert.

Strengths

Directly addresses the interview's #1 dashboard complaint. The admin described the current dashboard as "inaccurate and unhelpful" [Q6] and provided a detailed wish list for what it should show: app issues, appointment utilization, TA response time alerts, failed payment alerts, students falling behind [Q7]. The hub model is the only framework that makes this wish list the central organizing principle rather than a secondary feature.
Shifts admin from reactive to proactive. The admin currently learns about failed payments when students email, about TA response delays when she manually checks, and about students falling behind when she runs reports [Q2, Q7]. The hub model surfaces these proactively, enabling intervention before problems escalate. This is not just a navigation improvement — it is an operational capability improvement.
Works well for secondary users. TAs and view-only admins can ignore the dashboard entirely and use the spoke sections directly. The spoke sections provide predictable, stable navigation that does not change based on phase or context. The hub adds value for the power admin without complicating life for occasional users [Redesign Plan, Candidate B strengths].
Naturally accommodates billing alerts. Failed payment notifications, expiring subscriptions, and students on installment plans with remaining cycles are inherently alert-worthy. The hub model gives billing visibility its most natural expression — not as a section the admin must remember to visit, but as exceptions that surface when they need attention [Q5, Q7].

Risks

The hub is only as good as the alert logic. Detecting "students falling behind on submissions" requires defining "behind" (how many submissions per week is expected? does it vary by level?). Detecting "TA response time >48hrs" requires reliable timestamp data. If the alert logic produces false positives or misses real issues, the dashboard degrades to noise — or worse, to the same useless overview the admin already has [Q6]. Building reliable alert logic is a significant backend engineering effort.
Planned work is not triggered by alerts. Semester setup is the admin's highest-friction workflow [Q1], but it is not reactive — it is proactive, scheduled work. The hub model handles this through phase-aware prompts ("Semester close: 6 items remaining"), but these are a bolt-on to the hub concept, not its core strength. The hub model's value proposition is weakest for the admin's most painful workflow.
The spoke sections may just reproduce the current nav. If the hub's alerts link to standard list/detail pages, the admin's experience after clicking an alert is the same as navigating directly. The hub adds one click (dashboard, then spoke) rather than reducing clicks. The value depends on whether the alert links preserve context (e.g., pre-filtering the student list to only those with failed payments) — if they do not, the hub is just a notifications page [Redesign Plan, Candidate B risks].
Dashboard-first assumes the admin starts each session at the dashboard. If the admin bookmarks the Students page or opens multiple tabs, the hub model's benefits diminish. The hub only adds value if the admin's workflow actually begins there. This is a behavioral assumption that may or may not hold.

Affinity with Current State

Moderate to high. The spoke sections can closely mirror the current structure (or a mildly reorganized version of it). The DASHBOARD screen would be completely rebuilt, but the rest of the nav could survive with minimal changes. This makes hub-and-spoke the lowest-disruption framework — the existing sections persist, and the improvement comes from adding an intelligent layer on top. Alternatively, the spoke sections could be reorganized into domains (creating a hybrid with Framework 2), which would increase disruption but also increase coherence.

Natural Opportunities

Alert-driven billing visibility. Failed payments, expiring subscriptions, and past-due installments would surface on the dashboard without requiring the admin to visit a billing section. This is arguably the most natural way to address the billing gap — not by building a comprehensive billing management section first, but by surfacing the exceptions that require action [Q5, Q7].
TA performance monitoring. Response time alerts, submission review backlogs, and student outcome flags can be dashboard tiles, enabling the admin to manage TA performance without maintaining separate Google Sheets [Q2].
Phased prompts as dashboard tiles. "Semester setup: 3 of 7 content types uploaded" and "Semester close: 12 students pending promotion" can be dashboard tiles that borrow from the phase-based model without restructuring the navigation around phases. This gives the admin temporal awareness without the costs of a full phase-based system.
Student issue reporting pipeline. The admin requested "student-reported app issues" on the dashboard [Q7]. The hub model makes this a first-class feature — a tile that links to an issue queue, creating a new communication channel between students and admin that does not currently exist.

Framework Interactions

Before scoring each framework individually, it is worth mapping which frameworks are complementary (can be combined into a coherent hybrid) and which are competing (cannot coexist as co-equal organizing principles). This mapping sets up the hybrid candidates that will be evaluated in step 1.4.

Domain-Based + Hub-and-Spoke: Complementary. One organizes the sections (domains give the sidebar its structure), the other surfaces alerts (the hub gives the admin a starting point for reactive work). They operate on different layers of the experience — structure vs. attention — and combining them loses nothing from either.
Domain-Based + Entity-Centric: Complementary. Domains organize the navigation; entity pages provide depth within each domain. A "Student Management" domain that leads to rich Student Entity Pages combines domain structure with entity depth. The domain provides the where, the entity page provides the what.
Hub-and-Spoke + Entity-Centric: Complementary. The hub surfaces alerts ("3 failed payments"); clicking an alert opens a Student Entity Page with payment context pre-loaded. The hub provides the trigger, the entity page provides the resolution context. Together they form a complete detect-and-resolve loop.
Workflow-Based + Phase-Based: Overlapping. Both try to contextualize what the admin should do now — workflows by sequencing steps, phases by surfacing time-relevant tools. Combining them creates redundancy: should the system guide the admin via a workflow wizard or via phase-aware prompts? They compete for the same cognitive space. However, individual concepts from each (guided checklists from workflows, temporal prompts from phases) can be borrowed as features without conflict.
Object-Based + anything: Competing. The object-based model is the baseline being replaced. Its value (simplicity, developer alignment) is retained as a fallback within spoke sections or as the default for secondary users, but it cannot be combined with another framework as a co-equal principle without simply reproducing the current state.

Comparison Matrix

The following matrix scores each framework against four key evaluation criteria, using a 1-5 scale (1 = poor fit, 5 = excellent fit).

Scoring Criteria Definitions

Mental Model Match: How well does the framework align with how the admin described thinking about the system? Primary evidence: interview Q4 (domains of responsibility), Q1-Q3 (phase-oriented descriptions), Q2 (entity-oriented descriptions). A score of 5 means the framework directly implements the admin's stated mental model.
Implementation Effort: How much backend development is required to realize the framework? A score of 5 means minimal effort (mostly reorganizing existing screens). A score of 1 means significant rearchitecture (new consolidated pages, alert logic, search infrastructure).
Secondary User Fit: How well can TAs, view-only admins, and support staff navigate the system? A score of 5 means any user can find what they need without training. A score of 1 means the framework is optimized for the power admin and confusing to everyone else.
Billing Accommodation: How naturally does billing integrate as a first-class feature? A score of 5 means billing has an obvious, logical home and improves the framework. A score of 1 means billing is an awkward addition that strains the organizational structure.

Matrix

Framework	Mental Model Match	Implementation Effort	Secondary User Fit	Billing Accommodation	Total
1. Object-Based (current)	2	5	4	2	13
2. Domain-Based	5	4	3	4	16
3. Workflow/Task-Based	3	2	2	2	9
4. Phase-Based / Temporal	3	2	1	2	8
5. Entity-Centric / CRM	4	1	3	4	12
6. Hub-and-Spoke	3	3	5	5	16

Score Rationale

Object-Based (current)

Mental Model Match (2): The admin explicitly said she thinks in domains, not data types [Q4]. The current structure forces her into a data-type mental model she does not hold.
Implementation Effort (5): This is the current state. No development required.
Secondary User Fit (4): Simple, stable, predictable. TAs and view-only admins can navigate by noun recognition. Loses a point because the catch-all Settings and misnamed "Students Management" confuse even basic navigation.
Billing Accommodation (2): A "Payments" section could be added, but the relational nature of billing (connecting students, semesters, subscriptions) does not fit cleanly into a flat object section. Payment Plans and Coupons already exist in Settings — adding more billing screens would either fragment billing across sections or create a large new section that doesn't solve the cross-referencing need.

Domain-Based

Mental Model Match (5): This is the admin's own proposal [Q4]. No other framework scores higher.
Implementation Effort (4): Primarily a reorganization of existing screens into new sections. Some screens move (Welcome Package from Settings to Semester Management), but the screens themselves do not need to be rebuilt. Loses a point because domain boundaries require new section pages and some screens (like Submissions) may need contextual changes depending on which domain they land in.
Secondary User Fit (3): The domain structure is logical but requires learning a new vocabulary ("Semester Management" instead of "Semesters"). Secondary users who memorized "Students is under People" must relearn. The domain labels are intuitive but not self-evident.
Billing Accommodation (4): Billing fits naturally as its own domain or distributed across Student Management (individual) and a Billing domain (aggregate). Payment Plans and Coupons move from Settings to Billing. Scholarships and deferments get a logical home. Loses a point because the cross-cutting nature of billing means it appears in at least two domains (student profiles and a billing section).

Workflow/Task-Based

Mental Model Match (3): The admin's workflows map well to this model, but she did not describe thinking in tasks — she described thinking in domains [Q4]. Workflows solve a real problem (multi-screen hopping) but impose a structure the admin did not ask for.
Implementation Effort (2): Workflows require building guided sequences with state tracking, step completion logic, and conditional branching for edge cases [Q3]. This is not a reorganization of existing screens — it is a new application layer on top of them. Significant development effort.
Secondary User Fit (2): Workflows are designed for the primary admin's recurring tasks. A TA looking up a student's submission status does not want to enter a "Handle Student Issue" workflow. Occasional users need direct access, not guided sequences.
Billing Accommodation (2): Billing appears within workflows (payment step in semester close, payment tab in student support) but has no persistent home for configuration and ad-hoc lookups. Payment Plans, Coupons, family plans, and scholarships need a non-workflow location.

Phase-Based / Temporal

Mental Model Match (3): The admin's descriptions were organized by phase [Q1-Q3], but when asked directly about navigation, she proposed domains, not phases [Q4]. The phase model matches how she describes her calendar but not how she describes her navigation preference.
Implementation Effort (2): Requires building phase detection logic, conditional navigation rendering, and a persistent layer. If phase detection is automatic, it requires reliable date-based rules that interact with the already-problematic semester status fields [Q1]. If manual, it adds a cognitive burden.
Secondary User Fit (1): A navigation that changes based on phase is actively confusing to occasional users. A TA logging in during setup phase sees different tools than during active phase. This is the framework most hostile to secondary users.
Billing Accommodation (2): Billing is relevant across all phases and does not fit cleanly into any single phase. It would need to be in the persistent layer, where it competes with other always-available items, undermining the phase model's simplification benefit.

Entity-Centric / CRM

Mental Model Match (4): The admin's description of wanting a consolidated student profile [Q2] and her entity-by-entity workflow patterns (find student, check everything about them) closely match this model. It loses a point because the admin's mental model is not purely entity-centric — she also thinks in domains and phases, and her description of bulk/aggregate tasks (semester close, daily monitoring) does not fit the entity paradigm.
Implementation Effort (1): The highest development effort of any framework. Every entity page is a mini-application with multiple tabs, inline actions, and data aggregation from many sources including Stripe. The current simple list/detail pages would all need to be rebuilt. This is a rearchitecture, not a reorganization.
Secondary User Fit (3): CRM-style interfaces are widely familiar (Stripe dashboard, HubSpot, Salesforce). A TA could search for a student and see their info. However, the search-first model assumes the user knows what entity to look for, which may not always be the case for occasional users who want to browse.
Billing Accommodation (4): Billing fits beautifully on entity pages — a Payment tab on every student profile showing subscription status, payment history, and actions. Cross-cutting billing views (failed payments overview, family plans) need a separate section, preventing a perfect score. But the entity model solves the admin's primary billing use case: "I need to see this student's payment status" [Q2, Q5].

Hub-and-Spoke

Mental Model Match (3): The admin did not describe a dashboard-first mental model, but her wish list for the dashboard [Q7] and her frustration with the current dashboard [Q6] show strong latent demand for this pattern. She described wanting proactive alerts even though her current workflow is navigational. This scores a 3 because it matches her desired workflow more than her current mental model.
Implementation Effort (3): The spoke sections can reuse existing screens with minimal changes, keeping structural effort low. The hub (dashboard) requires building alert detection logic, which is moderate engineering work. The overall effort is balanced — less than entity-centric or workflow-based, more than domain-based or object-based.
Secondary User Fit (5): The best score of any framework. TAs and view-only admins can completely ignore the dashboard and use the spoke sections, which provide stable, predictable navigation. The hub adds value for the power admin without imposing costs on anyone else. The spoke sections can be organized however is clearest for all users.
Billing Accommodation (5): The best score of any framework. Billing alerts (failed payments, expiring subscriptions) are the most natural dashboard tiles possible — the admin explicitly requested them [Q7]. Billing configuration lives in the spoke sections. The hub model solves both the "I need to see billing problems" use case (dashboard alerts) and the "I need to manage billing settings" use case (spoke section) without either feeling forced.

Observations

Two frameworks tie at the top with a score of 16: Domain-Based and Hub-and-Spoke. This is notable because they are complementary, not competitive — domain-based excels at organizing the sections while hub-and-spoke excels at surfacing what matters now. A hybrid that uses domain-based spoke sections with a hub dashboard would score the maximum on multiple criteria.

Three frameworks score lowest (8-9): Phase-Based and Workflow-Based. Both have valuable concepts to borrow (phase-aware prompts, guided checklists) but significant risks as standalone navigation paradigms. They are best used as features within another framework rather than as the organizing principle.

Entity-Centric scores in the middle (12), held back primarily by implementation effort. Its concept of rich entity pages is the most direct solution to the admin's concrete requests (consolidated student profile, semester setup page), but building those pages is the most expensive option. The entity-centric concept is valuable; the entity-centric framework is expensive.

The matrix also reveals important patterns about hybrid potential. Domain-Based and Hub-and-Spoke are the most natural combination: Domain-Based provides the highest organizational structure score (Mental Model Match: 5) while Hub-and-Spoke provides the highest alert visibility scores (Secondary User Fit: 5, Billing Accommodation: 5). A hybrid inherits both strengths without either framework's primary weakness. Entity-Centric concepts — particularly rich entity pages with tabs — can be used within any framework without being the framework; a Domain-Based system with CRM-style Student and Semester pages gets the entity model's concrete benefits without its implementation cost as a standalone paradigm. Similarly, Phase-Based concepts (temporal prompts on the dashboard) and Workflow concepts (guided checklists for semester setup) are best deployed as features within a hybrid rather than as the organizing principle. This explains why three frameworks score low as standalone systems but contain high-value concepts: they are feature donors, not framework candidates.

This matrix feeds into the pre-filtering step (1.3) and candidate definition step (1.4) of the Redesign Plan.

Improvements and Opportunities Summary

The following is a consolidated list of every improvement opportunity identified across all six framework analyses. Each entry notes which framework(s) surfaced the opportunity, what interview evidence supports it, and whether it represents a net-new capability (does not exist today) or an enhancement of an existing capability.

Semester setup checklist with progress tracking — Emerged from: Workflow (step completion state), Entity-Centric (Semester Entity Page content-status tab), Hub-and-Spoke (phase-aware dashboard tile). Evidence: Semester setup requires 11 screens across 4 sections [Q1]; admin does "extensive double-checking" after setup [Q8]. Type: NEW capability. The current system has no way to track setup completion status.
Sequenced semester close (promotions before payments) — Emerged from: Workflow (enforced step order), Phase-Based (close phase tool prominence). Evidence: Stripe payment setup currently happens before promotion decisions are finalized, causing cascading corrections [Q3]. Type: ENHANCEMENT. The actions exist today but are unsequenced; this adds enforced ordering.
Consolidated student profile — Emerged from: Entity-Centric (Student Entity Page with tabs), Domain-Based (student data grouped under Student Management). Evidence: Admin wants to see "level, TA, gender, semester history, submission count, and payment status" on one screen [Q2]. Type: NEW capability. Current student detail page shows only basic profile data without submissions, payments, or history.
Alert-driven dashboard (operational hub) — Emerged from: Hub-and-Spoke (core principle). Evidence: Admin described current dashboard as "inaccurate and unhelpful" [Q6] and provided detailed wish list: app issues, appointment utilization, TA response times, failed payments, students falling behind [Q7]. Type: NEW capability. Current dashboard is a passive overview with no alerts or actionable links.
Billing integration (failed payments, subscription status, payment history) — Emerged from: Hub-and-Spoke (billing alerts as dashboard tiles), Entity-Centric (Payment tab on student profiles), Domain-Based (Billing as a domain). Evidence: Billing is the admin's biggest pain point [Q5, Q9]; currently managed entirely in Stripe and Google Sheets with no backend presence. Type: NEW capability. Zero billing functionality exists in the backend today.
TA performance monitoring (response times, review backlogs, outcomes) — Emerged from: Entity-Centric (TA Entity Page performance tab), Hub-and-Spoke (TA response time alerts), Domain-Based (Teacher Management domain). Evidence: Admin tracks TA performance in Google Sheets [Q2]; wants response time alerts [Q7]. Type: NEW capability. No TA performance data is surfaced in the backend.
Phase-aware dashboard prompts — Emerged from: Phase-Based (core concept), Hub-and-Spoke (semester status tiles). Evidence: Admin's work follows three distinct phases — setup [Q1], active [Q2], close [Q3] — with distinct tool needs for each. Type: NEW capability. The system currently has no temporal awareness.
Automatic semester status transitions — Emerged from: Phase-Based (temporal awareness infrastructure). Evidence: Admin requested auto-activation/deactivation based on start date; manual status switching is "risky" and "accidentally leaving an old semester active corrupts student profiles" [Q1]. Type: ENHANCEMENT. Semester status exists but must be switched manually.
Contextual help text (per-domain, per-step) — Emerged from: Domain-Based (documentation structured by responsibility area), Workflow (inline guidance at each step). Evidence: Admin requested "clear inline documentation explaining what each feature does and how it affects other processes" [Q9]. Type: NEW capability. No inline documentation exists today. Domain-based structure enables help organized by responsibility area; workflow structure enables help at each procedural step.
Search-first navigation — Emerged from: Entity-Centric (entity selection as primary nav mechanism). Evidence: Admin's support workflow already follows a search-first pattern — find student, then investigate [Q2]. Type: NEW capability. No global search exists in the backend.
Semester content cloning (setup wizard action) — Emerged from: Workflow (clone-from-previous step in semester setup wizard). Evidence: The admin's most avoided task is re-uploading content each semester [Q8]; the workflow model naturally offers "clone from previous semester" at the point of need. Type: NEW capability. All content must be manually re-uploaded each semester.
Student issue reporting system — Emerged from: Hub-and-Spoke (dashboard tile for "app issues reported by students" [Q7]). Evidence: The admin requested this as a dashboard feature; students currently have no in-app mechanism to report issues, and the admin has no queue to review them [Q7]. Type: NEW capability. This is a net-new communication channel between students and admin that does not exist in any form today. Should be a requirement for any framework.
Linked deactivation + payment cancellation — Emerged from: Entity-Centric (Actions tab on Student Entity Page), Workflow (deactivation as a step in semester close). Evidence: Student deactivation is currently a disconnected two-step process — backend deactivation and Stripe subscription cancellation are performed separately with no link between them [Q3]. Type: ENHANCEMENT. Both actions exist but are decoupled across two systems. Any framework should enable a single "deactivate student" action that handles both.
Content versioning / persistent content across semesters — Emerged from: Workflow (semester setup wizard with clone option), Entity-Centric (Semester Entity Page content-status tab). Evidence: Re-uploading content each semester is the admin's most avoided task [Q8]. Beyond the clone action in item 11, this is the deeper infrastructure: content that persists across semesters, with versioning so updates to a video lesson propagate without re-upload. Type: NEW capability. No content versioning or persistence infrastructure exists. This is framework-agnostic and should be a requirement regardless of navigation paradigm.
Role-based navigation simplification — Emerged from: Hub-and-Spoke (spoke sections usable by secondary users independently of the hub), Domain-Based (secondary user navigation risk [Q4]). Evidence: TAs and view-only admins currently see the same navigation as the power admin, creating unnecessary complexity. Type: NEW capability. The backend has no role-based navigation filtering today. Any framework should support showing a simplified nav based on user role.
Inline documentation system (framework-agnostic infrastructure) — Emerged from: All frameworks (each benefits from it, none inherently produce it). Evidence: The admin explicitly requested "clear inline documentation explaining what each feature does and how it affects other processes" [Q9]; navigation currently "lacks documentation and logic" [Q6]. Type: NEW capability. Distinct from item 9 (which is about structuring help content by domain or step), this is about building the system: tooltip infrastructure, field-level help, "what does this affect?" callouts, and a documentation content model. Framework-agnostic but critical.
EOC assessment integration — Emerged from: Workflow (semester close sequence includes EOC review), Phase-Based (close phase surfaces assessment tools). Evidence: EOC assessments are currently tracked in Google Sheets populated by teachers [Q2]. Type: NEW capability. Bringing this into the backend would eliminate a major external dependency that currently forces the admin out of the system during semester close.
Initial placement assessment tracking — Emerged from: Entity-Centric (Student Entity Page semester history), Domain-Based (Student Management domain). Evidence: Initial placement assessments have "no home in the backend" [Q2] and are tracked externally. Type: NEW capability. A new tracking capability needed regardless of framework.
Student body composition reporting — Emerged from: Domain-Based (Reporting domain), Hub-and-Spoke (dashboard tile potential). Evidence: There is no report showing the breakdown of new vs. repeat vs. graduating students [Q2]. Type: NEW capability. A new reporting capability that would support enrollment planning and program health monitoring.