Pattern-driven Development C

A pattern language for visual storytelling (Alexander-inspired)

Use patterns as building blocks. For each feature, choose the smallest pattern that fits, implement it, playtest, then proceed to the next. Keep patterns independent, composable, and named.

Generative sequence (end-to-end)

  1. Story Core → pick “Story Spine” and target audience.
  2. Scene List → outline scenes/pages; choose “Scene as Place”.
  3. Interaction Verbs → tap/drag/scroll; pick “Clear Affordances”.
  4. Page Structure → decide layout using “Page Grid”.
  5. Asset Budget → define targets with “Asset Budget”.
  6. First Vertical Slice → one scene from PSD → Kwik → Simulator.
  7. Feedback Loop → add “Immediate Feedback” and “Tempo & Rhythm”.
  8. Reuse → extract “Reusable Components” (symbols/shared assets).
  9. Telemetry → add “Telemetry Hooks” for events and funnels.
  10. Optimization → apply “Asset Budget” rules (PNG→JPEG, shared atlases).
  11. Packaging → “Soft Launch” build.settings, icons, splash.
  12. Iteration → observe analytics, refine patterns, then scale.

Pattern cards (starter set)

Story Spine

  • Forces: Clarity vs. feature creep.
  • Solution: One-sentence arc (setup → conflict → resolution) that gates scope for each scene.
  • Consequences: Easier pruning, consistent tone.
  • Applies: Phase I (authoring), planning.

Scene as Place

  • Forces: Scenes must feel spatial and coherent across devices.
  • Solution: Treat each page/level as a “place” with entry, core action, exit.
  • Consequences: Clear navigation; measurable completion.
  • Applies: Phase II (implementation).

Page Grid

  • Forces: Layout must adapt to multiple aspect ratios.
  • Solution: Define a fixed grid (e.g., 8pt) and safe zones; anchor key elements to grid.
  • Consequences: Fewer layout bugs; consistent rhythm.
  • Applies: Phase I (assets), Phase II (layout).

Clear Affordances

  • Forces: Discoverability vs. visual noise.
  • Solution: Standardize interactive states (idle/hover/pressed/disabled) and hit areas.
  • Consequences: Faster onboarding; fewer mis-taps.
  • Applies: Phase II (Kwik interactions).

Immediate Feedback

  • Forces: Engagement vs. overload.
  • Solution: Micro SFX/haptics/particle hints within 100–200 ms of user input.
  • Consequences: Perceived responsiveness.
  • Applies: Phase II (polish).

Tempo & Rhythm

  • Forces: Pacing vs. content density.
  • Solution: Alternate calm and peak beats; time transitions (250–700 ms) consistently.
  • Consequences: Better retention; reduced fatigue.
  • Applies: Phase II (animation timing).

Reusable Components

  • Forces: Speed vs. duplication.
  • Solution: Extract commonly used UI/FX into shared symbols/assets; version them.
  • Consequences: Smaller builds; faster changes.
  • Applies: Phase I (assets), Phase II (orchestration).

Asset Budget

  • Forces: Quality vs. size/perf.
  • Solution: Define budgets (e.g., max texture size, per-scene memory, audio bitrate).
  • Consequences: Predictable performance; easier optimization.
  • Applies: Phase I (prep), Phase II (optimization).

Telemetry Hooks

  • Forces: Insight vs. privacy/noise.
  • Solution: Log scene enter/exit, key interactions, errors; sample rates; opt-in text.
  • Consequences: Actionable analytics; minimal overhead.
  • Applies: Phase II (analytics), Phase III (release).

Soft Launch

  • Forces: Certainty vs. time-to-market.
  • Solution: Limited geos/testflight; A/B creatives; crash/retention review before global.
  • Consequences: Lower risk; data-informed polish.
  • Applies: Phase III (deployment, store).

How it maps to your phases

  • Phase I: Story Spine, Page Grid, Asset Budget, Reusable Components.
  • Phase II: Scene as Place, Clear Affordances, Immediate Feedback, Tempo & Rhythm, Telemetry Hooks.
  • Phase III: Soft Launch (+ build.settings, icons, splash, bookshelf).

Pattern card template

  • Name
  • Context/Forces
  • Solution (1–3 sentences)
  • Consequences/Trade-offs
  • Applies (Phase I/II/III), Links (docs, files)