Admin Backend Redesign Plan

QuranFlow Admin Backend Redesign Plan

Purpose: Detailed execution plan for redesigning the admin backend navigation and integrating billing as a first-class feature. Approach: Two parallel workstreams (Navigation Redesign + Billing Discovery) that converge into evaluated candidates. Prerequisites: Admin Capability Map (complete), Admin Navigation Interview Report (complete) Date: March 2026

Plan Structure

Workstream 1: Navigation Redesign        Workstream 2: Billing Discovery
├─ 1.1 Define 6 frameworks               ├─ 2.1 Audit checkout repo
├─ 1.2 Map real admin workflows          ├─ 2.2 Map current billing workarounds
├─ 1.3 Pre-filter → 3 candidates         ├─ 2.3 Research Stripe data available
├─ 1.4 Specify 3 candidate structures    ├─ 2.4 Define billing screen requirements
├─ 1.5 Score via task walkthroughs        └─ 2.5 Produce billing integration brief
│                                                │
└────────────────────┬───────────────────────────┘
                     │
              3. Convergence
              ├─ 3.1 Place billing into candidates
              ├─ 3.2 Re-score combined candidates
              └─ 3.3 Select top candidate + rationale
                     │
              4. Open Questions
              ├─ 4.1 Resolve from interview
              ├─ 4.2 Resolve from billing discovery
              └─ 4.3 Determine if follow-up interview needed
                     │
              5. Final Output
              └─ Validated candidate → ready for mockup walkthrough

Workstreams 1 and 2 run in parallel. They have no dependencies on each other until the convergence phase. They can be assigned to different people.

Workstream 1: Navigation Framework Exploration

1.1 — Define the Organizational Frameworks

Research and document each of the following frameworks as a lens for organizing the admin backend. For each one, write a short description of the principle, how it would apply to QuranFlow's admin, and what assumptions it makes about the user.

Frameworks to evaluate:

A. Object-based (current state)

B. Domain-based (from interview)

C. Workflow/Task-based

D. Phase-based / Temporal

E. Entity-centric / CRM-style

F. Hub-and-spoke / Dashboard-driven

Deliverable for 1.1:

A reference document describing each framework with its principle, application to QuranFlow admin, assumptions, strengths, and risks. This serves as the foundation for the pre-filtering in step 1.3 and the candidate definitions in step 1.4. The goal is not to evaluate all 6 equally — it's to understand each well enough to make informed decisions about which to use, which to eliminate, and which to borrow elements from.

1.2 — Map the Real Admin Workflows

Before evaluating frameworks, document the actual workflows the admin performs. These come from the interview and capability map but need to be structured as step-by-step task flows with the screens they currently touch.

Top workflows to map:

Workflow 1: Set up a new semester

Workflow 2: Handle a student support issue

Workflow 3: Close a semester / promote students

Workflow 4: Daily monitoring / operations

Workflow 5: Manage appointments / scheduling

Workflow 6: Onboard / manage a TA

Deliverable for 1.2:

A workflow document with step-by-step flows for each of the 6 workflows, annotated with: screens touched, click count, where information is missing or requires external tools, and where errors occur. This is the measuring stick for evaluating candidates.

1.3 — Pre-Filter: Why 3 Candidates, Not 6

We have enough information from the interview and capability map to eliminate frameworks that don't fit, rather than evaluating all 6 abstractly. This is the reasoning:

Eliminated as standalone approaches:

Framework Why it's eliminated What we borrow from it
Object-based This is the current state. It's failing — the interview confirmed single workflows span 5–9 screens. It's the baseline to measure against, not a candidate. Nothing — this is what we're replacing.
Pure Workflow-based The primary admin is a power user who would feel constrained by guided wizards. Workflows are rigid, hard to maintain when processes change, and don't help secondary users (TAs, view-only admins) who do ad-hoc lookups. Borrow the concept of a semester setup checklist that tracks what's been configured — but as a feature within a section, not as the organizing principle for the entire nav.
Pure Phase-based Phases overlap in practice (the admin confirmed semester close prep starts while the current semester is still active). Secondary users don't think in semester phases. A nav that changes based on phase would confuse anyone who isn't the primary admin. Borrow phase-aware contextual prompts — the dashboard or semester hub can surface "you're approaching semester close, here's what needs attention" without restructuring the entire nav around phases.

Remaining strong foundations: Domain-based, Entity-centric, Hub-and-spoke. Each has clear strengths grounded in interview evidence, and they combine naturally into hybrids. All 3 candidates below are hybrids that mix these foundations in different proportions.

1.4 — The 3 Candidate Navigation Structures

These are not abstract — each is a specific hypothesis about the best way to organize the admin backend, grounded in evidence from the interview and capability map.

Candidate A: Domain-First with Rich Entity Pages

Organizing principle: The top-level nav follows the admin's own mental model (7 domains from interview Q4). Within each domain, key entities (students, semesters, TAs) get comprehensive single-page views that consolidate everything about that entity.

Why this candidate: Directly implements what the admin asked for in the interview. The domain structure matches her description of how she thinks about the system. Adding entity-centric pages within domains solves the "I need 5 screens to handle a student issue" problem without restructuring the entire nav.

How it works:

Strengths from interview evidence:

Risks:

What to watch for in task walkthroughs: Does the domain structure reduce screen-hopping for all 6 workflows, or only for the ones that are already domain-aligned? Cross-domain workflows (like semester close, which touches students, billing, and the semester itself) may still require jumping.

Candidate B: Hub-and-Spoke with Domain Sections

Organizing principle: A smart dashboard is the primary workspace — it surfaces exceptions, alerts, and phase-aware prompts. Domain sections exist for direct access when the admin knows exactly where to go, but the dashboard is the starting point for most work.

Why this candidate: The interview revealed two things in tension: (1) the current dashboard is useless (Q6, Q7), and (2) much of the admin's daily work is reactive — responding to student issues, failed payments, TA delays. A hub-and-spoke model turns the dashboard into the operational nerve center the admin wished she had.

How it works:

Strengths from interview evidence:

Risks:

What to watch for in task walkthroughs: Does the dashboard actually reduce screen-hopping, or does it just add one more screen (the hub) before the admin navigates to the same places they go today? The value depends on whether the alert links are deep enough.

Candidate C: Entity-Centric with Contextual Navigation

Organizing principle: The admin starts by selecting an entity (student, semester, TA) and everything about that entity is accessible from a single comprehensive page. Navigation is minimal — a search/select bar + entity type selector replaces a traditional sidebar.

Why this candidate: The interview revealed that most admin work is centered on a specific entity — "I need to handle this student's issue", "I need to set up this semester", "I need to check this TA's schedule." The object-based approach fails not because entities are the wrong concept, but because entity pages are too shallow. This candidate goes all-in on deep entity pages.

How it works:

Strengths from interview evidence:

Risks:

What to watch for in task walkthroughs: Does entity-centric excel at entity-specific workflows (student support, TA onboarding) but struggle with cross-entity and bulk workflows (semester close, daily monitoring)?

What each candidate must include when fully specified:

  1. Full navigation tree — every screen from the current capability map placed, plus billing
  2. What moved — where each item came from in the current structure
  3. What's new — screens or consolidations the structure implies
  4. What's eliminated — screens merged or removed (e.g., "Students Management" grab-bag)
  5. Hybrid notes — which principle governs which part of the structure

1.5 — Evaluate Candidates Against Workflows

Evaluation criteria:

Criterion What it measures How to score
Screen-hop reduction How many screens does each top workflow require vs. current state? Count screens per workflow. Lower = better.
Mental model match Does it match how the admin described thinking in interview Q4? High / Medium / Low with rationale.
Secondary user learnability Can a TA or view-only admin find what they need without training? Simulate: "I'm a TA, I need to check a student's submission status." Score: Obvious / Findable / Confusing.
Billing accommodation Does billing fit naturally into the structure? Natural fit / Workable / Forced.
Scalability If 3 new features are added next year, does the structure hold? Test with: "Student App Issue Reporting", "TA Performance Reviews", "Content Versioning" — where do they go? Clean / Messy.
Catch-all risk Does it create dumping-ground sections? Count orphan items. Fewer = better.
Implementation effort How much backend change is needed? Nav-only / Moderate restructuring / Significant rearchitecture.

Task walkthrough format:

For each candidate, walk through all 6 workflows from step 1.2:

Workflow Candidate A (Domain-First) Candidate B (Hub-and-Spoke) Candidate C (Entity-Centric)
Semester setup Screens: ?, External tools needed: ?, Key improvement: ?
Student support
Semester close
Daily monitoring
Appointment mgmt
TA onboarding

For each cell, document:

Deliverable for 1.5:

Scored comparison table with evaluation matrix and a preliminary recommendation, with rationale citing specific interview findings and workflow evidence. This feeds into Phase 3 where billing specifics get layered in.

Workstream 2: Billing & Payment Discovery

2.1 — Audit the Checkout Repo

Review the QuranFlow checkout repository on GitHub to understand the current billing implementation.

What to document:

Deliverable for 2.1:

A technical brief documenting the current checkout architecture, what Stripe data flows through the system, and what data only exists externally.

2.2 — Map Current Billing Workarounds

Using the interview data (already captured in the Interview Report), consolidate every billing-related workaround into a structured list.

From the interview, we already know:

Workaround Tool used What data it tracks Who maintains it
Payment/subscription management Stripe dashboard All payment data Admin
Family payment plans Google Sheets Which families, shared plans, amounts Admin
Scholarship tracking Google Sheets Who has scholarships, amounts, terms Admin
Deferment tracking Google Sheets Who is deferring, timeline, status Admin
Student payment status lookup Stripe + Sheets Whether a student is paid, plan type Admin + Support
Failed payment follow-up Stripe alerts (if configured) + manual Who missed a payment Admin
Semester-end payment setup Stripe dashboard New subscriptions for continuing students Admin
Student deactivation + payment cancel Backend + Stripe separately Account status + subscription status Admin

What to add:

Deliverable for 2.2:

A billing workaround inventory with volume and frequency data. If volume data isn't available from existing documents, flag it as an open question for step 4.

2.3 — Research Stripe Data Available via API

Document what Stripe data could be surfaced in the admin backend, regardless of what's currently integrated.

Key Stripe objects to review:

Stripe Object What it contains Admin relevance
Customer Email, name, payment methods, metadata Link to student profile
Subscription Plan, status (active/past_due/canceled/trialing), current period, cancel_at Student payment status, failed payment detection
Invoice Amount, status (paid/open/uncollectible), line items, payment attempts Payment history, failed payments
Payment Intent Amount, status, payment method, failure reason Detailed payment troubleshooting
Coupon / Promotion Code Discount amount, duration, redemption count Already in admin — verify sync
Product / Price Plan names, amounts, intervals Payment plan configuration

Questions to answer:

Deliverable for 2.3:

A Stripe data availability brief listing what can be surfaced, what API calls are needed, and what limitations exist (rate limits, data freshness, etc.).

2.4 — Define Billing Screen Requirements

Based on 2.1–2.3, define what billing-related screens and features the admin backend needs.

Proposed billing surfaces:

A. Student Profile — Payment Tab

B. Billing Dashboard / Alerts

C. Payment Configuration

D. Semester Close — Payment Workflow

Deliverable for 2.4:

A billing feature requirements document describing each surface, what data it shows, what actions it supports, and where it would live in the admin backend.

2.5 — Produce Billing Integration Brief

Synthesize 2.1–2.4 into a single document that Workstream 1 can use during convergence.

The brief should answer:

  1. What billing data exists today (from 2.1) and what's only in Stripe/Sheets
  2. What the admin needs to see and do (from 2.2 + 2.4) — the feature requirements
  3. What Stripe can provide (from 2.3) — the technical feasibility
  4. What gaps remain — things that need custom development beyond Stripe API reads (family plans, scholarships, deferments, linked deactivation)
  5. Billing as nav sections — a proposed set of billing-related screens/sections that Workstream 1 candidates must accommodate

Deliverable for 2.5:

The billing integration brief — a self-contained document that tells the nav redesign team "these are the billing screens and features that need a home in your navigation structure."

Phase 3: Convergence

3.1 — Place Billing Into Navigation Candidates

Take each of the 3 candidates from Workstream 1 (step 1.5) and the billing requirements from Workstream 2 (step 2.5). For each candidate:

3.2 — Re-Score Combined Candidates

Re-run the task walkthroughs from step 1.5, but now with billing integrated. Pay specific attention to:

3.3 — Select Top Candidate

Based on the re-scored comparison:

Deliverable for Phase 3:

A convergence report with the recommended navigation structure, billing placement rationale, and comparison against alternatives.

Phase 4: Open Questions

4.1 — Questions from the Interview (Already Identified)

These were flagged in the Interview Report and need resolution before finalizing the design:

Question Why it matters How to resolve
Content cloning: linked or copied? Determines whether "Content" is per-semester or shared. Affects nav structure — do you access content within a semester context or globally? Decision from PM. Technical input on what the backend supports.
Promotion workflow sequencing: what should gate payment setup? Determines the semester close workflow and whether payment setup is inside or after the promotion flow. Decision from PM based on operational reality.
Support staff access: what do they need to handle billing independently? Determines whether billing screens need role-based views (support sees read-only payment data vs. admin sees full controls). Quick check with PM on what support currently escalates.
Scholarship and deferment volume Determines whether these need full CRUD features or lightweight tagging on student profiles. Numbers from PM or from Stripe/Sheets data.

4.2 — Questions from Billing Discovery (Will Emerge from Workstream 2)

These can't be fully predicted now but will likely include:

4.3 — Do We Need Another Interview?

Assessment based on current information:

For the navigation redesign, we likely have enough. The interview covered all three phases, the admin's mental model, pain points, workarounds, and preferences. The capability map documents every screen. What we're doing is design work — proposing structures and evaluating them — not discovery work.

For billing, we may need targeted follow-up questions (not a full interview) to fill specific gaps:

Recommendation: No second full interview. Instead, prepare a short list of 5–8 specific questions that emerge from Workstream 2, and get answers asynchronously (email or quick call). These questions will be known after steps 2.1 and 2.2 are complete.

Deliverable for Phase 4:

Resolved answers for all open questions, either from existing data or from targeted follow-up. Any unresolved questions documented with impact assessment.

Phase 5: Final Output

The output of this plan is a single recommended navigation structure with:

  1. Full navigation tree with every screen placed
  2. Billing screens and features integrated
  3. Task walkthrough evidence showing improvement over current state
  4. Open questions resolved or documented with mitigation
  5. Ready for the next step: mockup walkthrough with the admin (validation — not part of this plan)

Execution Notes

What can be delegated

What needs the decision-maker

Dependencies

Reference Documents