Architecture Prompt — v4
QuranFlow Information Architecture Redesign
Your Task
Design 3 distinct information architecture proposals for QuranFlow, an iOS app for learning to read the Quran. Each proposal should represent a different organizing principle—a different answer to "how do users think about this app?"
The Core Problem
Students are disoriented. They don't know what week they're on, what they should do today, or when live sessions happen.
This isn't a feature gap—it's an orientation failure. The current app hides critical information (schedule, coach, recordings) in a hamburger menu while surfacing less important things. Students email asking "when does semester start?" after receiving 5 emails about it.
Your proposals must make the app foolproof. A user who reads nothing should still understand what to do.
Reference Materials
Read these before designing:
| File | What to Extract |
|---|---|
QuranFlow-User-Capability-Map.md |
Section 1.4 (the disorientation problem), Section 7 (gap analysis), and all [Core] tagged tasks—these must be ≤2 taps |
Quran Flow Program Description.md |
The weekly rhythm: Lesson → Record → Submit → Feedback → Live sessions. Understand this cycle cold. |
App-Redesign-Field-Guide-WWDC25.md |
Design principles and the checklist. Use this as your quality bar. |
Usability Audit Nov 27.md |
Current broken structure (Section 10-11) and P0 issues to address |
Hard Constraints
- iOS tab bar: 5 tabs maximum, destinations only (no actions like "Record")
- Screen-level actions: Recording, submitting, etc. go in the top toolbar, not the tab bar
- [Core] tasks: Everything tagged [Core] in the capability map must be reachable in ≤2 taps
- Quranic text: Mushaf font by default (not hidden in settings)
- Timezone: All times in user's local timezone with clear indicator
What Each Proposal Must Include
Structure each proposal with these sections:
1. Concept (1 paragraph)
Explain the organizing principle. What mental model does this architecture assume? Why does this approach fit QuranFlow's users (busy adults, many older, don't read instructions)?
2. Navigation Structure
Tab Bar:
| Tab | Icon | Purpose |
|---|---|---|
| Name | 📍 | What this tab contains and why it deserves tab-level placement |
One Level Deep: For each tab, list what screens/sections live inside it. Show the hierarchy.
3. Key Screens (2-3 screens)
For each screen, describe:
- What the user sees — The key information displayed
- What orientation it provides — How it answers "where am I?" and "what should I do?"
- What actions are available — What can the user do from here?
Focus on:
- The home/landing screen (most important)
- One other screen critical to this architecture's organizing principle
- Optionally, one screen that shows how a previously-hidden feature becomes accessible
4. Critical User Flows (2-3 flows)
Walk through how a user accomplishes these tasks:
- Submit their weekly recording (the core task)
- Find and join a live session (currently broken)
- Check their feedback (currently scattered)
For each flow:
- List the steps (tap path)
- Explain why this flow makes sense given your organizing principle
- Count the taps for the critical path
5. Surfacing Strategy
Show how currently-hidden information becomes findable:
| Hidden Info | Current Location | New Location | Taps to Reach |
|---|---|---|---|
| Quran Coach name | Hamburger menu | ? | ? |
| Session schedule | Resources → external link | ? | ? |
| Past recordings | Hamburger → Recordings | ? | ? |
| Font settings | Hamburger → Settings | ? | ? |
| Support | Hamburger → Support | ? | ? |
6. Trade-offs (1 paragraph)
- Optimizes for: What does this architecture make easy?
- Sacrifices: What becomes harder or less prominent?
- Best for: Which user type benefits most from this approach?
- Risk: What could go wrong with this approach?
What Makes Proposals "Distinct"
Three variations on the same structure is not what we want. Each proposal should have:
- A different tab bar (not just renamed tabs—different groupings)
- A different home screen focus (what's the first thing the user sees?)
- A different primary flow for the same task
Ask yourself: "If I showed someone just the tab bars, could they tell these apart?" If not, they're not distinct enough.
Output Format
# Proposal A: [Name]
## Concept
[1 paragraph]
## Navigation Structure
[Tab bar table + hierarchy]
## Key Screens
### [Screen Name]
[Description]
### [Screen Name]
[Description]
## Critical Flows
### Submit Weekly Recording
[Step-by-step with reasoning]
### Find Live Session
[Step-by-step with reasoning]
## Surfacing Strategy
[Table showing where hidden info now lives]
## Trade-offs
[1 paragraph]
---
# Proposal B: [Name]
[Same structure]
---
# Proposal C: [Name]
[Same structure]
---
# Comparison Summary
| Aspect | Proposal A | Proposal B | Proposal C |
|--------|------------|------------|------------|
| Organizing principle | | | |
| Home screen focus | | | |
| Taps to submit recording | | | |
| Taps to find schedule | | | |
| Best for user who... | | | |
Quality Checklist
Before finalizing, verify each proposal:
- Home screen immediately answers: Where am I in the program? What should I do now?
- Tab bar contains only destinations (actions are in toolbars)
- All [Core] tasks from capability map are ≤2 taps
- Previously hidden features (coach, schedule, recordings, support) are now findable
- Passes the "squint test"—clear information hierarchy
- Works for Week 1 student AND Week 14 student
- Doesn't require reading a manual to understand