Version: 1.0
Date: 2026-03-17
Scope: Consolidating 6 pages (Create, Recipes, Carousel, Generations, Vault, Collections) into a coherent creation + library experience.
- What we do: AI content creation platform — generate images/videos from recipes, custom prompts, and carousels
- Who we serve: Semi-technical content creators building AI virtual influencers. Familiar with AI image generation concepts but not model nuances. Motivated by the dream of running an AI influencer business.
- Core task: Browse recipes → select → generate → see results
- Core promise: Recipe-based creation that's simpler than any competitor while producing quality output
- Safety constraint: Never make the user feel lost ("where do I go?") or waste their credits on something they didn't intend
- Activation funnel: Sign in → Create a model → Create content using a recipe (tracked in PostHog)
| Axis | Score (0–10) | Justification |
|---|---|---|
| Speed (10) vs. Learnability (0) | 2 | Optimizing for beginners and first-time experience. Semi-technical users who've used other tools but aren't deep. Manual control is a fallback, not the default path. |
| Error Prevention (0) vs. Flexibility (10) | 6 | Errors are cheap — bad output just means regenerate. Credits cost something but aren't catastrophic. Fallback to full manual control exists for power users. |
| Information Density (10) vs. Simplicity (0) | 3 | "Super simple" is a design goal. "Too confusing" is a top abandon reason. Recipe grid is visually dense but it's browsing, not data analysis. |
| Discoverability (0) vs. Efficiency (10) | 2 | First-time experience matters most. Users need to discover recipes exist and understand what they are. Business wants to push users toward recipes/carousels (higher margin, higher value). |
| Consistency (0) vs. Context-Optimization (10) | 4 | 6 different page layouts is part of the current problem. But creation and library are genuinely different tasks — some context-optimization is warranted. |
| Safety (0) vs. Flow (10) | 8 | "Too much friction" and "not enjoyable" are abandon reasons. Errors are cheap. Credits are the only real cost of mistakes. Minimize interruptions. |
This product leans heavily toward learnability, simplicity, discoverability, and flow. The interface should feel obvious on first use, guide users toward recipes, and get out of the way during creation. It should NOT optimize for expert speed, information density, or safety confirmations.
| Rank | Cost Currency | Tolerance | Rationale |
|---|---|---|---|
| 1 (unacceptable) | Learning | Must be productive on first session | If they can't figure it out, they leave. Competing tools exist. First-time activation funnel is the key metric. |
| 2 | Cognitive | ≤ 3 WM chunks during any creation step | Confusion = abandonment. "Too many screens" and "too confusing" are top concerns. |
| 3 | Time | Moderate | Users aren't time-pressured, but friction kills enjoyment. Flow matters more than raw speed. |
| 4 (acceptable) | Error | Regeneration is cheap | No destructive operations that matter. Credits are low-cost. Bad output → try again. |
These define the product. Every second of confusion, every unnecessary click, every moment of "where do I go?" is a product failure.
| Flow | Description | Performance Target |
|---|---|---|
| Recipe-based creation | Browse recipes → select → generate → see results | Competent on first attempt. < 4 WM chunks at any step. |
| First-time activation | Sign in → create model → first recipe generation | Complete without documentation. Zero "where do I go?" moments. |
Support the primary flow or serve less frequent needs. Heuristic evaluation, no learnability failures.
| Flow | Description |
|---|---|
| Carousel creation | Select mode → configure shots → generate multi-image set |
| Custom prompt creation | Write prompt → select model/params → generate |
| Browse past generations | Review previous outputs, download, manage |
Functional correctness. Inline help acceptable. Never sacrifice Tier 1 for these.
| Flow | Description |
|---|---|
| Collection management | Create/edit/delete collections, curate boards |
| Vault / asset management | Filter all assets by purpose, upload files |
| Failed run management | Retry or delete stuck/failed generation runs |
"We will not degrade recipe-based creation or first-time activation to improve library browsing, collection management, or custom prompt flexibility."
- Discoverability (2): Recipes should be prominent, visually browsable, obviously the main path → needs viewport space and visual weight
- Simplicity (3): Fewer things on screen, not confusing → fewer things competing for attention
Making recipes maximally prominent means they need space. Making the interface simple means less on screen. These pull against each other.
The user's working memory context during different phases is fundamentally different:
| Phase | WM Contents | Viewport Need |
|---|---|---|
| Selection | "What kind of content do I want?" — browsing, comparing options | Large (19+ recipe cards) |
| Creation | "My selected recipe + config" — generating, monitoring | Small (compose bar + filmstrip) |
| Review | "Comparing outputs, judging quality" — browsing history | Large (full output grid) |
Trying to support all three simultaneously creates WM interference — 4+ chunks from each task competing for the same 4-slot capacity (Cowan, 2001). This is why every single-page design felt cluttered. It's not a layout problem, it's a cognitive load problem.
The answer is sequential modes with smooth transitions, not simultaneous panels. Each mode gets full viewport for its task. Transitions between modes must be fast and contextual (not "navigate to a different page and lose your place").
| Page | Activity | Viewport Use |
|---|---|---|
| Recipes | Create (browse recipe cards + config sidebar + filmstrip) | Full — recipe grid |
| Carousel | Create (mode selector + form + preview sidebar) | Partial — lots of whitespace |
| Create | Create (output grid + compose bar) | Full — output grid |
| Generations | Library (output grid + history list) | Full — output grid |
| Vault | Library (all assets + purpose filter) | Full — asset grid |
| Collections | Library (collection boards + detail view) | Full — card grid |
Navigation decision cost: 6 sidebar items for creation + library
- RT = 200 + 150 × log₂(6 + 1) ≈ 621ms per navigation decision
- Reducing to 2 clear items: RT = 200 + 150 × log₂(3) ≈ 438ms (29% faster decisions)
- More importantly: 6 choices require understanding what each does. Learning cost (our #1 unacceptable cost) scales with the number of distinctions the user must internalize.
Confusion patterns:
- Recipes vs. Create: "Which one do I use to make something?"
- Generations vs. Vault: "What's the difference? Where are my images?"
- Collections vs. Vault: "Aren't these the same thing?"
- Creation pages (3) are the same fundamental action — "make something new" — split by method
- Library pages (3) are the same fundamental concern — "see stuff I have" — split by view
- Session outputs (what I just made) ≠ generation history (everything I've ever made). Only history competes with recipe browsing for viewport. Session outputs are a filmstrip.
Based on the axis positions, cost hierarchy, and flow tiers:
- Recipes are the landing experience. Discoverability (2) + Tier 1 flow + business priority = recipes must be the first thing users see when they go to create.
- Session outputs stay with creation. Flow (8) = don't make users leave the creation context to see what they just made. A filmstrip or inline section is sufficient.
- Sequential, not simultaneous. Simplicity (3) + WM limits = don't try to show recipe browsing and generation history at the same time.
- Two nav items, not six. Learnability (2) + "too confusing" feedback = minimize navigation decisions. The user should never wonder "which page do I go to?"
- No dense multi-panel layouts. Simplicity (3) + beginner optimization = no two-panel split views, no drawers with peeking content.
- No confirmation dialogs on generation. Flow (8) + cheap errors = just generate. If output is bad, regenerate.
- No hidden-by-default recipe browsing. Discoverability (2) = recipes can't be behind a popover, drawer, or collapsed section on first visit.
- What is the transition between "browsing recipes" and "seeing my results"? Options: page transition with back button, inline expansion, overlay, or the current filmstrip-at-bottom approach.
- Where do carousels live? They're small (3 cards) and could be a section within the recipe browser, or a tab, or a separate entry point.
- Should Library be one page with tabs (Generations / Collections / All Assets) or stay as separate pages? The charter says consolidate, but the implementation details matter.
- Can Vault be eliminated entirely? If Generations + Collections cover 95% of use cases, removing Vault simplifies navigation further.
| Metric | Target | Green | Yellow | Red |
|---|---|---|---|---|
| First-time recipe generation (activation) | Complete without help | > 80% complete | 60-80% | < 60% |
| Time to first generation (new user) | < 3 minutes from create page | < 3min | 3-5min | > 5min |
| Navigation confusion (support/feedback) | Zero "where do I go?" reports | 0 per month | 1-2 | 3+ |
| Recipe discovery rate | Users try 3+ recipes in first week | > 60% | 40-60% | < 40% |
| Page count (creation + library) | ≤ 3 total | 2 | 3 | 4+ |
| # | Decision | Axis | Rationale | What's Sacrificed | Reversal Condition |
|---|---|---|---|---|---|
| 1 | Optimize for beginners over power users | Speed vs. Learnability | First-time activation is the key metric; power users have API access | Expert efficiency on repeat tasks | If > 50% of revenue comes from power users who request faster workflows |
| 2 | Push recipes over custom prompt | Discoverability vs. Efficiency | Higher margins, better output quality, simpler for beginners | Custom prompt prominence and accessibility | If custom prompt generates > 40% of creations |
| 3 | Sequential modes over simultaneous panels | Simplicity vs. Density | WM limits make simultaneous display cognitively expensive for beginners | Ability to see history while browsing recipes | If users report frequent need to reference past outputs during recipe selection |
Charter produced using HCI cognitive engineering methods (GOMS, Hick-Hyman, WM capacity analysis). Quantitative predictions are relative comparisons at Medium confidence — absolute values require measured pixel distances and user testing.