Admin Navigation Interview Report

ADMIN NAVIGATION INTERVIEW REPORT

Interview Summary

The interviewee is the QuranFlow admin and Product Manager — the primary power user of the backend system. The interview focused on understanding workflow pain points across the three semester phases (setup, active, close) to inform a navigation redesign. She has deep institutional knowledge of the system, including all its workarounds and gaps.

Key Findings

Top Pain Points

• Semester setup is almost entirely manual and repetitive. Content (videos, submissions, resources, live sessions, quizzes, welcome packages) must be re-uploaded or re-configured every semester from scratch, despite being largely the same. This is time-consuming and error-prone.
• Semester status switching is manual and risky. There is no automatic transition between old and new active semesters, and accidentally leaving an old semester active corrupts student profiles. This has happened.
• Payment and billing has no presence in the backend. All payment data, family plans, discounts, scholarships, and deferments live in Google Sheets. This forces every student support interaction to span multiple external tools and creates information asymmetry between admin and support staff.
• Student deactivation is a two-step process (backend account + Stripe payment) with no link between the two, leading to students retaining access or being charged after unenrolling.
• Semester close payment setup is premature and fragile. Stripe payments for continuing students are configured before promotion decisions are finalized, creating a cascade of corrections when teacher assessments, student decisions, or automation results don't align.
• EOC (end-of-course) assessment and promotion logic has edge cases that send wrong automation emails — particularly around students near the 12-submission threshold, late submissions, and teacher discretion overriding automation criteria.
• The dashboard provides no actionable information. It doesn't surface exceptions, alerts, or operational metrics that would reflect real daily work.
• Navigation is unintuitive and undocumented. Settings is a catch-all, "Students Management" contains unrelated tools, reports are unexplained and some non-functional, and items are placed based on historical patching rather than logic.

Mental Model Insights

She thinks in terms of domains of responsibility, not data types. Her proposed structure:

1. Student Management — everything affecting a student (profile, level, payments, teacher, submissions)
2. Semester Management — dates, automation triggers, status transitions, email schedules
3. Content — passive content students consume (videos, resources, recordings, tutorials)
4. Scheduling — live sessions and 1:1 appointments together as the "live component"
5. Teacher Management — TA profiles, access, assignment
6. Reporting — holistic, all reports in one place with full data exports
7. Misc/Admin — everything else

This is notably different from the current structure: Teachers and Students are separated (not both under "People"), Scheduling is its own domain, and Settings is broken up and distributed to where things actually belong.

Workarounds in Use

• Google Sheets for: TA weekly schedules, family payment plans, scholarship tracking, deferment tracking, EOC assessment outcomes, initial placement assessment notes, semester-end student status overview
• Stripe (external): All payment and subscription management
• Vimeo (external): Checking recording links
• Mental/manual tracking: Student history across semesters, who is new vs. repeat vs. graduating

Requests & Wishes

• Automatic semester activation/deactivation based on start date
• Content cloning from one semester to the next (or persistent content available to all semesters)
• TA schedule cloning between semesters
• Repeat student auto-assignment to their previous teacher
• Welcome package persistence (edit, don't re-upload)
• Full payment and billing management integrated into the backend, including family plans, discounts, scholarships, deferments
• Student profile showing: full semester history, levels per semester, electives, all appointments, payment status, sign-up date, submission delete capability
• Student-facing issue reporting that surfaces in the admin dashboard
• Dashboard with: app issue reports, Year 2 appointment utilization, session attendance, TA submission response time alerts (48hr flag), failed payment alerts, students falling behind on submissions
• Calendar view of all live sessions and 1:1 appointments across all TAs, filterable by gender
• Semester close workflow where promotion decisions precede payment setup
• Linked student deactivation + payment cancellation as a single action
• Better labeling and inline documentation throughout the backend

Full Q&A Transcript

Q1: During semester setup, what's the one thing that takes longer than it should, or that you've had to redo because something was missed?

A: Multiple pain points identified: confusing date fields with no explanation of their downstream effects; registration status and active/inactive status are unintuitive and have caused errors (leaving old semester active); all program content must be manually re-uploaded each semester; teachers must be manually moved to new semesters; TA appointment schedules cannot be cloned; repeat students aren't auto-assigned to previous teachers; welcome packages (21 documents) must be re-uploaded individually each semester; automation emails require manual updating each semester.

Q2: During an active semester, what information do you wish was on one screen but isn't?

A: A consolidated student profile showing level, TA, gender, semester history, submission count, and payment status. Currently payment data is entirely absent from the backend. Sign-up date is unreliable. Year 2 students lack appointment history on their profiles. No visibility into electives taken in prior semesters. Admins cannot delete/reset individual student submissions. Recordings require going to Vimeo. All payment data requires going to Stripe. Special pricing, family plans, and discounts are tracked in Google Sheets. TA schedules require a separate spreadsheet for a full weekly overview. No calendar view of all sessions. No report of student body composition (new vs. repeat vs. graduating). Initial placement assessment notes have no home in the backend. EOC assessments are tracked in a sheet populated by teaching staff. Scholarship students are tracked externally. Deferment students are tracked externally.

Q3: What's the most manual or error-prone part of closing out a semester and promoting students?

A: Automation handles standard promotions (12+ submissions, last submission ≥3.5) but breaks down in edge cases: teacher discretion overrides automation criteria; semester length variation (16 vs. 17 weeks) affects who qualifies; teachers sometimes assign sub-3.5 grades on submission 12+ despite instructions, triggering incorrect repeat emails. Setting up Stripe payments for continuing students before promotions are finalized creates corrections when students opt out, switch plans, or teachers change pass/fail decisions. Student deactivation requires a separate manual step in Stripe.

Q4: Would you organize navigation by what things are, or by what you're trying to do?

A: By domain of responsibility: Student Management, Semester Management, Content, Scheduling, Teacher Management, Reporting, and Miscellaneous admin tools.

Q5: Which Google Sheet would cause the most relief if eliminated first?

A: Payment and billing management — it touches the most workflows and causes the most cross-tool friction.

Q6: What's currently grouped together that feels wrong, or separated that you reach for at the same time?

A: Dashboard is inaccurate and unhelpful. "Students Management" under People contains unrelated tools (welcome videos, etc.). Reports section has unexplained, non-functional reports. Holidays should apply to all live sessions, not just appointments. Settings is a catch-all: welcome package belongs under content/program, teacher assignment criteria doesn't belong in Settings. Overall navigation lacks documentation and logic, making it hard to remember where things are.

Q7: What would be on a dashboard that reflected your real daily work?

A: Student-reported app issues, Year 2 appointment utilization for the week, session attendance numbers, TA submission response time alerts (flagging >48 hours), failed payment alerts for instalment plan students, students falling behind on submissions.

Q8: Is there a task you avoid or delay because it's too cumbersome?

A: Manually uploading all semester content (time-consuming, error-prone, requires extensive double-checking). Setting up Stripe payments for continuing students (risky, frequently requires corrections, and is decoupled from the student deactivation process in the backend).

Q9: What's the single most frustrating thing about how the admin panel is organized?

A: If adding one thing: billing and payment management. If reorganizing: restructuring by the six domains she described, with clear inline documentation explaining what each feature does and how it affects other processes.

Recommendations for Navigation Redesign

1. Adopt a domain-based navigation structure. Replace the current object-type navigation with the six domains the admin naturally thinks in: Student Management, Semester Management, Content, Scheduling, Teacher Management, and Reporting. This reduces the cross-section jumping that currently makes single workflows span 5–9 screens. The "Students Management" grab-bag page should be eliminated and its tools redistributed to their correct domains.

2. Build a Semester Management hub as a priority. This is the highest-friction workflow. A dedicated semester hub should show all configuration in one place: dates with plain-language explanations of their effects, automation schedule with a preview of which emails go to whom and when, content status (what has been set up vs. still needed), and a semester transition tool that handles activation/deactivation as a single action. Auto-activation based on start date should be the end state.

3. Integrate payment and billing as a first-class feature. This is the single highest-impact gap. A payment management section should surface Stripe data within the backend, link payment status to student profiles, connect deactivation to subscription cancellation, and eliminate the Google Sheets used for family plans, discounts, scholarships, and deferments. Until this exists, support staff will always need admin escalation for basic billing questions.

4. Redesign the dashboard as an exceptions and alerts surface. Replace the current passive stats dashboard with an operational view: app issues reported by students, TA response time flags, failed payments, students falling behind, and appointment utilization. This shifts the admin from reactive (students email in) to proactive (system surfaces problems early).

5. Add inline documentation throughout. Many fields, reports, and settings are opaque without institutional knowledge. Tooltips or inline descriptions — particularly on semester date fields, status toggles, and reports — would reduce errors and reduce dependency on the admin being the sole source of system knowledge.

Questions for Further Investigation

• Content cloning scope: Should cloned content be linked (changes propagate) or copied (independent per semester)? This has implications for versioning and consistency across semesters.
• Promotion workflow redesign: At what point in the semester close process should payment setup be triggered? Is there a logical gate (e.g., EOC submitted by teacher) that could sequence this more safely?
• TA gender filtering: How is gender matching between students and TAs currently handled, and is it a hard rule or a preference? This affects how scheduling views should be designed.
• Support staff access: What does the customer support team currently have access to, and what would they need to handle billing questions independently? This shapes what goes in a "view-only" admin role vs. full admin.
• Scholarship and deferment volume: How many students per semester fall into these special categories? Understanding volume helps prioritize whether a full feature or a simpler tagging/notes system is appropriate.