Phase 2 — Design Principles

Phase 2 -- Design Principles & Quality Bar

Version: 1.0 Date: February 25, 2026 Input: WWDC25 Field Guide + Phase 1 Problem Brief Organizing Principle: Weekly Rhythm -- "The app follows my weekly learning cycle."

Preamble: What This Phase Is For

The WWDC25 Field Guide presents four diagnostic layers -- Structure, Navigation, Content, Visuals -- and a set of tests to apply at each layer. Phase 2 uses those tests not to audit the current app but to establish the standards the new architecture must meet. Every principle below is derived from the Field Guide and then sharpened against a specific QuranFlow failure from the Phase 1 problem brief.

The goal is a quality bar that is concrete enough to fail. Vague goals ("the app should feel clear") cannot be tested. Each criterion below can be answered with yes or no.

The 3 Questions Test

The WWDC25 Field Guide states this directly: "Before touching a pixel, the app must answer The 3 Critical User Questions immediately upon launch. If the user has to guess, the design has failed."

QuranFlow's current home screen fails all three. A student opens the app and sees a tab bar with unlabeled icons, a lesson list with no week context, and a hamburger menu that hides their level, coach, schedule, and every orientation tool they need. The disorientation problem identified in Phase 1 is not a content problem -- it is a structure problem. The app never tells the student where they are in time or in sequence.

The new architecture must answer all three questions from the home screen, without scrolling, on every launch, for every lifecycle phase.

Question	The Architecture Must Provide	How
Where am I?	The student's current position in the semester, stated explicitly: week number, level, and semester phase (Pre-Semester / Active / End-of-Course)	A persistent week indicator at the top of the Home tab that reads something like "Week 7 of 15 -- Level 2" with the semester phase readable in context. This must be the first thing the eye lands on. No inference required -- the student should not have to count unlocked submissions to figure out what week it is.
What can I do?	The single most important action available right now, visible without scrolling	A "This Week" card on the Home screen showing the weekly task state: lesson status, submission status, feedback status. The primary incomplete action is foregrounded. If the lesson is watched and the submission is not yet done, the card shows "Record this week's submission." If feedback has arrived, it shows "You have feedback from your Coach." The card collapses completed items so the student always sees what remains, not what is finished.
Where can I go?	A tab bar with exactly the right destinations, labeled plainly, each one a place not an action	A tab bar of no more than 4 tabs, each representing a distinct destination a student legitimately returns to: Home (current week), Learn (all lessons), Live (schedule), and a fourth covering history/profile. Every tab label is a noun, not a verb. The student can glance at the bar and know which tab holds what. No hamburger menu anywhere.

Tab Worthiness Criteria

The Field Guide test is: Is it a destination? If yes, it belongs on the tab bar. Is it an action or a subset? If yes, it does not.

QuranFlow's current navigation violates this at every level. The hamburger menu makes destinations invisible. The top-of-screen tabs (the current pattern) mix destinations with filtered views of the same data. Some items that should be tabs (Feedback, Schedule) are buried. Some items that should not be tabs (the "+" record action on some screens) are treated as primary navigation.

The following criteria govern every tab bar decision in this architecture:

A tab is worthy if:

It is a place, not an action. The student navigates to it. Tapping it changes their location in the app. Tapping "Record" is an action -- it triggers a flow, not a destination. Tapping "Learn" takes the student to a place they will return to repeatedly.
It is used at least once per week during an active semester. Frequency of return is the test. If a typical student visits a destination less than once per week, it does not belong on the tab bar -- it belongs one level deeper. The Live session schedule meets this bar. The Settings screen does not.
Its absence would leave the student unable to complete a core task. The tab bar must cover the full critical path of the weekly rhythm: learn, submit, receive feedback, attend live sessions. Any destination not reachable from the tab bar must still be reachable in 2 taps from a tab.
It represents a coherent, self-contained information space. A tab contains things that belong together. The Learn tab contains lessons. The Live tab contains scheduled sessions and session recordings. A tab is not a dumping ground for loosely related features.

A tab is NOT worthy if:

It is a subset of another tab. Submission history is a subset of the student's learning record, not a top-level destination. Feedback archives are a subset of submission history. Neither warrants its own tab.
It is an action. Record, Submit, Add -- these are toolbar or inline actions. Placing an action on the tab bar confuses navigation with task initiation.
It is administrative. Password change, notification settings, billing details -- these are settings-layer content. A Settings or Profile tab may house them, but they do not each deserve a tab.
It serves only one lifecycle phase. Pre-semester orientation content, the EOC assessment flow, and Year 2 appointment booking are all important but phase-specific. They should surface contextually (as cards, banners, or state changes) within the existing tabs, not as dedicated tabs that are empty or irrelevant 90% of the time.

The 4-tab ceiling. QuranFlow's core weekly rhythm involves exactly four types of activity: orienting to the week (Home), learning the lesson (Learn), submitting and receiving feedback (could be unified as Practice or My Progress), and attending live sessions (Live). Four tabs. Any proposal for a fifth tab requires justification against the criteria above and against the organizing principle.

Content Principles

The WWDC25 Field Guide identifies three content-layer principles: Progressive Disclosure, layout selection (Grid vs. List vs. Collection), and grouping by human logic (Time, Progress, Pattern). Each maps directly to a QuranFlow failure.

1. Progressive Disclosure -- The Most Critical Principle for QuranFlow

The Field Guide pattern: Show the top 5 items in a collection (horizontal scroll), add a disclosure indicator, let the user tap through to the full list.

The QuranFlow problem it solves: The current Live session screen is described in the Phase 1 brief as "a wall of unstructured text." There are up to 20 live sessions per week (Quran Reading Circles, Level Classes, Office Hours) spanning multiple timings and days. Dumping all of them onto one screen means students "cannot find sessions they know are scheduled." The same problem occurs in the feedback archive (a flat list of every submission, requiring month/year filters) and in Resources (15+ items with no hierarchy).

How to apply it in QuranFlow: The Home screen applies progressive disclosure by surfacing only the current week's relevant sessions, not all sessions. The full schedule is one tap away via "See All" or the Live tab. The Learn tab shows the current week's lesson at the top, with prior weeks accessible via "See All Lessons." The feedback detail within a submission shows the coach's audio note and a summary of the comment; a "See full thread" action reveals the full comment history. Nothing is hidden permanently -- everything is one tap deeper.

The rule: No screen in the new architecture shows more than 7 items without a progressive disclosure mechanism. If a list can grow beyond 7 items, it must have a natural entry point (the top 3-5 most relevant) and a "See All" escape.

2. Grouping by Time and Progress -- Not by Feature Type

The Field Guide pattern: Group by human-centric themes: Time (Recent, This Week), Progress (Continue Watching, Drafts), Pattern (Genre, Related).

The QuranFlow problem it solves: The current architecture groups by feature type -- there is a Lessons tab, a Submissions tab, a Feedback tab. But the student does not think in feature types. They think in weeks. "What did I do in Week 6?" should return: the lesson video, the submission recording, the coach's audio feedback, and whether they attended the live session. These four things currently live in four different places with no linking mechanism.

How to apply it in QuranFlow: Time-grouping is the primary grouping strategy. The Home screen is organized around "This Week." A history view (whether in a dedicated tab or within the Practice/Progress tab) groups submissions chronologically by week: "Week 6," "Week 5," and so on -- each entry expanding to show lesson, submission, and feedback together. The Live schedule is grouped by day, then by session type, not by a flat alphabetical list of session names. Progress grouping is applied at the macro level: the student can see what is complete, what is in-progress, and what is upcoming.

The rule: Items that belong to the same week of the student's learning journey must be co-located or cross-linked. The Week 7 lesson, the Week 7 submission, and the Week 7 feedback are one unified record, not three separate items in three separate tabs.

3. Layout Selection -- List Over Grid for QuranFlow's Data

The Field Guide rule: Use grids for highly visual items (album art, photos). Use lists for text-dense or heterogeneous data. Use horizontal collections for themed groupings where you want to show a sample and let the user dive deeper.

The QuranFlow problem it solves: The core data in QuranFlow is text-heavy and status-driven: lesson titles, week numbers, submission states (Not started / In progress / Submitted / Feedback received), coach names, session times. None of this is primarily visual. A grid layout would sacrifice scannability for aesthetics. The student scanning for "Week 8 submission" needs to read titles and states quickly -- a list is correct.

How to apply it in QuranFlow: Lists are the default layout for lessons, submissions, feedback history, and live sessions. Horizontal collection rows (5 items with a "See All" disclosure) are appropriate for the Home screen to surface the current week's sessions without overwhelming the screen. A grid layout is acceptable only where visual differentiation is the point -- for example, coach avatars in a hypothetical coach directory, or thumbnail previews for session recordings. The default is always list.

The rule: No grid layout without a clear visual differentiator for each item. If the primary differentiator is text (a title, a date, a status), use a list.

4. The Squint Test Applied to QuranFlow

The Field Guide test: Squint until the screen blurs. You should still be able to identify the most important element and the structure of the page. If the screen looks like a uniform grey blob, or a decorative element overpowers content, it fails.

The QuranFlow problem it solves: The Phase 1 brief notes that the progress screen shows "9%" with no label, a redundant circle and bar display, and legacy "QR" branding. A student squinting at that screen cannot identify what 9% means or whether it is good or bad. The Live session screen is a wall of text with no visual hierarchy -- everything has equal weight, so nothing is findable.

How to apply it in QuranFlow: Every screen must have one clear visual anchor -- the element that draws the eye first and communicates the most important information. On the Home screen, the anchor is the weekly status card. On the Learn screen, the anchor is the current week's lesson. On the Live screen, the anchor is the next upcoming session. The anchor must survive the squint test: even blurred, it should be readable as "the thing that matters most right now."

The rule: Each screen has exactly one primary visual anchor. If two elements compete equally for the eye, the hierarchy is broken.

5. Standard Titles and Navigation Over Custom Patterns

The Field Guide warning: "Branding Over Utility -- Large, decorative headers that look nice but don't explain the utility."

The QuranFlow problem it solves: The hamburger menu icon is the QuranFlow logo -- a small graphic that does not signal "navigation" to users who encounter it without training. Critical features are buried behind it. The current top tab bar uses a custom pattern that mixes contexts. Labels like "Feedback" are misread as "give feedback" rather than "receive feedback."

How to apply it in QuranFlow: All navigation uses iOS standard components: a tab bar at the bottom for global destinations, a navigation bar at the top with a clear screen title and contextual actions in the top-right. Screen titles are functional, not decorative. "My Submissions" not "Your Journey." "Live Sessions" not "Community." Labels on the tab bar are single nouns that exactly describe what the tab contains. Where there is any ambiguity about a label's direction (receive vs. give), the label is rewritten to remove it -- "Coach Feedback" rather than "Feedback."

Quality Bar

These are the specific, testable criteria the architecture must meet before it is considered complete. Each is a binary test: pass or fail. Partial credit does not count.

Structure Tests

S1 -- The 3 Questions Test (10-second rule) A person who has never used QuranFlow opens the app's Home screen and is asked: "What week of the semester is this? What should you do next?" They must answer correctly within 10 seconds, using only what is visible on screen, without scrolling. Pass: They answer correctly within 10 seconds. Fail: They cannot answer, answer incorrectly, or require scrolling.

S2 -- No Hamburger Menu The architecture contains zero hamburger menus, sidebar drawers accessed via a logo, or navigation patterns that are not part of the iOS standard tab bar + navigation bar system. Pass: None exist. Fail: Any exist.

S3 -- Core Task Reach in 2 Taps Every [Core] task from the Phase 1 task inventory is reachable from the tab bar in 2 taps or fewer. "Reachable" means the student arrives at the screen where the task begins -- not necessarily that the task is complete in 2 taps. Pass: All [Core] tasks satisfy the 2-tap rule. Fail: Any [Core] task requires 3 or more taps from the tab bar.

S4 -- Hidden Features Eliminated Every feature listed in the Phase 1 "Hidden Features Table" (Quranic font selector, student's level, Quran Coach identity, weekly schedule, session recordings, support/help, feedback archives, font size settings) is accessible from a primary tab or is surfaced contextually without requiring the student to know it exists. Pass: All 8 hidden features are discoverable without prior knowledge. Fail: Any of the 8 remain hidden.

Navigation Tests

N1 -- Tab Bar Destination Test Every tab on the tab bar passes the Tab Worthiness criteria: it is a destination (not an action), it is visited at least once per week during an active semester, and it represents a coherent information space. Pass: Every tab passes all three criteria. Fail: Any tab fails any criterion.

N2 -- No Actions on the Tab Bar The tab bar contains only nouns (destination labels). No tab initiates a workflow, creates a record, or performs an action. Pass: All tab labels are nouns; no tab triggers a flow. Fail: Any tab triggers an action rather than navigating to a destination.

N3 -- First Submission Without Help A new student, using only the app, can complete their first submission (watch lesson, view Quranic text, record, review, and submit) without reading an email, asking for help, or leaving the app. Pass: They complete the flow unassisted. Fail: They get stuck at any point and require external guidance.

N4 -- Return Test (5-second rule) A returning student who has not opened the app in 3 days opens it and can state their current submission status (submitted / not yet submitted / feedback received) within 5 seconds, without scrolling. Pass: Correct answer within 5 seconds. Fail: They cannot determine status, determine it incorrectly, or must scroll to find it.

Content Tests

C1 -- No Screen Exceeds 7 Unmediated Items Any list on any screen that can contain more than 7 items has a progressive disclosure mechanism (a "See All" link, a collapsed section, or a filtered default view). The default state shows no more than 7 items. Pass: No default list view shows more than 7 items without a disclosure mechanism. Fail: Any list shows 8 or more items in its default state without a "See All" path.

C2 -- The Squint Test (per screen) Each primary screen (Home, Learn, Live, and the fourth tab) has a clear visual anchor -- the single most visually prominent element. When the screen is blurred, the anchor is still identifiable as the dominant element. Pass: Each primary screen has one identifiable anchor. Fail: Any primary screen has two competing anchors, or no discernible anchor at all.

C3 -- Week-Grouped History A student looking for their Week 6 submission and feedback can find both in one location, grouped by week, without needing to navigate to separate tabs for submission vs. feedback. Pass: Week 6 submission and Week 6 feedback are co-located or cross-linked within one tap of each other. Fail: They live in separate tabs with no link between them.

C4 -- Timezone Always Displayed Every live session time display includes the timezone. There are no bare times (e.g., "7:00 PM") without an associated timezone label or confirmation that the display is in the user's local time. Pass: Every time display carries explicit timezone information. Fail: Any time is displayed without a timezone.

C5 -- Standard Quranic Font on First Encounter The first time a student views Quranic text to recite (at the submission screen), the text is displayed in the standard mushaf font (not the default non-mushaf font). The student does not need to visit Settings to correct the rendering. Pass: Mushaf font is active by default on first use. Fail: The student sees a non-standard font and must navigate to Settings to fix it.

Lifecycle Tests

L1 -- Pre-Semester State A student who has completed the initial assessment but whose semester has not yet started opens the app and sees: their assigned level, their Quran Coach's name, the number of days until semester start, and at least one action they can take now (such as watching orientation videos or attending a pre-semester housewarming session). Pass: All four elements are visible from the Home screen. Fail: Any element is missing or requires navigation beyond the Home screen to find.

L2 -- Behind Test (2 weeks behind) A student who is 2 weeks behind on submissions opens the app. They can see their current deficit (e.g., "You are 2 submissions behind -- you can submit up to 2 this week to catch up") and a direct path to begin catching up, all from the Home screen. The messaging is neutral and functional, not shame-inducing. Pass: Deficit is visible, the catch-up path is one tap away, and the language is neutral. Fail: The deficit is not shown, the path requires more than 2 taps, or the language implies failure.

L3 -- EOC Phase State A student who has completed 12 of 15 submissions opens the app during the End-of-Course Assessment phase. The Home screen shows a distinct EOC state: what the EOC is, that they are eligible to submit it, and a direct path to the EOC submission screen. Pass: EOC card is visible on Home screen; student can reach EOC submission in 2 taps. Fail: EOC is not surfaced, is indistinguishable from a regular submission, or requires more than 2 taps.

L4 -- Recovery Test A confused student who does not know what to do next can find a support path (whether that is in-app help, a way to contact their Quran Coach, or a link to support) within 2 taps from any screen. Pass: Support is reachable in 2 taps from any screen. Fail: Any screen requires more than 2 taps to reach support, or there is no visible support affordance.

Notification Tests

V1 -- Notification Deep Links Every push notification delivers the student to the specific content referenced. A "feedback received" notification navigates to the feedback for the specific submission. A "new lesson available" notification navigates to that lesson. Pass: Every notification type has a functional deep link. Fail: Any notification lands on the app's home screen or a generic tab without context.

V2 -- Notification Content Every push notification contains: what happened, which submission or session it refers to (by week number and title), and when it happened (relative timestamp). Pass: All three elements are present in every notification type. Fail: Any notification is missing any of the three elements.

Principle Priority Stack

When design decisions must trade off against each other, apply this stack in order:

Temporal orientation first. If a screen does not tell the student where they are in time, it fails the organizing principle. This takes precedence over aesthetic choices, information density preferences, and feature completeness.
Guidance over flexibility for the Home screen. The Home screen optimizes for the student who does not know what to do next. Flexibility (browsing, exploring, catching up on old material) is served by the other tabs.
Clarity over density. When in doubt, show less and disclose progressively. A screen that shows 4 things clearly is better than a screen that shows 12 things at once.
Standard platform patterns over custom ones. Every custom navigation or layout pattern requires explicit justification. The default is always iOS standard: tab bar, navigation bar, list, system text styles, semantic colors.
No dead ends. Every screen state -- including empty states (no submissions yet), error states (video playback failure), and transition states (semester not yet started) -- must offer the student a clear next action or orientation. A blank screen with an error message is never acceptable.

What This Phase Hands to Phase 3

Phase 3 (Navigation Architecture) will use the Tab Worthiness criteria from this document to evaluate and select the tab bar. It will use the 3 Questions Test to evaluate the Home screen structure. It will use the lifecycle tests to define the state model. Every navigation decision in Phase 3 must be testable against the Quality Bar above.

The organizing principle is locked: Weekly Rhythm. The quality bar is locked. Phase 3's job is to find the specific information architecture -- tabs, screen hierarchy, primary flows -- that satisfies both.