v6 Brainstorm
QuranFlow Architecture Prompt v6 — Brainstorm
What We're Building
A v6 architecture design prompt that produces a single, implementation-ready architecture specification for the QuranFlow iOS app redesign. Unlike v5 (which generated 3 conceptual proposals), v6 generates one deep, actionable architecture that can be directly used to build mockups.
Why This Approach
What changed since v5
- v5 produced 3 proposals → We selected Proposal A (Weekly Rhythm)
- Proposal A was implemented as a React/shadcn mockup (qf-design-a)
- A design review assessed the mockup at ~80% alignment, 57% capability coverage
- A second visual exploration (qf-design-b) was created with different aesthetics
- We now have real implementation data about what works and what doesn't
Key insight
v5 was "explore the space." v6 is "go deep on the right answer, informed by everything we've learned."
Key Decisions
- Single proposal, not 3: We've already explored the space. Now go deep.
- Organizing principle constrained: Weekly Rhythm. Not re-debated.
- Fresh architecture, informed by A: The AI reads everything (including Proposal A + its design review) but designs from scratch. Proposal A is evidence, not a template.
- Re-derive with fresh eyes: The AI reads source documents and produces its own synthesis (doesn't take our existing analysis as gospel).
- Implementation-ready output: Detailed written descriptions of screens, states, behaviors. No ASCII wireframes.
- Full lifecycle scope: Pre-semester → onboarding → weekly cycle → end of semester → graduation.
- Architecture only: No visual design direction (colors, fonts, spacing). That's a separate workstream.
- Design decisions resolved organically: Not a separate "decisions" section — the architecture itself embodies the decisions.
- Runs in Claude Code: Can reference files by path.
Prompt Structure (Phases)
Preamble
- Role: iOS product designer
- Constraint: Weekly Rhythm organizing principle
- Goal: Implementation-ready architecture spec
- Format: Single deep proposal
Phase 1: Problem Synthesis
- Read: Capability Map, PM Discussion, Usability Audit, Program Descriptions
- Produce: Problem brief, task inventory, hidden features table
Phase 2: Design Principles Diagnosis
- Read: WWDC25 Field Guide
- Produce: Quality bar, diagnostic framework to validate against
Phase 3: Learn from Previous Attempt (NEW)
- Read: Architecture Proposals (all 3, focus on A), Design Review of Exploration A
- Produce: What worked, what didn't, open questions, elements from B/C worth incorporating
Phase 4: Design the Architecture
- 9 sections: Concept, Navigation, Screens, Flows, Surfacing, States, Edge Cases, Onboarding, End-of-Semester
- Detailed written descriptions (not wireframes)
- Full lifecycle coverage
Phase 5: Validation
- [Core] task coverage check
- WWDC25 validation tests
- P0 issue resolution
- Tap count verification
Open Questions (for the output to resolve)
- Tab structure: Submit standalone vs. unified into Learn vs. something else
- What dominates the Today page
- How to handle "you're behind" state
- Where feedback history lives (its own tab? inside Learn? Progress tab?)
- Onboarding flow specifics
- Pre-semester experience design
- End-of-semester/graduation flow
Next Steps
→ Draft the v6 prompt as a markdown file in reviews/prompts/ → Review and refine the prompt → Execute it in Claude Code to produce the architecture document