Raxx Closed-Beta Walkthrough — Narrative Arc + Survey Hypothesis Validation

Date: 2026-06-11 | Author: marketing-strategist | Status: v1

Purpose

This doc gives the ux-designer locked headline + body copy for each walkthrough screen, gives feature-dev the measurable hypotheses the survey must test, locks the voice + tone rules, and records BLR sync status.

It is upstream of: - ux-designer's 4-screen build - feature-dev's rubric-survey wiring - BLR's best-practices review (parallel; see Section 4)

1. The 4-Screen Narrative Arc

The arc is a single through-line: the tester starts with their own frustration, sees Raxx name it, watches Raxx enforce a structure they already recognize, and ends with a clear question about value. It is not a product tour. It is not a demo. It is a confirmation that a problem they already have is solvable.

Tester arrival state: hand-selected, trading-competent, mildly skeptical. They are not beginners. The arc respects that.

Screen 1 — Welcome

Headline (lock): The rules you wrote. Enforced before emotion gets a vote.

Body (2 sentences the tester reads and understands by end of this screen): You already know what your trade should do — entry, credit target, exit point. Raxx holds that plan in place while a position is open, so the decision you made before you had P&L anxiety is the decision that counts.

What value is demonstrated: The tester understands in 30 seconds that Raxx is not a new platform to learn — it is enforcement of the structure they already wrote. Specifically: their entry condition and exit rule are the inputs; Raxx is the thing that doesn't let them override those inputs at 2pm on expiry Friday.

CTA copy: See how it works — 15 minutes

What this screen leaves out: - Any mention of AI, machine learning, or "smart" features - Broker names - Pricing or tier information - Paper trading mechanics (save for Screen 2) - Tax tools, backtest, or any secondary feature - Platform comparison language ("better than X")

Screen 2 — Structure Enforcement (Dashboard + Strategies)

Headline (lock): Your strategy, your rules. Set once. Held every time.

Body (2 sentences): This is what a live strategy looks like in Raxx: the entry rule, the exit rule, and the stop-loss are on the record before the trade opens. When the position is open, the rules are visible — not in a spreadsheet you have to go find.

What value is demonstrated: The tester sees the specific mechanism: entry rule (30 DTE, delta 0.30, IV rank >40), exit rule (50% profit or 21 DTE), stop-loss (2x credit received). These are not hypothetical feature descriptions — they are the actual fields in the strategy card. The tester can map what they see directly to a trade they have run before. The insight is: "I have these rules, I just don't have them held anywhere enforced."

CTA copy: Look at the backtest view next

What this screen leaves out: - How strategies are created (that is onboarding, not this walkthrough) - Multi-leg structure builder details - Anything requiring a funded account - Shape / sentiment features (separate section later) - Any implication that Raxx chose these rules for the user

Screen 3 — Paper + Backtest (then Tax Tools)

Headline (lock): What this structure did before you risked a dollar.

Body (2 sentences): Before anything goes live, Raxx runs the structure against real historical data so you can see what it returned, where it failed, and whether it fits your risk tolerance. That record is yours — closed positions, wash-sale flags, and P&L by structure — not just what the platform tracks by regulation.

What value is demonstrated: Two concrete, specific things the tester sees: 1. Backtest: the structure they just defined in Screen 2 has a historical result — a win rate and a max-loss scenario — before it is ever run with capital. 2. Tax tools: closed positions tagged with short-term / long-term / wash-sale badges. The wash-sale flag is specific enough that a tester who has been burned by one will feel the value without needing it explained.

These are shown as a unit because together they represent the retrospective record. Raxx does not predict what will happen; it shows what happened and flags what the rules require.

CTA copy: One last feature, then the survey

What this screen leaves out: - Any forward-looking performance claim ("this structure will return X") - Promotion to live trading (not yet established; paper-first is the gate) - Pricing or tier-gating details for retention periods - Shape / sentiment features (save for a future cohort if v2) - Integration details (which brokers connect, how fills route)

Screen 4 — The Ask (Survey)

Headline (lock): Honest question: does this solve a problem you actually have?

Body (2 sentences): You have seen the structure enforcement, the backtest, and the tax record. Now we want to know what you think — not whether you liked the interface, but whether Raxx addresses something you have tried and failed to solve on your own.

What value is demonstrated: The tester is not being pitched at in Screen 4. The headline reframes the survey from "rate our product" to "confirm or deny a hypothesis." This is respectful of their competence and honest about what we are trying to learn. The founder note on this screen (Kristerpher's voice) makes it personal: this is a builder asking someone they trust.

CTA copy: Submit my answers

What this screen leaves out: - Product roadmap or future promises - Pricing pressure ("lock in the Founders price now") - NDA framing or legal friction at this moment (already handled at entry per BLR guidance) - Any implication that their answers are being used for anything other than building a better product for traders like them

2. Survey Hypothesis Validation

The rubric has 11 scored items plus free-text and task check. Below are the 5 hypotheses the survey should actually test. Items that do not map to a hypothesis are flagged for removal or demotion.

H1 — Structure enforcement is understood as a distinct category

Hypothesis: Testers who complete the walkthrough understand "structure enforcement" as something different from journaling, from a spreadsheet, and from a trade alert. They can describe it in their own words as rules-held-before-emotion.

Measurable from: C2 (can explain in one sentence) + D1 (differentiated from existing tools) + D2 (free-text: "how is Raxx different from a trade journal?")

Disconfirmation: C2 mean < 3.5 OR D2 free-text responses cluster around journal/alert framing rather than enforcement/rule framing. Specifically: if testers use words like "tracks," "logs," or "reminds" rather than "holds," "enforces," or "locks in," H1 fails.

Actionable if fails: Screen 2 copy (Strategy rules card) is not making the enforcement mechanism concrete enough. Fix: add a single line to the screen 2 walkthrough that explicitly names the enforcement moment — "when the position is open, these rules cannot be silently overridden."

H2 — Structure-gap resonance is high for this cohort

Hypothesis: The operator-curated testers have the specific problem Raxx solves — they already have rules they break emotionally. R1 should be high for this group because they were selected on exactly this criterion.

Measurable from: R1 (structure gap describes my experience) and the pre-survey Q3 (biggest frustration) verbatim.

Disconfirmation: R1 mean < 3.5 for the cohort, or Q3 verbatim answers that describe skill gaps ("I don't know what to trade") rather than structure gaps ("I know what to trade but I keep breaking my rules").

Actionable if fails: Either the tester selection criteria were too loose (operator action: tighten cohort definition) OR the walkthrough is obscuring the structure thesis behind feature descriptions (marketing action: rewrite Screen 1 to lead with the structure-gap problem statement, not the solution).

H3 — Founders $29 pricing hits the right anchor

Hypothesis: At least 70% of testers answer P1 as Yes or Maybe. The Founders price is not being perceived as too low (commodity/cheap signal) or too high (barrier to entry).

Measurable from: P1 (would you pay $29 today) + P2 (would you pay monthly after the Founders period) read together.

Disconfirmation: P1 Yes < 50%, or high P1 Yes with P2 No (indicates the Founders price works but the long-term subscription value proposition doesn't land). The P1/P2 split is more informative than either alone.

Actionable if fails: P1 No clusters: Screen 3 (backtest + tax tools) is not demonstrating enough concrete value for the price to feel justified. Fix: tighten the backtest demo to show a specific dollar outcome — a real structure, a real historical result — rather than the form UI. P2 No clusters: the ongoing value proposition (monthly access to enforcement + paper ledger) isn't established by the walkthrough. File a card to add a retention hook to Screen 4 copy.

H4 — The walkthrough is clear enough to not require facilitation

Hypothesis: Testers complete the walkthrough without needing to ask what a feature does. O1 mean >= 4.0 (clear throughout) and task-check pass rate >= 80% on wash-sale detection.

Measurable from: O1 (walkthrough clarity Likert) + O2 (most confusing part) + the wash-sale detection task pass/fail.

Disconfirmation: O1 mean < 3.5 OR O2 verbatim clusters around the same feature (e.g., multiple testers cite "backtest" as confusing) OR wash-sale task pass < 60%.

Actionable if fails: O2 verbatim clustering is the most specific signal. If "backtest" is the cluster, the Screen 3 explanation is insufficient — rewrite. If "strategy rules" is the cluster, Screen 2 needs a one-line annotation. The task check is a navigation test: if wash-sale fails at > 40%, the information architecture is burying a critical feature.

H5 — Testers can name a specific person they'd refer

Hypothesis: The binary PR1 question ("is there a specific person in your trading circle?") will be Yes for > 60% of testers. Referability at this stage is stronger than NPS as a signal: it requires the tester to have understood the product well enough to map it to someone else's situation.

Measurable from: PR1 (would refer to someone specific).

Disconfirmation: PR1 Yes < 50%. NPS may still be high even if PR1 is low — that combination means testers like Raxx but do not yet understand it well enough to know who else needs it.

Actionable if fails: If NPS is high but PR1 is low, the walkthrough is creating delight but not clarity. The product story is not landing as a specific use case — it is landing as "this is cool." Fix is to sharpen C2 copy so the product thesis is one specific sentence testers can repeat.

Question audit — current rubric items

New question proposed to close a gap:

No current question directly tests whether the tester's pre-walkthrough frustration (Q3) matched what Raxx addresses. The rubric has Q3 (verbatim frustration) and R1 (resonance Likert) but no explicit "did Raxx address the frustration you described?" question.

Proposed addition — R3: "Looking back at the frustration you described before the walkthrough — does Raxx address it?" (one-tap: Yes / Partially / No)

This creates a closing loop on Q3. It is fast to answer, clearly mappable to H2, and produces a direct before/after signal. Weight: 10 points (Yes=10, Partially=5, No=0).

If R3 is added, update the scoring table: max achievable rises to 115; normalize by 1.15.

3. Voice + Tone Calibration

What Raxx sounds like

The walkthrough copy operates at the level of a peer who has traded seriously and built a tool they would use themselves. It is not a pitch. It is not a tutorial. It is an honest conversation between two people who understand the problem.

The voice is: calm, specific, founder-driven, structure-first. It acknowledges the user's competence. It does not explain things they already know.

5 lines that nail it

1. "The rules you wrote deserve more than a spreadsheet." — Acknowledges existing practice; positions Raxx as a natural upgrade, not a replacement.

2. "Your exit rule runs at 50% profit or 21 DTE. Raxx holds that. The position does not override it." — Specific. Concrete. Describes the mechanism without pitching a feature.

3. "Before anything goes live, you see what this structure did. Not a projection — the actual recorded result." — Retrospective framing locked. Contrast with "projection" sets honest expectations.

4. "You set the entry condition. You set the stop-loss. Raxx is the thing that does not forget them when the trade goes against you." — Emotion is named precisely: forgetting a rule when stressed. Not "managing emotions."

5. "Wash-sale flags surface automatically. They do not wait for you to remember to check." — Specific feature, specific benefit. The word "automatically" earns its place here because the alternative (manual memory) is exactly what it replaces.

3 wrong-voice lines (anti-patterns for ux-designer + dev)

1. WRONG: "Raxx uses AI to help you make smarter trading decisions." — Violates feedback_deterministic_execution_ai_augments. No AI hype. No "smarter." No "decisions" framed as platform-originated.

2. WRONG: "Take your trading to the next level with Raxx's powerful analytics platform." — Generic fintech marketing voice. "Next level" is meaningless. "Powerful" is a filler adjective. "Analytics platform" misnames what Raxx is.

3. WRONG: "Connect your [broker name] account and start trading in minutes." — Violates feedback_no_backend_branding. No broker names in tester-facing copy. Also: "start trading" frames Raxx as a trading platform, not a structure layer.

4. BLR Sync Notes

BLR's best-practices doc at docs/marketing/2026-06-11-beta-walkthrough-best-practices.md was not present at time of this dispatch (2026-06-11). This section is a placeholder.

When BLR's doc lands, reconcile the following specific items:

1. Screen 3 body copy — "what it returned, where it failed, and whether it fits your risk tolerance." Confirm BLR is comfortable with "what it returned" as retrospective copy, not a return claim. The phrase is descriptive of a historical backtest on user- supplied data, not a performance guarantee.

2. H3 hypothesis copy — "Founders $29 pricing hits the right anchor." Confirm BLR is comfortable with the walkthrough showing pricing to testers. No purchase is occurring; this is price-point exposure only.

3. Proposed R3 question — "does Raxx address the frustration you described?" Confirm BLR is comfortable with this as a survey instrument question, not a testimonial solicitation that could be construed as investment endorsement.

4. Review BLR's "Raxx 10/10 recipe" paragraph for any framing that conflicts with feedback_no_forward_looking_framing or feedback_deterministic_execution_ai_augments. If BLR introduces "improves," "optimizes," or predictive language, flag for removal before the walkthrough copy is locked.

If BLR's doc confirms no conflicts with the above: mark this section resolved in a follow-up commit and update the PR description to note BLR sync complete.

Downstream handoffs

ux-designer: Headlines + body copy in Section 1 are locked. CTAs are verbatim. The "What this screen leaves out" list is a constraint, not a suggestion — if a feature appears on screen that is not in the value demonstrated section, the screen is off-arc.

feature-dev: The 5 hypotheses in Section 2 define what the survey must produce data on. Each hypothesis names the specific rubric items it maps to. The proposed R3 question is a gap that current wiring does not cover — confirm with PM whether R3 should be added before the survey is wired.

product-manager: Please file the following cards from this doc:

1. Add R3 survey question ("did Raxx address the frustration you described before the walkthrough?") to the rubric — requires rubric update + scoring table update + survey form update.

2. Move CI1 ("wants next round") from scored items to operational pipeline gate — no score weight change needed if already 0; confirm in rubric doc.

3. Update screen 2 (walk-strategies) to include an explicit enforcement-moment line per H1 action plan: "when the position is open, these rules cannot be silently overridden."

4. Verify Screen 3 walkthrough framing passes retrospective test per H3 action plan: backtest demo should show a specific historical result, not just the form UI.