Raxx · internal docs

internal · gated

Beta Walkthrough Best Practices — Raxx Closed-Beta Recipe

Date: 2026-06-11 Scope: Research brief for Raxx Phase-1 closed-beta tester onboarding design Author: business-legal-researcher (research only — not a UX or product directive)

Q1 — Pattern Survey: What Top-Tier SaaS Apps Do for Closed-Beta / First-Touch Onboarding

Fintech Consumer Apps

Robinhood - Steps: ~4 screens (KYC + goal + first watchlist + first deposit prompt) - Density: one concept per screen; large type, single CTA - Visual approach: clean white, microinteractions on each tap confirming progress - Survey timing: post-signup, before first trade; 3 questions (age bracket, investment goal, experience level) - Survey length: 3 questions, mandatory routing - End-state: empty account with sample watchlist and educational card deck - Notable pattern: Progress bar across every KYC step — removes fear of the unknown length - Source: https://www.eleken.co/blog-posts/fintech-ux-best-practices

M1 Finance - Steps: ~6 (goal-setting, pie-builder, first slice, risk tolerance, funding, confirmation) - Density: moderate; the pie visualizer is the conceptual anchor - Visual approach: animated pie chart responds to every tap — structure is visible before money moves - Survey timing: during walkthrough (goal + risk); no post-walkthrough survey for free tier - Survey length: 2 routing questions built into the flow, not labeled as survey - End-state: pre-populated demo "Pie" with suggested ETF slices the user can modify - Notable pattern: Outcome-first framing — shows the allocation result BEFORE asking for personal details - Source: https://m1.com/ (primary) + https://financebuzz.com/m1-finance-vs-robinhood

Public.com - Steps: ~5 (interest selection, first stock, social follow, account creation, funding) - Density: low; social proof (what friends hold) is the primary hook - Visual approach: feed-style cards with community annotations - Survey timing: interest selection IS the survey (3-5 tags), pre-product - Survey length: 3 tags, 15 seconds - End-state: pre-populated social feed showing real activity from anonymous peers - Notable pattern: Social scaffolding before any financial decision; user feels contextualized before they act - Source: https://www.webstacks.com/blog/fintech-ux-design

Trading Prosumer Tools

TradingView - Steps: ~3 (chart type, instruments of interest, layout); most users skip to the chart immediately - Density: high; the chart IS the product; no hand-holding assumed - Visual approach: dense, data-rich; no simplified onboarding mode - Survey timing: none during walkthrough; post-trial upgrade prompts use embedded NPS - Survey length: NPS only (1 question) in upgrade prompt - End-state: default BTC/USD chart with all indicators pre-visible; user must configure to own tickers - Notable pattern: Respects expertise; skips softening screens for prosumer audience. No "let us show you" — just the product. - Source: https://www.tradingview.com/ (primary); UI pattern documented in https://www.saasui.design/blog/7-saas-ui-design-trends-2026

Tastytrade / ThinkorSwim papermoney - Steps: ~5-8 for paper trading activation (brokerage account creation gates paper mode) - Density: high; assumes you know what a put spread is - Visual approach: platform-native; no simplified "beginner mode" during onboarding - Survey timing: UNKNOWN — no documented closed-beta survey pattern found in public sources - Survey length: UNKNOWN - End-state: live paper-money account with $100k synthetic balance; populated with real market data - Notable pattern: Real market data in paper mode from minute one — no toy data. Confidence comes from authenticity of the environment. - Source: https://tastytrade.com/newsroom/press-releases/ (primary) + https://support.tastytrade.com/support/s/solutions/articles/TradingView

B2B SaaS (Linear-class)

Linear - Steps: ~4 (team type, workspace name, first issue, invite prompt) - Density: one concept per screen; opinionated defaults everywhere - Visual approach: dark theme, tight typography; feels like a tool pros use - Survey timing: first screen; 1 segmentation question ("what kind of team?") - Survey length: 1 question; answers drive routing, not just analytics - End-state: pre-populated workspace with a sample project and 3 example issues - Notable pattern: Segmentation question actually changes what you see next — users can tell the answer matters - Source: https://pageflows.com/web/products/linear/

Notion - Steps: ~5 (use case, workspace type, optional import, template selection, invite) - Density: low-to-medium; progressive; optional steps labeled as optional - Visual approach: clean, template previews as visual anchors - Survey timing: step 1 and 2 of onboarding; baked in, not labeled "survey" - Survey length: 2 questions + optional - End-state: pre-populated workspace with relevant templates based on routing answers - Notable pattern: Optional steps are visibly optional — user agency is preserved; skip is real, not a trick - Source: https://goodux.appcues.com/blog/notions-lightweight-onboarding

Stripe / Stripe Atlas - Steps: ~4-6 for test payment activation; Atlas is longer (~8, entity-formation heavy) - Density: moderate; progressive disclosure gates complexity behind earlier completions - Visual approach: annotated, code-adjacent; sandbox environment mirrors production API behavior - Survey timing: none during core flow; post-activation email survey is optional - Survey length: 3-4 questions post-activation - End-state: live sandbox with pre-seeded test data; developer can fire real API calls in minutes - Notable pattern: Activation milestone frames the end-state ("make a test payment") — the goal is concrete and time-bound, not abstract - Source: https://docs.stripe.com/stripe-apps/onboarding

Closed-Beta Specialists

Superhuman - Steps: 30-minute human-led onboarding call; not a self-serve flow - Density: specialist-paced; moves at user's demonstrated proficiency - Visual approach: live product with instructor narrating; not slides - Survey timing: pre-call Typeform (2-3 questions) + 2 minutes at call start - Survey length: 3-5 questions total across both touchpoints - End-state: user's real inbox, configured during call; Inbox Zero achieved by end of session - Notable pattern: Mandatory human presence for first access. Friction is the filter — only motivated users show up. The onboarding call IS the beta-tester qualification instrument. - Source: https://review.firstround.com/superhuman-onboarding-playbook/

Loom - Steps: ~3 (record first video, share it, see the view count) - Density: extremely low — one action per step - Visual approach: camera preview is the first thing on screen; no preamble - Survey timing: after first video share, not before; triggered by activation - Survey length: UNKNOWN (Substack source timed out) — estimated 3-5 questions post-activation based on PLG patterns - End-state: account populated with the video just recorded; viral loop begins immediately - Notable pattern: Activation event (first video recorded) is the onboarding. The walk IS the tour. - Source: https://onboardme.substack.com/p/looms-975m-user-onboarding-secret-perfect-timing-product-led-growth-loop (fetch timed out — pattern sourced from secondary: https://www.appcues.com/blog/saas-user-onboarding)

Slack (early invite era) - Steps: ~3 (workspace join, first message to Slackbot, first channel) - Density: one concept per step; Slackbot teaches through conversation - Visual approach: conversational; the product surface is the tutorial medium - Survey timing: 3-question survey baked into Slackbot conversation; feels like onboarding not survey - Survey length: 3 questions; answers immediately reflected in product behavior - End-state: user in a live workspace; Slackbot conversation is persistent and reference-able - Notable pattern: Survey IS the product experience. Questions are delivered through the product's own mechanism, removing the "survey wall" feeling. - Source: https://userpilot.com/blog/slack-onboarding/

Q2 — Anti-Patterns to Avoid

These are documented failure modes from analysis of 200+ onboarding flows and beta-program post-mortems:

1. Survey before first touch Asking for role, goals, or experience before the user sees anything is a prediction tax — they don't yet know what the product is or how they'll use it, so answers are speculative. Best practice: 2-4 routing questions embedded in step 1-2, framed as personalization, not intake. Source: https://www.appcues.com/blog/saas-user-onboarding

2. Feature parade Showing all features in sequence before the user has done anything. 92% of users dismiss these tours on the first step. The walk produces no activation because nothing was earned. Source: https://designerup.co/blog/i-studied-the-ux-ui-of-over-200-onboarding-flows-heres-everything-i-learned/

3. Fake skip buttons Skip labels that do not actually skip (they advance to the "next mandatory step"). Users who discover fake skips lose trust in the entire flow and the product. Source: https://www.chameleon.io/blog/onboarding-ux-patterns

4. Survey about features not yet seen Asking "how useful was the tax engine?" before the user has reached the tax engine. Useless data and confusing experience. Source: https://www.specific.app/blog/best-questions-for-beta-testers-survey-about-onboarding-experience

5. No "exit and return" affordance Users who start onboarding at an inconvenient time cannot save progress. Forcing completion in one session inflates abandonment for motivated users who weren't ready. Source: https://cieden.com/saas-onboarding-best-practices-and-common-mistakes-ux-upgrade-article-digest

6. Marketing-copy overload before the verb Long value-proposition paragraphs before the first interactive action. 72% of users say completing required information in under 60 seconds matters to them. Source: https://www.eleken.co/blog-posts/user-onboarding-best-practices

7. Segmentation questions that don't change anything Asking "are you a beginner or advanced trader?" then showing the same experience to both is a trust tax. Users can tell when answers have no effect.

8. Demo data that doesn't match the user's stated situation Pre-populated example using a $500K portfolio when the user said they're starting with $5K. Breaks immersion and signals the product isn't for them.

9. One-size-fits-all survey for a heterogeneous beta cohort For closed betas with hand-selected users (3-10 people), a generic 15-question survey produces noise, not signal. The instrument should be narrow and hypothesis-driven.

Q3 — Raxx-Specific Recommendation

Situational context that changes the calculus

Raxx's Phase-1 closed beta is 3-5 hand-selected testers who already know Kristerpher. They are not strangers. They are not discovering the brand. They have been briefed on the concept. This is closer to Superhuman's model (high-intent, invited, motivated) than Robinhood's model (mass-market, anonymous, skeptical). That distinction should drive every design decision.

The thesis to test is structural: does the user feel the structure-enforcement moment? Not "does the UI look good" — that is secondary. The question is whether a tester who enters an Iron Condor setup feels the system constraining and guiding them in a way that feels like relief, not restriction.

The Founders tier gate ($29, tax engine) means demonstrating the tax engine value in the walkthrough is a conversion-intent signal worth measuring — but only after the tester has experienced structure enforcement first.

Total screens: 5 (not counting confirmation/landing)

Step Name Content Density
1 Welcome + single routing question One question: "What do you usually trade?" (IC / vertical / equity / mixed) Minimal
2 Structure demo — enter a live IC Pre-seeded paper trade with real market data; tester fills in the spread width Medium
3 Structure enforcement moment System shows the max-loss gate triggering; tester sees the constraint in action High
4 Tax context reveal Show what the tax engine would surface for this trade (P/L estimate, lot attribution) Medium
5 Survey landing 4 questions, post-activation; tester has now done the thing Minimal

Step 2-3 is the activation event. The tester has placed a paper trade and seen the system push back on a rule violation or confirm a compliant structure. That is the "first video recorded" moment — the Loom pattern applied to structure enforcement.

Survey timing: After step 3 (post first IC attempt), not at the start. If any survey question is placed before step 2, delete it. The rubric already has a pre-walkthrough Section 1 (3 questions, persona-match only, not scored) — that's fine. The substantive hypothesis questions belong at step 5.

Survey length: 4 questions maximum. The tester rubric already exists (docs/marketing/beta-tester-rubric-2026-06-08.md) and is thorough — the walkthrough survey should be a sub-set of it, not a duplicate.

5 testable hypotheses for the survey

These are framed as hypotheses, not as survey question copy. The survey-question wording should be validated with marketing-strategist for brand voice.

H1 — Structure-gap resonance: The tester can articulate, in their own words, what Raxx prevented them from doing wrong. (Test with: "Describe what happened when you tried to [X]" — open-ended.)

H2 — Constraint as relief, not restriction: The tester's reaction to the max-loss gate is positive (feels protected) rather than negative (feels blocked). (Test with: single-select "the system limit felt: helpful / annoying / I didn't notice it.")

H3 — Tax engine value is felt without explanation: After seeing the tax context screen, the tester believes the tax information would have changed a real past trade decision. (Test with: "Would this information have changed a past trade? Yes / No / I don't do enough volume for this to matter.")

H4 — Upgrade intent: After seeing the Founders tier gate on the tax engine, tester assigns a dollar value to the feature. (Test with: "What's the most you'd pay per month for this?" — open-ended number field, not a range.)

H5 — Re-invitation NPS proxy: Tester would recommend the beta to another options trader in their network. (Standard NPS: 0-10 scale + one open-ended "why" field.)

One pattern from Q1 to translate to Raxx

Tastytrade / papermoney: real market data from minute one. Their paper-money environment uses live market prices, not toy data. This produces a specific kind of confidence: the user knows they are seeing what is real. Raxx should seed the paper-trade walkthrough with yesterday's actual SPX options chain, not a synthetic example. If the tester can look at the numbers and recognize them from their own broker screen, the structure-enforcement moment lands harder.

One pattern to explicitly NOT use

Robinhood's post-signup survey before first trade. Robinhood asks about investment goals and risk tolerance before the user has touched anything, then ignores the answers (the product is the same for everyone). For Raxx's beta, this pattern is doubly harmful: (a) testers are hand-selected experts who find beginner-framing patronizing, and (b) survey answers collected before first use carry no predictive value for the hypothesis Raxx is actually testing (structure-gap resonance). The existing beta-tester rubric's pre-walkthrough Section 1 is fine because it is labeled as persona-match context and is not scored — but any expansion of that pre-walkthrough block should be resisted.

The 10/10 Raxx Walkthrough Recipe

Five screens. Real market data. The activation event is structure enforcement, not account creation. A tester enters one Iron Condor in a paper environment seeded with yesterday's actual options chain, encounters the system's constraint logic in action, and sees the tax context surface for that trade before answering four survey questions. The pre-walkthrough survey (3 questions, already exists) is persona-match only and is not scored — it should not grow. The four post-activation questions test five named hypotheses: structure-gap resonance, constraint as relief, tax engine value, upgrade intent, and NPS proxy. The Superhuman pattern (human presence as quality filter) is adapted: for 3-5 friends, Kristerpher is on a brief async Loom walkthrough the tester watches first, then self-completes the 5-screen flow, then books a 15-minute debrief. That debrief is where the qualitative signal lives — the survey is just the pre-read.

What to Ask Marketing-Strategist to Verify

  1. "Structure enforcement" vs "guardrails" vs "rules" — which Confidence Engine word lands best when the constraint triggers on-screen? The survey hypothesis H2 ("constraint as relief") depends on the label used in the UI being the same language used in the survey question.

  2. Does the Founders tier reveal on screen 4 feel like a pitch or a feature? The tax engine gate is a conversion-intent moment, but if the copy reads as upsell it breaks the trust framing. Marketing-strategist should audit screen 4 copy against the "structure gap, not skill gap" positioning.

  3. Is "paper trade with real market data" consistent with the Raxx brand voice around determinism? Raxx's thesis is user-driven input. A pre-seeded walk may feel like the system is doing the trade for them. Verify whether the walk should be tester-initiated (tester picks the ticker + strikes) or operator-seeded (Raxx pre-selects a recognizable trade from last week's market).

  4. What is the right NPS proxy question for an options-trader cohort? The standard "would you recommend to a friend" NPS may not translate — options traders do not generally recruit friends into their toolchain. Verify whether the H5 question should instead be "would you pay for this before the end of the beta period?" as a stronger intent signal.

  5. Does the 15-minute async-Loom-then-self-serve-then-debrief model match the tone of Raxx's closed-beta invite communications? The closed-beta campaign doc (docs/marketing/closed-beta-campaign-2026-06-08.md) should already set expectations — confirm the walkthrough shape is coherent with whatever promise was made in the invite.

Sources