Section 01
Product Brief
A practical delivery brief translated from the live stack specification. It turns the current product vision into execution guidance for product, design, and engineering kickoff.
Scope of this brief
This section is intentionally delivery-facing rather than aspirational. Where older summary copy conflicts with the later locked decisions in the stack spec, the locked decisions win: Ochre & Soul launches as a calm mobile colouring app with free starter artworks and paid content packs, not subscriptions.
1.1 — Business objective
- Launch a differentiated colouring product that celebrates Black culture through representation, editorial quality, and a calmer tone than generic free-to-play colouring apps.
- Prove that culturally specific content can convert from a free starter experience into one-off content-pack purchases without forcing sign-up or paywall friction before the user reaches value.
- Establish a thin-client product model where new artworks can be published remotely, downloaded on demand, and played offline once cached.
1.2 — Project profile
| Area | Delivery brief |
|---|---|
| Project profile | UI |
| Product type | Hybrid mobile app with a custom Flutter canvas, remote content delivery, and local-first offline play. |
| Platforms | iOS and Android. Tablet layouts are in scope, but not the launch priority. |
| Core interaction | Browse library → open artwork → download if needed → fill numbered regions on canvas → track progress → optionally purchase content packs. |
| Monetisation model | Free starter artworks plus one-off premium content packs only at launch. Subscription is explicitly post-MVP. |
| Primary UX constraint | The canvas is the product. Performance, accessibility, and calm presentation matter more than visual flourish. |
1.3 — User segments
| Segment | Need | Implication for delivery |
|---|---|---|
| Adults seeking calm creative downtime | A relaxing, polished colouring experience that feels culturally resonant rather than generic. | Onboarding must get to the first satisfying fill quickly, and the interface must stay elegant and non-game-like. |
| Parents and carers choosing content for children | Safe, positive, child-friendly depictions of Black life with low-friction offline use. | Child-mode defaults, family-safe purchase controls, and clear cultural review gates are launch requirements. |
| Children using the app directly or jointly | Simple guidance, accessible colouring interactions, and trustworthy content. | The first artwork must be playable anonymously, tooltips must be light, child-mode is set via the audience flag at onboarding (see /spec/09-user-flows/ §9.7), and behavioural analytics are restricted to app_opened and crash signals only when profiles.child_mode = true (see /spec/13-observability/ §13.3). Purchase gating relies on the platform’s OS-level parental controls for IAP; richer in-app parental controls and child profiles are explicitly out of MVP scope. |
| Users with colour-vision or other accessibility needs | A colouring experience that does not rely on colour discrimination alone. | Number visibility, pattern fills, screen-reader semantics, motion reduction, and forgiving tap behaviour are baseline product requirements. |
1.4 — Value proposition
- Cultural relevance: Ochre & Soul offers a library centred on Black culture, identity, families, hairstyles, textiles, traditions, and celebrations rather than treating representation as a token category. Every artwork passes through a named cultural reviewer before publication (see /spec/14-culture/ §14.2); the review process — not the subject list alone — is the differentiator competitors cannot copy quickly.
- Calm quality: The product should feel closer to a beautifully designed colouring book than to a noisy mobile game, with restrained motion and warm, confident copy. The handwritten founder’s note that appears at the first completion (or 50% milestone on long artworks) is treated as a launch deliverable, not a polish item — it is the highest-leverage trust moment in the app (see /spec/09-user-flows/ §9.7 #6).
- Low-friction value: Every install holds a persistent anonymous session from first launch (see /spec/07-data-layer/ §7.8). Users can browse, download free artworks, colour, and save local progress with no sign-up; signing in is only required to purchase a pack or to carry progress across devices. This materially shortens time-to-aha.
- Offline reliability: Once an artwork is downloaded, colouring must remain fully playable without a network connection.
- Accessible by design: Accessibility is built into the colouring engine itself, not deferred to a settings page or post-launch clean-up.
1.5 — Risks, dependencies, and success metrics
Key risks
- Canvas performance risk: The core delivery risk is whether the Flutter engine can hit the frame-time, memory, and tap-latency budgets on real mid-range devices.
- Content pipeline risk: The product depends on a repeatable artwork authoring, segmentation, validation, and cultural review workflow. Weak tooling here slows every release.
- Compliance risk: Child mode, parental gating, privacy constraints, and platform family policies affect analytics, purchases, and account design.
- Monetisation risk: Pack purchasing, restore flows, entitlement validation, and family-sharing support add platform-specific complexity early.
- Experience drift risk: If onboarding, paywall, or motion patterns drift toward generic mobile-game conventions, the product loses its positioning advantage.
Delivery dependencies
- Flutter app foundation and custom canvas implementation
- InsForge auth, storage, database, and function stack
- Apple App Store Server API and Google Play Developer API for receipt validation; Family Sharing-propagated entitlements honoured (see /spec/07-data-layer/ §7.5)
- Cloudflare CDN layer in front of artwork delivery
- Artwork production pipeline: authoring, segmentation, palette validation, bundle generation
- Cultural review workflow live, and the curated launch library — target ~25 artworks (see /spec/19-mvp/) — produced, reviewed, and ready to publish
- PostHog and Sentry instrumentation with child-mode policy enforcement
- Phase 0 proof of concept signed off against the three committed test fixtures — F-small (50 regions · 10 colours · 1024×1024), F-typical (500 regions · 16 colours · 2048×2048), F-stress (2 000 regions · 20 colours · 2048×2048) — before full production implementation. The fixtures and the measurement harness ship into the repo as Phase 0 deliverables and are reused as test fixtures per §15.2.
Success metrics
| Area | Metric | How to use it |
|---|---|---|
| Performance | Eight locked Phase 0 gates measured on a Pixel 6a (or equivalent mid-range Android), release build, Wi-Fi, 50% brightness: cold start to library ≤ 1.8 s; cached artwork open ≤ 600 ms (F-stress); steady-state frame time ≤ 16 ms p95 (F-stress, 60 s scripted pan/zoom); zero frame excursions > 50 ms over the same test; tap → fill latency ≤ 50 ms p95 (F-stress); tap accuracy ≥ 99% at 4× zoom (1 000 scripted taps); resident memory ≤ 220 MB (F-stress loaded + 5 min play); battery drain ≤ 6% per 30 min (F-typical play). | All eight rows must hit threshold on the same build — no partial pass. A failure on any row means the stack choice is revisited before Phase 1. See /spec/17-phases/ for the full table. |
| Activation | Time to first satisfying fill on the starter artwork. | Primary onboarding health signal; use it to judge whether the welcome and personalisation flow is too heavy. The conversion-lift figures cited in /spec/09-user-flows/ §9.7 (from a single 1,460-app onboarding study) are directional design heuristics, not committed conversion targets — do not treat them as a contract. |
| Engagement | Starter artwork completion rate, return to library after first canvas session, repeat opens of downloaded artworks. | Confirms whether the first-session experience is strong enough to create habit. |
| Monetisation | Paywall view → purchase start → purchase success for content packs. | Use to validate whether free value is converting into paid content demand without aggressive gating. |
| Reliability | Crash-free sessions and download completion rate are gated launch metrics. Sync failure rate is tracked via the sync_failed { reason } event (see /spec/13-observability/ §13.2) but is not gated at launch — set a threshold once we have baseline data. | Ensures the calm product promise is not undermined by operational failures. |
| Accessibility | Adoption and task completion for always-show-numbers, pattern fills, and reduce-motion configurations. | Checks whether the baseline accessibility features are both discoverable and effective. |
1.6 — UI / Hybrid kickoff fields
These fields are mandatory at kickoff for a UI / hybrid delivery. The brief below records what is already fixed by the current spec and what still needs explicit confirmation.
| Field | Current brief | Status |
|---|---|---|
| Platforms | iOS and Android. Tablet layouts are in scope but not the launch priority. | Specified |
| Accessibility baseline | Always-show-numbers on by default, optional pattern fills, high-contrast number halo, screen-reader semantics, reduce-motion support, Dynamic Type on non-canvas screens, and forgiving small-region tap handling. | Specified |
| Responsive requirements | Phone-first layout across onboarding, library, artwork detail, paywall, and settings. Tablet layouts are in scope but not a launch priority — they ship post-launch unless the rendering budget allows otherwise (see /spec/05-stack/ §5.1). Orientation and breakpoint rules still need explicit design confirmation. | Partially specified |
| Personalisation taxonomy | Cultural-themes multi-select with eight predefined values (textiles, carnival, portraits, family, children, symbols, traditions, landscapes); audience single-select (self / child / both); accessibility defaults (always-show-numbers on, reduce-motion inherits from OS, pattern-fills off). See /spec/09-user-flows/ §9.7. | Specified — should not be reopened at kickoff |
| Visual inspiration | Calm, polished, joyful, and restrained. The product should feel like a beautifully designed digital colouring book, not a free-to-play game. | Needs reference board |
| Reference apps | Happy Color is named as the interaction lineage in /spec/02-product/ §2.1. Additional reference apps for editorial tone, onboarding restraint, and purchase presentation still need to be named at kickoff. | Partially specified |