Architecture Prompt — v5
QuranFlow Architecture Design Process
What This Document Is
This is a guided design process for producing information architecture proposals for QuranFlow. It walks through analysis stages that build on each other, culminating in 3 distinct architecture proposals with clear rationale.
Don't skip stages. Each one produces insights the next stage needs.
Design Philosophy
Before any analysis, establish the frame.
What Success Looks Like
A successful QuranFlow architecture means:
- Week 1 student: Opens app for first time → immediately understands what to do and when the semester starts
- Week 8 student: Opens app → sees "Week 8 of 15" and their current status (lesson watched? submission pending? feedback ready?) without scrolling
- Catch-up student: Missed a week → can quickly find what they missed and what's due
- Confused student: Something's wrong → finds help in ≤2 taps
The ultimate test: No one should ever need to email asking "when does semester start?" or "what week am I on?" The app answers this instantly.
The Core Trade-off
QuranFlow serves two competing user needs:
| Need | Description | Optimizing For |
|---|---|---|
| Guidance | Tell me exactly what to do next | Reduces anxiety, increases completion, helps beginners |
| Flexibility | Let me explore, catch up, browse freely | Supports varied schedules, empowers advanced users |
Every architecture leans one way or the other. Acknowledge this tension explicitly.
Key Architectural Decisions
These are the choices that define an architecture. Each proposal must take a clear stance:
What earns a spot on the tab bar? The skeleton. Wrong choices here can't be fixed with good screens.
What dominates the home screen? The first impression. Does the user see their current week? A dashboard? A task list? A timeline?
Are submissions and feedback unified or separate? Currently split across locations. What's the relationship?
Where does the schedule live? Currently buried. How prominent should it be?
How does the app handle "you're behind"? Guilt-inducing? Encouraging? Hidden?
How We Validate
An architecture works if it passes these tests:
- Orientation test: New user can state what week it is and what they should do within 10 seconds
- First task test: New user can complete first submission without external help
- Return test: Returning user sees current status without scrolling
- Recovery test: Confused user finds support in ≤2 taps
- Tab bar test: Every tab is a destination, no actions
- 3 Questions test: Home screen answers Where am I? What can I do? Where can I go?
Reference Materials
| Document | Read For | Extract |
|---|---|---|
| User Capability Map | Task inventory, priority tags, gap analysis | List of [Core] tasks, hidden features table, disorientation manifestations |
| Program Description | The weekly rhythm, student journey | The cycle: Lesson → Record → Submit → Feedback → Live. The 15-week structure. |
| Usability Audit | Current state problems, severity ratings | P0 issues, current screen inventory, what's broken |
| WWDC25 Field Guide | Design principles, diagnostic tests | The 3 questions, tab worthiness test, squint test |
Phase 1: Synthesize the Problem
Goal: Produce a clear problem statement and requirements summary.
Tasks
- Read the User Capability Map Section 1.4 ("The Primary Problem")
- Read the Usability Audit Executive Summary
- Synthesize into a problem brief
Output: Problem Brief
Write 1 page covering:
The Disorientation Problem (2-3 sentences)
- What's the core failure?
- How does it manifest?
The Weekly Rhythm (bullet list)
- What happens each week?
- What's the critical path a student must complete?
Task Inventory
| Priority | Task | Current State |
|---|---|---|
| [Core] | Know what week I'm on | Not shown |
| [Core] | Access this week's lesson | Works, but no context |
| ... | ... | ... |
Hidden Features Table
| Feature | Current Location | Why It's Hidden |
|---|---|---|
| Quran Coach | Hamburger menu | User wouldn't think to look |
| Schedule | Resources → external link | 5 clicks deep |
| ... | ... | ... |
Phase 2: Diagnose the Current State
Goal: Apply the Field Guide diagnostic tests to understand why the current architecture fails.
Tasks
- Open the Field Guide "Diagnostic Test" section
- Apply each test to QuranFlow's current home screen
- Audit the current tab bar for "tab worthiness"
Output: Diagnostic Report
The 3 Questions Test (Current Home Screen)
| Question | Should Answer | Current Answer | Verdict |
|---|---|---|---|
| Where am I? | Week X of 15, Level Y | "Your Upcoming Home" (meaningless) | ❌ Fail |
| What can I do? | Watch lesson, submit recording, join session | Unclear - multiple competing elements | ❌ Fail |
| Where can I go? | Clear navigation to other sections | Top tabs exist but hamburger hides critical items | ⚠️ Partial |
Tab Worthiness Audit (Current: Home | Lessons | Submissions | Live)
| Current Tab | Is it a destination? | Is it an action? | Is it a subset? | Verdict |
|---|---|---|---|---|
| Home | Yes | No | No | ✓ Keep |
| Lessons | Yes | No | No | ✓ Keep |
| Submissions | Yes | No | Could merge with Lessons? | ? Evaluate |
| Live | Yes | No | No | ✓ But broken |
Hamburger Menu Audit List everything in the hamburger and ask: should this be hidden?
| Item | Should Be Hidden? | Why/Why Not |
|---|---|---|
| Student level | No | Critical orientation info |
| Quran Coach | No | Users need to know who their teacher is |
| Recordings | No | Important for catch-up |
| ... | ... | ... |
Phase 3: Explore Organizing Principles
Goal: Generate possible mental models before committing to architectures.
The Question
How might users think about this app? Each mental model suggests a different architecture.
Tasks
- Brainstorm 5-6 possible organizing principles
- For each, identify what it optimizes and what it sacrifices
- Select 3 that are meaningfully different
Output: Organizing Principles Exploration
| Principle | Mental Model | Optimizes For | Sacrifices |
|---|---|---|---|
| Time-First | "The app is a calendar/timeline of my semester" | Temporal orientation, planning | Quick task completion |
| Task-First | "The app is a to-do list of what I need to do" | Action clarity, completion | Exploration, context |
| Progress-First | "The app shows how far I've come and what's left" | Motivation, big picture | Immediate next steps |
| Content-First | "The app is a library of learning materials" | Browsing, exploration | Guidance, urgency |
| Coach-First | "The app connects me to my teacher" | Relationship, feedback | Self-directed learning |
| Rhythm-First | "The app follows the weekly cycle" | Routine, habit | Flexibility, catch-up |
Selected Principles for Development:
- [Principle A] — because...
- [Principle B] — because...
- [Principle C] — because...
Explain why these 3 were selected and why the others were set aside.
Phase 4: Develop Architectures
Goal: For each selected principle, build out a complete architecture.
For Each Proposal, Develop:
4.1 Concept Statement (1 paragraph)
- What's the organizing principle in plain language?
- Why does this fit QuranFlow's users?
- What's the "elevator pitch" for this approach?
4.2 Tab Bar Design
| Tab | Icon | Contains | Why Tab-Worthy |
|---|---|---|---|
| Name | Symbol | What lives here | Justification |
For each tab, explain:
- What screens/sections live inside
- The hierarchy (one level deep minimum)
- Why this grouping makes sense given the organizing principle
4.3 Home Screen Design
Describe in detail:
What the user sees:
- Primary orientation element (what's the first thing they read?)
- Current status indicators
- Next action prompt
- Upcoming events/deadlines
How it answers the 3 questions:
- Where am I? → [specific answer]
- What can I do? → [specific answer]
- Where can I go? → [specific answer]
What actions are available:
- Primary action (most prominent)
- Secondary actions
- Navigation affordances
4.4 Critical Screens (2-3 additional screens)
For each screen:
- What is it for?
- What does the user see?
- What can they do?
- How does it connect to other screens?
Focus on screens that are:
- Central to this architecture's organizing principle
- Solving a currently-broken experience
- Demonstrating how hidden info surfaces
4.5 User Flows
Walk through these scenarios step-by-step:
Flow A: First-time student orientation
- Student opens app for first time after placement
- What do they see?
- What do they do?
- How do they learn what the app is for?
Flow B: Submit weekly recording
- Student wants to submit this week's recording
- Starting point: wherever they naturally land
- End point: submission confirmed
- Count the taps
Flow C: Find and join a live session
- Student wants to attend today's QRC
- How do they find it?
- How do they know the time in their timezone?
- How do they join?
Flow D: Check feedback and ask follow-up
- Student received notification about feedback
- How do they find it?
- How do they respond?
For each flow, explain why this flow makes sense given the organizing principle.
4.6 Surfacing Strategy
| Currently Hidden | New Location | Taps to Reach | How User Discovers It |
|---|---|---|---|
| Quran Coach | ? | ? | ? |
| Schedule | ? | ? | ? |
| Recordings | ? | ? | ? |
| Font settings | ? | ? | ? |
| Support | ? | ? | ? |
4.7 Trade-off Analysis
This architecture optimizes for: [What becomes easy/clear/prominent]
This architecture sacrifices: [What becomes harder/hidden/de-emphasized]
Best for users who: [User type/behavior that benefits most]
Risk: [What could go wrong, what assumption might be wrong]
Key decision points: [The 2-3 choices that define this architecture and could be challenged]
Phase 5: Evaluate and Compare
Goal: Test each architecture against success criteria and produce a recommendation.
Tasks
- Run each proposal through the validation checklist
- Produce a comparison matrix
- Articulate a recommendation (or present as options with trade-offs)
Output: Evaluation
Validation Checklist Results
| Test | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Orientation test | ✓/✗ | ✓/✗ | ✓/✗ |
| First task test | ✓/✗ | ✓/✗ | ✓/✗ |
| Return test | ✓/✗ | ✓/✗ | ✓/✗ |
| Recovery test | ✓/✗ | ✓/✗ | ✓/✗ |
| Tab bar test | ✓/✗ | ✓/✗ | ✓/✗ |
| 3 Questions test | ✓/✗ | ✓/✗ | ✓/✗ |
Comparison Matrix
| Dimension | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Organizing principle | |||
| Tab bar | |||
| Home screen focus | |||
| Taps: submit recording | |||
| Taps: find schedule | |||
| Taps: get support | |||
| Strongest advantage | |||
| Biggest weakness | |||
| Best for |
Recommendation
Either:
- "Proposal X is recommended because..." with clear rationale
- Or: "These represent genuine alternatives with different trade-offs. Choose based on whether you prioritize [A's strength] vs [B's strength] vs [C's strength]"
Final Deliverable Structure
The complete output should be organized as:
# QuranFlow Architecture Proposals
## Executive Summary
[1 page: problem, approach, 3 proposals at a glance, recommendation]
## Problem Brief
[Output from Phase 1]
## Current State Diagnosis
[Output from Phase 2]
## Organizing Principles Explored
[Output from Phase 3]
## Proposal A: [Name]
[Full output from Phase 4]
## Proposal B: [Name]
[Full output from Phase 4]
## Proposal C: [Name]
[Full output from Phase 4]
## Evaluation and Comparison
[Output from Phase 5]
## Appendix: Reference Material Synthesis
[Key extracts from source documents]
Process Checklist
- Phase 1 complete: Problem brief written
- Phase 2 complete: Diagnostic tests applied
- Phase 3 complete: Organizing principles explored, 3 selected
- Phase 4 complete: All 3 proposals fully developed
- Phase 5 complete: Evaluation and comparison done
- Design philosophy referenced throughout
- All [Core] tasks addressed in every proposal
- All hidden features have a home in every proposal
- Trade-offs honestly articulated