QuranFlow iOS Redesign

Kamran walked through every screen of the QuranFlow iOS app while recording a voice transcript — a natural walkthrough documenting real reactions to what each screen showed.

The 47-line transcript captured specific moments of confusion, frustration, and broken features. The 23 screenshots were taken chronologically, following the user flow from home screen to settings.

This raw input — reactions like "this is hideous" and "complete fail" — provided the starting material for every step that followed.

The raw transcript was transformed into a structured audit using Nielsen Norman Group's UX methodology and the HEART metrics framework (Happiness, Engagement, Adoption, Retention, Task Success).

491 lines of analysis, organized screen-by-screen across 12 areas of the app. Every issue was assigned a severity level:

The six P0 issues — the ones blocking core functionality:

1. Video Playback Failure
2. Missing Submission History
3. Non-Standard Quranic Font (hidden in settings)
4. No Timezone Information on live sessions
5. Broken Notification Context
6. Critical Missing Information in User Profile

The audit produced a severity-ranked inventory of problems. What it didn't explain was why these problems existed — that required someone who works with students daily.

The audit was an outside perspective. Meeting with Lejla — the program manager who works with students daily — revealed what it missed.

New discoveries:

• A hidden recordings section the audit missed entirely
• A schedule buried behind five clicks
• Students accidentally submitting recordings when they meant to press play

More importantly, the discussion reframed the problem. The core issue isn't individual broken features — it's user disorientation. Students don't know where they are in the program, what to do next, or when things happen. Despite receiving five emails announcing the October 2nd semester start, students still email three weeks in asking when it begins.

"Make everything super clear. Even having a schedule that's hidden behind five clicks is an issue. Them not seeing when the semester starts is an issue. Them not being spoon-fed what they should be doing is an issue."

This shifted the question from "how do we fix this screen?" to "how do we solve disorientation?" — which removed the constraint of the current app's structure entirely.

A capability map is a document that defines everything a user needs to be able to do — independent of how the app is currently structured. Instead of asking "how do we fix this screen?", the question becomes "what does the student need to accomplish?"

This is the key methodological shift. By documenting 68 discrete tasks across the full student lifecycle — from pre-semester enrollment through weekly learning cycles to end-of-semester transitions — we removed the constraint of the existing app's screen structure entirely. The redesign could start from first principles.

Each task was tagged by priority:

• [Core] — The app fundamentally fails without this
• [Supporting] — Significantly improves the experience
• [Enhancement] — Polish items

The document also includes a gap analysis — four categories of problems discovered when comparing what students need against what the app provides:

• P0 bugs: 7 items blocking core functionality
• Missing capabilities: 8 features that don't exist (semester countdown, calendar integration, direct coach messaging)
• Discoverability gaps: 7 features that exist but are hidden (font settings, recordings, support)
• Design gaps: 5 areas where UI design makes features unusable

Every gap traces back to the disorientation problem identified in Step 3. This document became the single source of truth for everything that followed.

Before designing the new architecture, we gathered two external references to measure against.

Apple's WWDC25 "App Redesign Field Guide" session was extracted from the YouTube video into a structured reference document using Gemini (Google's AI). It provided the framework we'd use to evaluate every design decision: the "Three Questions" test (Where am I? What can I do? Where can I go?), progressive disclosure patterns, and tab bar guidelines.

Headspace iOS screenshots served as design reference — a well-designed learning app for a similar audience: people with daily practice habits who need structured guidance without complexity.

A prompt is the detailed written brief given to Claude (Anthropic's AI) specifying what to analyze and produce. The goal here: write a prompt that produces three distinct architecture proposals for the app. It took five attempts. Each version was a direct response to what the previous version failed to produce.

Each version refined the framing. The shift that worked: v5 moved from "here's the problem, propose solutions" to "here's a structured process for arriving at solutions" — analyze the problem first, then design.

The v5 prompt produced three architectures, each organized around a different principle:

Proposal A was selected. QuranFlow is a 15-week program with weekly lessons and weekly submissions. Making time the organizing principle — "Week 8 of 15" — directly addresses disorientation. Students immediately know where they are.

Key advantages of Weekly Rhythm:

• Schedule becomes one tap instead of five clicks
• Lesson, submission, and feedback grouped by week — matching how students think
• Passes all three WWDC25 validation tests

The first visual implementation of Proposal A: five screens (Today, Learn, Submit, Schedule, More) built as a React prototype.

Design review found 80% alignment with the architecture and 57% capability coverage:

Schedule and Submit were near-perfect. The Today page scored 60% — missing the "Week 8 of 15" temporal orientation that was the architecture's central feature. A key structural issue: Submit existed as a standalone tab instead of being unified into Learn.

These specific failures informed what to fix in the second exploration.

Two months after Exploration A, the second attempt addressed every documented failure. Correct 5-tab structure, improved Today page, and an entirely new Progress tab.

92% alignment — up from 80%:

The "Week 8 of 15" hero block solved temporal disorientation. The unified Learn tab grouped lesson, submission, and feedback by week. The WWDC25 "Three Questions" test went from 1/3 passing to 3/3.

Still missing: recording interface, feedback detail screens, video playback, onboarding, and several detail modals. Building these required a deeper specification — the subject of the next two steps.

Steps 6–9 were exploration — three proposals, two mockups, documented failures. This step shifted to execution.

The v6 prompt was fundamentally different from v1–v5. Instead of asking for multiple proposals, it locked in Weekly Rhythm and asked for one deep, implementation-ready architecture. Instead of running as a single pass, it split the work across five sequential AI passes — each focused on one layer of the design, building on the previous output:

1. Problem Brief — distill all prior research
2. Design Principles — governing rules for every decision
3. Learnings — what worked and didn't in Mockups v1 and v2
4. Architecture — full screen-by-screen specifications
5. Validation — capability coverage check against the original map

v1–v5 explored the design space. v6 executed within it — one locked direction, maximum depth.

The five passes ran sequentially, each building on the previous output:

Phase 5 returned a CONDITIONAL PASS (meets requirements with minor gaps): 24 of 27 core tasks fully covered, 3 partially covered, 0 missing. All 7 original P0 issues addressed.

A subsequent Phase 6 provided the visual design language and mockup-specific implementation guidance.

The architecture specification was translated into an interactive prototype — 13 screens covering every part of the student experience: Today, Learn, Schedule, Recording, Profile, Video Player, multi-step Onboarding, Notification Sheet, Notification Settings, Personal Details, Subscription, and Manage Subscription.

Where Mockups v1 and v2 were surface-level explorations — tab structure, layout, visual direction — this mockup goes deeper. It handles real usage states: what do you see when you're behind schedule? When you have no sessions today? When you're mid-lesson with two videos watched? The onboarding flow walks new students through choosing their Quran font, setting notification preferences, and understanding the weekly rhythm — none of which existed in any previous version.

The Quran font picker is a good example of this depth. The original app buried font selection in settings — one of the six P0 issues from the audit. The redesign surfaces it during onboarding, where students see actual Arabic script rendered in each font and pick what's easiest for them to read. It's a small screen, but it represents the shift from "features exist somewhere" to "features appear when the student needs them."

The Weekly Rhythm principle runs through every screen. Today shows "Week 8 of 15" with the current lesson and upcoming sessions. Learn groups lesson, submission, and feedback by week. Schedule is one tap away instead of five clicks deep. Compared to the original app — where students couldn't find the schedule, didn't know what week they were in, and accidentally submitted recordings — every screen now answers the three WWDC25 questions: Where am I? What can I do? Where can I go?

Try the interactive mockup →

Lejla's key concern: the redesign adds information clarity but introduces cognitive load. The target audience — busy adult learners, some with ADHD or dyslexia — valued the old app's simplicity even when it was broken.

This created a tension: the audit found confusion from missing information, but adding that information increases visual complexity. Five solution approaches were evaluated. The result: 8 Tier 1 changes, all validated against Apple Human Interface Guidelines:

1. Remove progress ring — redundant, ambiguous, competes for attention
2. Remove countdown timer — not actionable, induces anxiety
3. Rename labels for clarity — "Your Lesson" not "Video Lesson," "Your Recording" not "Submission"
4. Clarify section headers — "Today's Live Sessions" not "Today's Sessions"
5. Reduce session cards — 2 instead of 3 (third was below fold)
6. Simplify level subtitle — "Level 2" not "Level 2 — Reading with Fluency"
7. Design self-explaining empty states — cards communicate meaning even with no data
8. Show next session in empty state — when nothing is scheduled today

The guiding principle: reduce without losing orientation. Every removal was validated against the original disorientation problem to ensure we weren't reintroducing the confusion we set out to fix.