QuranFlow Admin Redesign

Before you can redesign a system, you have to understand everything it does. Not what people say it does — what it actually does, screen by screen, field by field.

The QuranFlow admin backend has 35+ screens spread across 9 navigation sections, backed by 10 database tables and integrations with Stripe (payments), Vimeo (video hosting), and InfusionSoft (email automation). Every screen was documented: what data it shows, what actions it supports, what business rules it enforces.

The capability map revealed a structural pattern: the backend is organized by data type. There's a "Students" section, a "Semesters" section, a "Program" section. Each maps to a database table. This seems logical — until you try to actually use it.

The capability map documented the system. The interview revealed how it fails.

The admin — the primary power user who manages students, semesters, billing, and content daily — walked through her real workflows. Five pain points emerged:

1. Semester setup is entirely manual. Content must be re-uploaded from scratch every semester. 19+ screens, 50-80 clicks, 3 external tools.
2. Billing has zero presence in the backend. All payment data — subscriptions, family plans, scholarships, deferments — lives in Google Sheets and Stripe. Support staff can't answer basic billing questions without escalating.
3. Student deactivation is disconnected from payment cancellation. Two steps, two systems, no link between them.
4. The dashboard provides no actionable information. It shows passive stats. No alerts, no failed payments, no TA response times.
5. Navigation is organized by data type, but the admin thinks in domains of responsibility.

That last point was the critical reframe. When asked how she'd organize the backend, her answer wasn't "Students, Lessons, Reports" (the current structure). It was:

Student Management, Semester Management, Content, Scheduling, Teacher Management, Reporting, and Miscellaneous.

She doesn't think in database tables. She thinks in areas of responsibility. The current navigation forces her mental model into a structure that doesn't match how she works — which is why single workflows span 5-9 screens across multiple sections.

The interview revealed two distinct problems that need different research methods:

Navigation — Which organizational principle should govern the backend? This requires framework analysis: study different ways to organize admin tools, map real workflows through each option, score them, pick a winner. It's a design problem.

Billing — What billing data exists, where does it live, and what would it take to bring it into the admin backend? This requires technical discovery: audit code repositories, analyze Stripe's API, document every Google Sheet workaround. It's a research problem.

These problems are independent. Navigation research doesn't need billing data, and billing discovery doesn't need navigation decisions. So we split into two parallel workstreams that converge when both are complete.

This is a theme in AI-assisted product work: you can't just ask the AI to "redesign the admin backend." The problem is too large and too ambiguous. You have to decompose it into structured phases, each with a defined input, methodology, and deliverable. The next five steps are those phases.

There are fundamentally different ways to organize an admin backend. The current system uses one (organize by data type). But there are at least five others, each with different assumptions about how the admin thinks and works. Before choosing, we analyzed all six:

Each framework was analyzed against the admin's interview data: what assumptions does it make about how the admin thinks? What does it do well? Where does it break down?

In parallel, we mapped six real admin workflows step-by-step through the current system. This produced the baseline data every candidate would be measured against:

The numbers made the problem concrete. Semester setup alone: 19 screens, 50-80 clicks, 3 external tools. Any candidate that doesn't dramatically reduce these numbers isn't worth building.

With workflow evidence, three frameworks were eliminated as standalone navigation paradigms. Not because they're bad ideas — because each has a structural flaw that disqualifies it as the primary organizing principle:

• Object-Based eliminated — it's the current system, and it's the problem. Scored lowest on mental model match (2/5). The admin explicitly rejected it.
• Workflow-Based eliminated — guided wizards constrain power users. Edge cases (which the admin deals with constantly) break codified flows.
• Phase-Based eliminated — semester phases overlap in practice. A nav that changes by phase confuses TAs who log in irregularly.

But elimination doesn't mean discarding their best ideas. From each eliminated framework, we borrowed specific features that every surviving candidate must include:

• From Workflow: a semester setup checklist and a gated close workflow (payment setup blocked until promotions are complete)
• From Phase: phase-aware dashboard prompts ("semester close approaching — 4 items need attention")

The three survivors became three hybrid candidates, each specified down to the screen level — complete navigation trees, screen placement maps for all 35 existing screens, new screens introduced:

A navigation design can look good on paper and fail in practice. The only way to know: walk real workflows through it. Every workflow from Step 4 was traced through every candidate — exact screen paths, click counts, information co-location, external tool dependencies.

The results:

Enhanced Candidate A won. Domain-first navigation matching how the admin actually thinks, augmented with the strongest ideas from the other two:

• From B: an operational dashboard with configurable alert tiles and phase-aware prompts
• From C: global search resolving to entity pages from any screen

The projected improvements across all 6 workflows:

While Workstream 1 solved how to organize the backend, Workstream 2 tackled the system's biggest missing capability: billing has zero presence in the admin interface.

The admin manages payments weekly — but entirely outside the backend. Five code repositories were audited to understand what billing infrastructure exists. The checkout pipeline was traced end-to-end: frontend checkout → webhook processing → Stripe subscription creation → and then... nothing. Subscription data flows into Stripe and stays there. The admin backend never reads it.

Every Google Sheet workaround was documented:

Stripe's API was analyzed for what data could surface in the admin backend. The finding: Stripe has everything — subscription status, payment history, failure reasons, coupon redemptions. The data exists. It just isn't visible.

Six new billing screens were defined: Payment Overview, Payment Plans (enhanced), Coupons (enhanced), Family Plans, Scholarships & Deferments, plus billing tabs on student and semester entity pages.

The two workstreams converged. Enhanced Candidate A provided the 8+1 domain navigation structure. Billing discovery provided the requirements for six new billing screens plus entity-level payment tabs. The result: a complete, mockup-ready specification.

Each of the 11 spec files is detailed enough to build from without asking clarifying questions: every column, filter, action, state, role-based visibility rule, and data source for every screen.

The three most specified areas — each required the depth of a mini-application:

• Student Detail Page: 6 tabs consolidating what currently requires 5-7 screens. The profile the admin asked for in the interview — "level, TA, gender, semester history, submission count, and payment status on one screen."
• Semester Hub: 4 tabs including a gated Close Workflow that blocks payment setup until promotions are complete — directly solving the admin's most dangerous pain point.
• Billing & Payments: 6 screens bringing Stripe data into the admin backend for the first time, plus entity-level tabs so payment status appears in context.

The specification was translated into a working interactive prototype.

Built in 13 phases, each producing committed, navigable screens. Complex screens first (Student Detail, Semester Hub Close Workflow, Billing) — they set patterns that simpler screens follow. Six independent content screens were built in parallel. Stripe's admin UI served as the design reference: data-dense tables, inline status badges, metric cards with trends.

After the initial build, every screen was audited line-by-line against its specification. 52 deviations found — missing columns, incorrect filters, wrong badge colors, absent empty states. 44 resolved across four batches. This is the work that separates a demo from a specification-accurate prototype: ensuring that what you see matches what the spec says, so that future engineering decisions can reference the mockup with confidence.

The three screens that demonstrate the redesign's impact:

• Dashboard: Seven alert tiles (failed payments, pending submissions, TA response times, appointment utilization, semester phase status, app issues, student snapshot) replace what was a page of passive statistics. The admin's daily monitoring workflow drops from 4-5 screens with 3 external tools to one screen with zero external tools.
• Student Detail Page: One entity page with six tabs replaces the current 5-7 screen workflow for handling a student support issue. Profile, submissions, payments (from Stripe), appointments, semester history, and actions — all on one page. The consolidated student profile the admin asked for in the interview, built exactly as described.
• Semester Hub Close Workflow: A five-step gated sequence that enforces: EOC review complete → promotions finalized → payment setup begins → deactivation processed → semester archived. Payment setup is literally blocked until promotions are marked complete — directly preventing the cascading corrections that were the admin's most painful operational problem.