Draft Stonk First-Pick Speed UX Variations

This variation differs from sibling concepts by prioritizing direct intent capture. The first meaningful interaction is not a card grid, guided concept step, challenge prompt, or board preview. It is search.

Page And Flow Changes

The first-pick path is compressed into three surfaces:

1. Quick Draft Search Start

- A concise game frame and primary search input share the first viewport.

- The primary action is to start finding a first pick, not to browse a landing page.

- A compact trust line is visible near the input: no money, no prizes, no brokerage, game picks only.

1. Search Result And Pick Confirmation

- Matching company/ticker results appear as soon as the user types.

- Selecting a result opens a focused selected-stock preview with a single primary action: make this game pick.

- The selected preview repeats the local/mock/delayed data label and pick-not-trade boundary.

1. First Pick Recorded And Board Preview

- Success confirms the stock was recorded as a fantasy pick.

- The draft board preview appears immediately with the user's pick in slot one, bot continuation pending or recorded, and a clear next-turn state.

- The page avoids treating the successful pick as a completed task; it frames it as the first move in the draft.

Progression Model

The user advances through a direct progression:

StartQuickDraft -> SearchStockUniverse -> selected StockChoice -> MakeStockPick -> FirstPickRecorded -> GetDraftBoardPreview -> AdvanceTurnAfterFirstPick.

Progression differences from siblings:

• Search is the default entry route.
• Browse is secondary recovery, not the lead interaction.
• Education is just-in-time and proximal, not a separate step.
• The board appears only after the pick is recorded, not before.
• Social or challenge framing is absent unless the user arrived through a future invite context.

Primary completion criterion:

• The user sees a valid first pick recorded on the board, with no-money/no-prize/no-brokerage/no-advice framing still visible and data posture labeled.

Onboarding And Activation Model

Onboarding is minimized to a compact action frame:

• Header: "Draft a stock like a fantasy pick."
• Supporting line: "Pick a company for a no-money game draft. No brokerage, no prizes, no investment advice."
• Search placeholder: "Search a company or ticker"
• Data label near results: "Prototype stock list: local/mock data for gameplay."

Activation occurs when:

• The user searches or selects a recognizable stock.
• The pick action uses game language, such as "Make fantasy pick."
• The validation result records the pick.
• The board preview shows the selected stock in the user's first slot.

The variation should not require the user to acknowledge legal copy before picking. Trust copy is visible and contextual, but the path remains fast.

Typical Workflow Sequence

1. User lands on the quick draft surface.
2. System creates or prepares a local DraftSession with user and bot participants.
3. User types a company name, ticker, or recognizable label.
4. System displays matching StockChoice rows with ticker, company name, availability, and data label.
5. User selects a result.
6. System shows selected-stock preview, availability, and a primary "Make fantasy pick" action.
7. User confirms the pick.
8. System enters validating_first_pick.
9. If allowed, system records FirstPickRecorded, marks the stock taken, and completes the user's first turn.
10. System advances to board preview and queues or records a compact bot pick continuation.
11. User sees the pick counted and the next draft action.

Sharing, Collaboration, And Permissions Model

This variation is solo-first. It does not introduce share, invite, league, or organizer controls before the first pick.

If the user arrived through a future friend link, the entry context may add a short prompt above the search input, but the interaction still remains search-first.

Permissions:

• No account.
• No group setup.
• No role management.
• No public contest entry.
• No brokerage or payment permissions.

Share and invite remain downstream sibling concerns after standings or replay/share payoff is proven.

Return-Use And Notification Model

Return-use is local and lightweight:

• If local state contains an incomplete first-pick draft, show "Resume your local draft" with the previous selected pick or active turn.
• If local state is unavailable, show a restart option with clear prototype-state copy.
• No email, push, SMS, or reminder notifications belong in this variation.

The route may preserve the user's last searched term only within local prototype state, not as a persistent account feature.

Failure Recovery And Abandoned-Workflow Behavior

No Results

Symptom: user searches a company, nickname, or ticker that is not in the local/mock universe.

Recovery:

• Explain that this prototype uses a limited stock list.
• Offer "Browse recognizable stocks" as an escape hatch.
• Preserve the search term while showing suggested alternatives if available.

Duplicate Or Taken Stock

Symptom: user selects a stock already taken by user or bot.

Recovery:

• Disable the pick action.
• Message: "Already picked in this draft. Choose another game pick."
• Show available nearby alternatives or return focus to search.

Stock Unavailable

Symptom: a stock is present but cannot be picked.

Recovery:

• Mark it unavailable in the result row and selected preview.
• Explain that unavailable choices cannot be used in this local draft.
• Provide "Choose another stock."

Data Unavailable

Symptom: local/mock stock data cannot load.

Recovery:

• Stop the pick action.
• Show local/prototype data error copy.
• Offer retry or restart quick draft.

Not User's Turn

Symptom: bot continuation or turn state briefly prevents user action.

Recovery:

• Disable pick action and show current turn state.
• Keep the board preview visible so the block feels like draft rules, not an app error.

Abandonment

If the user leaves before making a pick:

• Returning to the route starts a fresh quick draft or resumes local state if available.
• The product should not nag or notify.

If the user leaves after the first pick:

• Returning shows the pick recorded when local state is available.
• If unavailable, restart with a plain local-state explanation.

Navigation Model

Primary navigation is linear:

• Search/start surface.
• Selected-stock preview.
• First-pick success and draft-board preview.

Secondary navigation:

• "How it works" disclosure from the start surface.
• "Browse instead" from no-results or empty-search states.
• "Choose another stock" from selected preview or validation failure.
• "Restart quick draft" only for local-state or data-loading failures.

The variation should not introduce a persistent sidebar, multi-page setup, tab system, onboarding carousel, or full landing-page navigation before first pick.

Screen-By-Screen Layout

Screen 1: Quick Draft Search Start

Purpose: turn a market take into a first pick as fast as possible.

Regions:

• Compact title and game-frame line.
• Trust boundary line near the title.
• Dominant search input.
• Local/mock data posture below or beside the input.
• Empty-state helper with examples: company name and ticker.
• Optional compact "How it works" disclosure.

Primary control:

• Search input with immediate result feedback.

Secondary controls:

• Browse recognizable stocks.
• How it works.

Screen 2: Search Results

Purpose: let the user recognize and select a stock choice.

Regions:

• Search input remains in place.
• Result rows show company name, ticker, availability, and a small data label.
• Taken/unavailable states are visible before selection.
• No-results recovery is in the same region, not a separate page.

Primary control:

• Select an available result row.

Secondary controls:

• Clear search.
• Browse local stock list.

Screen 3: Selected Stock Preview

Purpose: confirm the user's intended game pick without implying investment action.

Regions:

• Selected company/ticker.
• Availability status.
• Pick-not-trade copy.
• Local/mock/delayed data label.
• Primary "Make fantasy pick" action.
• "Choose another stock" secondary action.

Primary control:

• Make fantasy pick.

Blocked states:

• Duplicate/taken.
• Unavailable.
• Data unavailable.
• Not user's turn.

Screen 4: First Pick Recorded And Board Preview

Purpose: prove the pick counted and continue into the draft.

Regions:

• Success message: first pick recorded.
• User's pick in the first draft slot.
• Compact participant/turn strip.
• Bot pick pending or recorded.
• Remaining slots/next turn indicator.
• Trust and data label repeated unobtrusively.

Primary control:

• Continue draft or proceed as the board advances.

Secondary controls:

• Restart quick draft only if prototype scope allows.

Key Components And Controls

• Search input supporting company name and ticker.
• Search result row/list item.
• Availability badge: available, taken, unavailable, data issue.
• Selected-stock preview.
• Primary game-pick button.
• Validation status message.
• Browse fallback button.
• Compact trust boundary line.
• Data label pill or text line.
• Draft-board preview with user's first pick and bot continuation state.

All controls use game language:

• Use: pick, draft, game pick, choose another, board, turn.
• Avoid: buy, sell, trade, order, position, portfolio, recommendation, advice, profit, prize.

Button And Link Behavior

• Search input updates results on input change.
• Result row click selects a StockChoice and opens the selected preview.
• "Make fantasy pick" triggers MakeStockPick.
• Disabled "Make fantasy pick" displays the reason and next action.
• "Choose another stock" clears selected preview and returns focus to search/results.
• "Browse recognizable stocks" switches to a browse fallback without leaving the first-pick branch.
• "How it works" expands a compact explanation inline; it does not start a separate onboarding flow.
• Board continuation advances after FirstPickRecorded; bot continuation may be automatic, queued, or simulated with a short visible state.

Spatial Density, Sizing, And Hierarchy

Density: compact and action-first.

Hierarchy:

1. Search/pick action.
2. Selected stock and validation result.
3. Trust and data posture.
4. Board continuation.
5. Optional explanation.

Mobile-first constraints:

• Search input must be reachable in the first viewport.
• Primary pick action must not be hidden below long explanation.
• Result rows must support touch targets without crowding.
• Trust copy should be one concise line near the action, with longer explanation hidden behind disclosure.

Desktop constraints:

• Keep the experience narrow enough to feel like a focused draft action, not a finance dashboard.
• Avoid large marketing hero treatment.
• Board preview can sit beside or below search only after the first pick is recorded.

Responsive Behavior

Mobile

• Single-column flow.
• Search input, selected preview, and primary action stack vertically.
• Results use full-width rows.
• Board preview appears below success confirmation.
• Optional explanation stays collapsed by default.

Tablet

• Search/results and selected preview may sit in a two-region layout.
• Board preview stays below until first pick success.
• Touch targets remain large.

Desktop

• Centered action column with a compact right-side or below-the-fold board preview after success.
• Do not expand into a full trading-style table or market dashboard.

Visual Tone

Tone should be fast, clear, and game-like without becoming flashy or speculative.

Suitable direction:

• Plain-spoken fantasy draft language.
• Recognizable stock identity through company/ticker labels.
• Compact trust copy.
• Lightweight game-board continuation.

Avoid:

• Brokerage visual patterns.
• Stock chart dominance before first pick.
• Portfolio/account language.
• Prize, betting, or leaderboard hype before trust is established.
• Heavy legal disclaimer walls.

Strengths

• Tests the strongest speed thesis directly.
• Minimizes setup and concept friction.
• Works with local/mock data and no account.
• Establishes a clean baseline for comparing slower but more explanatory sibling variations.
• Makes company/ticker search behavior the center of the first prototype review.

Risks And Failure Modes

• Users without a stock idea may stall at an empty search field.
• Minimal explanation may leave anxious users unsure whether this is trading or advice.
• If result rows resemble a brokerage search, the trust boundary may fail.
• If the board preview appears too late or too weakly, first-pick success may feel like a dead end.
• If the local/mock data label is visually buried, users may over-read the stock data as live or investment-relevant.

Implementation Complexity

Complexity: low.

Reasons:

• Requires no account, backend, payment, brokerage, or production market data.
• Uses the existing logical contracts: StartQuickDraft, SearchStockUniverse, MakeStockPick, and GetDraftBoardPreview.
• Can be represented with local/mock stock fixtures.
• Needs only a small number of UI states, but those states must be precise.

Primary implementation risks:

• Search quality across company names, tickers, and common recognition labels.
• Clear disabled/blocked states.
• Copy discipline around pick-not-trade language.

What UI Review Should Validate First

The next $ui-interview search-to-pick-sprint pass should validate:

• Whether the search input belongs in the first viewport as the dominant control.
• Whether users can tell they are making a fantasy pick, not buying/trading a stock.
• Whether the local/mock data label is visible without distracting from the action.
• Whether no-results and duplicate/taken recovery are clear enough.
• Whether the board preview after success makes continuation feel natural.
• Whether the mobile layout preserves speed without hiding trust copy.

User Signal That Makes This Branch Ready For UI Interview

This branch is ready for $ui-interview when reviewers agree that its thesis is worth seeing visually:

• The fastest path should be tested as a baseline.
• Search-first does not violate trust or comprehension constraints on paper.
• Recovery requirements are explicit enough to design.
• The board-preview handoff is included, not deferred.

Future Experiment Route

Potential route after UI approval only: /experiments/search-to-pick-sprint.

No prototype buildout, implementation route, or shared production infrastructure should be created from this UX spec alone. It must first pass whole-set UX variation alignment and then route through $ui-interview search-to-pick-sprint.

This variation differs from siblings by putting the stock universe in front of the user before asking them to type. It treats first-pick speed as recognition speed rather than command speed.

Page And Flow Changes

The first-pick path is organized around a playable stock pool:

1. Quick Draft Browse Start

- A concise game frame sits above a visible list or grid of recognizable company choices.

- The stock pool shows company names first, tickers second.

- A compact trust line and data label frame the pool as a local/mock game list.

1. Recognizable Stock Pool

- Cards or rows show company name, ticker, availability, and simple context labels such as "Tech", "Consumer", or "Market story".

- Search filters the visible pool, but the user can pick without typing.

- Taken or unavailable choices remain visible with clear disabled reasons.

1. Pick Confirmation And Board Preview

- Selecting a card opens a focused confirmation state.

- The pick action uses fantasy-game language and repeats the data/trust boundary.

- Success moves directly to the draft-board preview with the chosen company recorded as the user's first pick.

Progression Model

The user advances through a recognition-led progression:

StartQuickDraft -> BrowseStockUniverse -> selected StockChoice -> MakeStockPick -> FirstPickRecorded -> GetDraftBoardPreview -> AdvanceTurnAfterFirstPick.

Progression differences from siblings:

• Browse is the default entry route.
• Search is refinement, not the primary starting action.
• The user can act from familiar company recognition before understanding ticker syntax.
• Concept education is embedded in the pool framing and confirmation copy.
• The board appears after the pick is recorded, not before.

Primary completion criterion:

• The user can identify a familiar available company, make it a fantasy game pick, and see it recorded on the board without needing exact ticker knowledge.

Onboarding And Activation Model

Onboarding is a short playable prompt:

• Header: "Pick a company for your draft."
• Supporting line: "Choose from this local game list, or search by company or ticker."
• Trust boundary: "No money, no prizes, no brokerage, no investment advice."
• Data label: "Prototype stock list: local/mock data for gameplay."

Activation occurs when:

• The user recognizes a company in the stock pool.
• The selected card makes availability and game-pick language clear.
• The pick is validated and recorded.
• The board preview shows the company in the user's first pick slot.

The variation should not ask the user to study the full concept before browsing. The pool itself should make the game legible.

Typical Workflow Sequence

1. User lands on the quick draft surface.
2. System prepares a local DraftSession, participants, and StockUniverse.
3. User sees a curated stock pool with recognizable company-first cards or rows.
4. User scans by company name, category, availability, or familiar market story.
5. User optionally filters the pool with search.
6. User selects an available StockChoice.
7. System shows selected-stock confirmation with ticker, company name, data label, availability, and pick-not-trade copy.
8. User confirms the fantasy pick.
9. System enters validating_first_pick.
10. If allowed, system records FirstPickRecorded, marks the stock taken, and completes the user's first turn.
11. System advances to the board preview and queues or records compact bot continuation.
12. User sees the pick counted and the next draft action.

Sharing, Collaboration, And Permissions Model

This variation is solo-first and does not add share, invite, or group controls before the first pick.

If the user arrives from a friend or challenge context, the stock pool can carry a short challenge prompt above the cards, but the interaction remains browse-first.

Permissions:

• No account.
• No group setup.
• No role management.
• No public contest entry.
• No brokerage or payment permissions.

The browse pool should avoid public leaderboard, prize, or contest cues. It is a local game draft chooser.

Return-Use And Notification Model

Return-use is local and state-based:

• If local state contains an incomplete first-pick draft, show the stock pool with "Resume your local draft" and the current pick/turn state.
• If the user previously searched, optionally preserve that query in local state, but keep the browse pool visible.
• If local state is unavailable, restart with clear prototype-state copy.

No email, push, SMS, reminder, or activity-feed model belongs in this variation.

Failure Recovery And Abandoned-Workflow Behavior

Desired Stock Missing From Pool

Symptom: user scans the stock pool and does not see the company they expected.

Recovery:

• Offer search directly above the pool.
• Explain that the prototype uses a limited local/mock stock list.
• Let the user browse available recognizable stocks without framing missing companies as errors.

No Search Results

Symptom: user searches a company, nickname, or ticker that is not in the local/mock universe.

Recovery:

• Keep the browse pool visible below the no-results message.
• Offer suggested recognizable alternatives when available.
• Copy: "Not in this prototype list yet. Pick another game stock from the local pool."

Duplicate Or Taken Stock

Symptom: user taps a stock already taken by the user or bot.

Recovery:

• Keep the taken card visible but disabled.
• Show who picked it when that context exists.
• Message: "Already picked in this draft. Choose another game pick."
• Preserve focus in the pool rather than sending the user to a generic error screen.

Stock Unavailable

Symptom: a stock appears but cannot be picked.

Recovery:

• Mark unavailable on the card before selection.
• Disable the primary pick action.
• Explain the local game-list limitation and offer nearby available alternatives.

Data Unavailable

Symptom: local/mock stock universe cannot load.

Recovery:

• Show a data-label error state where the pool would be.
• Offer retry or restart quick draft.
• Avoid showing stale or unlabeled stock cards.

Not User's Turn

Symptom: user attempts to pick while bot continuation or turn state blocks action.

Recovery:

• Disable pool pick actions.
• Show the current turn state near the board preview or pool header.
• Resume pick controls when the user's turn is active.

Abandonment

If the user leaves before making a pick:

• Returning shows the stock pool again or resumes local state when available.
• The product should not nag, notify, or require account recovery.

If the user leaves after making the first pick:

• Returning shows the pick recorded when local state exists.
• If unavailable, restart with local-state explanation and the browse pool ready.

Navigation Model

Primary navigation is linear but pool-centered:

• Browse start with stock pool.
• Selected-stock confirmation.
• First-pick success and draft-board preview.

Secondary navigation:

• Search/filter within the pool.
• "Show all" after filtering.
• "How it works" compact disclosure from the browse start.
• "Choose another stock" from selected confirmation or validation failure.
• "Restart quick draft" for local-state or data-loading failures.

The variation should not introduce a full stock screener, portfolio tabs, watchlist management, persistent navigation, or onboarding carousel before the first pick.

Screen-By-Screen Layout

Screen 1: Quick Draft Browse Start

Purpose: make the first pick feel like choosing from a fantasy draft pool.

Regions:

• Compact title and game-frame line.
• Trust boundary line near the title.
• Local/mock data posture near the stock pool.
• Search/filter input as a secondary control.
• Recognizable stock pool as the dominant visual area.
• Optional compact "How it works" disclosure.

Primary control:

• Select an available company card or row.

Secondary controls:

• Search or filter company/ticker.
• Show all.
• How it works.

Screen 2: Recognizable Stock Pool

Purpose: help users choose through recognition without forcing ticker knowledge.

Regions:

• Company-first cards or rows.
• Ticker and availability metadata.
• Simple optional labels such as category or market-story cue.
• Disabled/taken/unavailable states in-place.
• Search results or no-results recovery without leaving the pool.

Primary control:

• Tap/select an available stock choice.

Secondary controls:

• Filter search.
• Clear search.
• Choose another stock after a blocked state.

Screen 3: Selected Stock Confirmation

Purpose: turn a recognized company into an intentional fantasy game pick.

Regions:

• Selected company name and ticker.
• Availability status.
• Pick-not-trade copy.
• Data label.
• Primary action to make the fantasy pick.
• Secondary action to return to the pool.

Primary control:

• Make fantasy pick.

Secondary controls:

• Choose another stock.
• View local data label explanation if needed.

Screen 4: First Pick Recorded And Board Preview

Purpose: prove the pick counted and show the draft continuing.

Regions:

• Success message naming the selected company as a fantasy pick.
• Compact board preview with user's first slot filled.
• Bot continuation pending or recorded.
• Turn state and remaining draft context.
• Trust/data labels preserved without dominating the board.

Primary control:

• Continue draft or watch next bot pick, depending on later UI branch choice.

Secondary controls:

• Restart quick draft only if the prototype supports restart.

Key Components And Controls

• Company-first stock pool cards or rows.
• Search/filter input with clear action.
• Availability and taken-state badges.
• Local/mock data label.
• Selected-stock confirmation panel.
• Primary "Make fantasy pick" button.
• "Choose another stock" recovery action.
• No-results recovery block.
• First-pick success message.
• Compact draft-board preview.

Component requirements:

• Cards/rows must prioritize company name over ticker.
• Disabled states must explain why a choice cannot be picked.
• Data posture must be visible on the pool and selected confirmation.
• Pick controls must use game language, not investment-action language.

Button And Link Behavior

• StartQuickDraft: prepares the local draft session and stock universe.
• BrowseStockUniverse: loads the visible pool by default.
• SearchStockUniverse: filters the pool and preserves browse recovery.
• MakeStockPick: validates and records the selected available stock choice.
• ChooseAnotherStock: clears validation result and returns to the pool.
• GetDraftBoardPreview: displays the first-pick success continuation.
• AdvanceTurnAfterFirstPick: moves from first pick into compact bot continuation.

Buttons:

• "Make fantasy pick" is primary only after an available stock is selected.
• "Choose another stock" appears after selected confirmation and blocked states.
• "Show all" clears search/filter.
• "How it works" opens a compact disclosure, not a separate required step.

Avoid:

• Buy, sell, trade, order, invest, profit, prize, wager, or recommendation labels.
• Disabled buttons without visible reason.
• Any button that asks for account, brokerage, payment, or club setup before the first pick.

Spatial Density, Sizing, And Hierarchy

Density should be comfortable but not sparse:

• The stock pool should fit several recognizable choices in the first useful viewport.
• Mobile should show enough cards/rows to make browsing feel real without creating tiny touch targets.
• Company names should be scannable; ticker metadata should support recognition but not dominate.
• Trust and data labels should be close to the pool and confirmation action, not buried in a footer.

Hierarchy:

1. Game-frame title and trust boundary.
2. Stock pool.
3. Search/filter refinement.
4. Selected-stock confirmation.
5. Board continuation.

The visual feel should be closer to a draft pool than a brokerage watchlist. Use availability, turn, and game-pick language to prevent finance-tool drift.

Responsive Behavior

Mobile:

• Use a single-column card/list pool with large tap targets.
• Keep search/filter near the top, but do not let it consume the whole first viewport.
• Selected-stock confirmation can appear inline above the pool or as a bottom sheet only if it does not hide data/trust labels.
• Board preview follows success in the same vertical flow.

Tablet:

• Use a two-column card grid or list with a right-side selected preview when space allows.
• Keep the pool and confirmation visible together after selection.

Desktop:

• Use a denser grid or list with selected preview beside the pool.
• Avoid turning the surface into a financial dashboard or stock screener.

All breakpoints:

• Preserve 44px minimum touch targets.
• Keep disabled states and data labels visible.
• Do not require horizontal scrolling to select a stock.

Visual Tone

The tone is approachable, playable, and recognizable.

Useful cues:

• Fantasy draft pool language.
• Company-first recognition.
• Availability/taken states that feel like draft rules.
• Compact trust copy that reads as product framing, not legal ceremony.

Avoid:

• Brokerage watchlist visual language.
• Dense price tables.
• Candlestick charts, gain/loss heatmaps, portfolio allocation, or trading-style rows.
• Prize, contest, betting, or real-return cues.

Strengths, Risks, And Failure Modes

Strengths:

• Reduces blank-search anxiety.
• Supports users who know company names better than tickers.
• Makes the stock universe feel playable immediately.
• Keeps recovery from missing search results close to available alternatives.
• Helps the first pick feel like drafting from a pool.

Risks:

• A small curated universe may feel limiting.
• Users with a specific ticker may find browsing slower than search.
• Card/list presentation can drift into brokerage watchlist patterns if price-like data or finance visuals dominate.
• The pool can crowd out trust/data labels on mobile if density is mishandled.

Failure modes:

• The user cannot find the desired company and assumes the product is incomplete.
• Disabled/taken states are unclear.
• The selected confirmation looks like investment advice.
• The board continuation feels disconnected from the pool selection.
• The pool becomes too educational or too decorative, slowing the first pick.

Implementation Complexity

Rough complexity: low-medium.

Drivers:

• Requires a curated local/mock stock universe with availability states.
• Requires browse, filter/search, no-results, selected-confirmation, and disabled/taken states.
• Does not require accounts, live data, external APIs, persistent watchlists, or production stock lookup.
• Requires careful mobile layout so the pool is useful without overwhelming the first viewport.

Relative to siblings:

• More UI surface than Search-To-Pick Sprint because the browse pool must feel credible.
• Less conceptual sequencing than Guided Micro-Onboarding.
• Less social/copy complexity than Challenge Prompt Entry.
• Less board-system exposure than Board-First Preview.

What UI Review Should Validate First

The first $ui-interview recognizable-watchlist-browse review should validate:

• Whether the stock pool feels like a fantasy draft pool rather than a brokerage watchlist.
• Whether company-first cards/rows make selection approachable without ticker knowledge.
• Whether search remains discoverable for users with a specific stock in mind.
• Whether local/mock data labels are visible without intimidating the user.
• Whether disabled/taken/unavailable states explain recovery clearly.
• Whether first-pick success naturally transitions to draft-board continuation.

User Signal For UI-Interview Readiness

This branch is ready for $ui-interview when the reviewer accepts that:

• Browse-first progression is meaningfully distinct from search-first progression.
• The parent first-pick-speed boundary is preserved.
• The design can be proposed with local/mock data and no production infrastructure.
• Trust, data-label, and pick-not-trade constraints are explicit.
• Recovery states are concrete enough to guide UI screen design.

Recommended next UI route after whole-set approval:

$ui-interview recognizable-watchlist-browse

This variation differs from siblings by adding guided comprehension before and around the chooser. It does not add account setup, full concept education, league operations, or scoring explanation. The guidance exists only to make the first pick feel safe, game-like, and intentional.

Page And Flow Changes

The first-pick path is organized into a short guided sequence:

1. Micro Step 1: Game Frame

- The user sees a concise explanation: pick stocks like fantasy draft players.

- The step uses no-money, no-prize, no-brokerage, no-advice language.

- The primary action starts the quick draft, not a registration flow.

1. Micro Step 2: Pick Boundary

- The user sees the first pick framed as a game move.

- Local/mock/prototype-only data posture is visible before any stock choice.

- The user can continue to choose by company name, ticker search, or suggested recognizable choices.

1. Guided Stock Choice

- The chooser combines a small recognizable stock set with search.

- Inline helper copy explains what makes a valid game pick.

- The selected-stock confirmation repeats the pick-not-trade boundary.

1. First Pick Recorded And Board Preview

- Success confirms the choice as a fantasy pick.

- The board preview appears immediately with the chosen stock recorded.

- A compact next-turn or bot-continuation state proves the pick counted.

Progression Model

The user advances through a comprehension-led progression:

StartQuickDraft -> guided game-frame acknowledgement -> BrowseStockUniverse or SearchStockUniverse -> selected StockChoice -> MakeStockPick -> FirstPickRecorded -> GetDraftBoardPreview -> AdvanceTurnAfterFirstPick.

Progression differences from siblings:

• The first meaningful interaction is a tiny game-frame step, not search, browse, challenge, or board inspection.
• Trust copy appears before chooser exposure and again at selected confirmation.
• The chooser can support both browse and search because the key variation is sequencing, not stock-discovery mode.
• The board appears only after the pick is recorded.
• The flow should feel like two or three small decisions, never a long education sequence.

Primary completion criterion:

• The user can explain that they made a no-money fantasy game pick and can see it recorded on the draft board.

Onboarding And Activation Model

Onboarding is explicit but short:

• Step title: "Draft stocks like fantasy picks."
• Supporting line: "Choose a company for a no-money game draft. This is not a trade, recommendation, brokerage, or prize contest."
• Data label: "Prototype stock list: local/mock data for gameplay."
• Progress cue: "Step 1 of 3" or equivalent, only if it reduces uncertainty without making the flow feel heavy.

Activation occurs when:

• The user understands the action is a game pick before seeing the stock chooser.
• The user selects an available company or ticker.
• The pick is validated and recorded.
• The board preview shows the first pick in the user's slot.

The onboarding must end as soon as the user is ready to pick. It should not explain equal-dollar standings, invite flows, full draft strategy, or replay/share payoff in this branch.

Typical Workflow Sequence

1. User lands on the quick draft surface.
2. System displays a compact game-frame step with trust boundary and start action.
3. User starts the quick draft.
4. System creates or prepares a local DraftSession, participants, active user turn, StockUniverse, TrustBoundary, and DataLabel.
5. System shows a short pick-boundary step or inline guided panel: "Your first move is choosing one company as a fantasy pick."
6. User continues to the stock chooser.
7. User searches by company/ticker or browses suggested recognizable stock choices.
8. User selects an available StockChoice.
9. System shows selected-stock confirmation with company, ticker, availability, data label, and pick-not-trade copy.
10. User confirms the fantasy pick.
11. System enters validating_first_pick.
12. If allowed, system records FirstPickRecorded, marks the stock taken, and completes the user's first turn.
13. System advances to the board preview and queues or records compact bot continuation.
14. User sees the pick counted and the next draft action.

Sharing, Collaboration, And Permissions Model

This variation is solo-first and avoids collaboration setup before the first pick.

The micro-onboarding may mention that later drafts can be social, but it must not introduce invite, share, league, organizer, club, or public contest controls in the first-pick path.

Permissions:

• No account.
• No payment.
• No brokerage connection.
• No group setup.
• No notification permission.
• No role management.

If the user arrived from a friend link in a future branch, the first step may acknowledge the challenge context, but the guided sequence still focuses on making one valid game pick.

Return-Use And Notification Model

Return-use is local and preference-aware:

• If the user has already completed the micro-onboarding in local prototype state, the route may compress or skip the first framing step and show a short "Quick draft" recap.
• If local state contains an incomplete guided flow, resume at the last safe step with a clear local-state label.
• If the user has a recorded first pick, return to the board preview when local state exists.
• If local state is unavailable, restart with clear prototype-state copy.

No email, push, SMS, reminder, digest, or activity feed is part of this variation.

The product should not nag users who abandon before choosing. The recovery path is simply a clear restart or resume of the local quick draft.

Failure Recovery And Abandoned-Workflow Behavior

User Hesitates At The Game Frame

Symptom: the user does not continue because the concept still feels unclear.

Recovery:

• Offer a one-line "How it works" disclosure.
• Keep the primary action visible.
• Avoid expanding into scoring, leagues, or full concept education.

User Worries This Is Trading Or Advice

Symptom: the user pauses near chooser or selected confirmation because the action feels investment-like.

Recovery:

• Repeat the trust boundary near the selected-stock preview.
• Use "fantasy pick" and "draft" language.
• Avoid price, profit, position, order, buy, sell, trade, advice, or recommendation cues.

No Search Results

Symptom: user searches a company, nickname, or ticker that is not in the local/mock universe.

Recovery:

• Explain that the prototype uses a limited local/mock stock list.
• Keep suggested recognizable choices visible.
• Copy: "Not in this prototype list yet. Choose another game stock from the local pool."

Duplicate Or Taken Stock

Symptom: user selects a stock already taken by the user or bot.

Recovery:

• Show it as taken in chooser and selected confirmation.
• Message: "Already picked in this draft. Choose another game pick."
• Keep the user in the chooser with available alternatives.

Stock Unavailable

Symptom: a stock appears but cannot be picked.

Recovery:

• Disable the primary pick action.
• Explain the local game-list limitation.
• Offer "Choose another stock" and suggested available choices.

Data Unavailable

Symptom: local/mock stock universe cannot load.

Recovery:

• Stop progression before stock selection.
• Show the local/prototype data posture and retry action.
• Avoid showing unlabeled or stale stock choices.

Not User's Turn

Symptom: bot continuation or turn state blocks user action.

Recovery:

• Explain the current turn state in game language.
• Disable pick action until user turn is active.
• Keep the board preview visible if the first pick has already been recorded.

Abandonment

If the user leaves before selecting a stock:

• Returning resumes the local guided step or restarts the quick draft.
• The first step should not imply failure or require account recovery.

If the user leaves after selecting but before confirmation:

• Returning can restore selected-stock preview when local state exists.
• If unavailable, restart with plain prototype-state copy.

If the user leaves after making the first pick:

• Returning shows the recorded pick and board preview when local state exists.
• If unavailable, restart with clear local-state explanation.

Navigation Model

Primary navigation is linear and step-based:

• Game frame.
• Pick boundary and chooser entry.
• Stock chooser.
• Selected-stock confirmation.
• First-pick success and draft-board preview.

Secondary navigation:

• Back from selected confirmation to chooser.
• Choose another stock after a blocked validation result.
• Compact "How it works" disclosure from the framing step or chooser.
• Restart quick draft only for local-state or data-loading failures.

The variation should not introduce persistent app navigation, tutorial pagination beyond the micro-flow, account setup, scoring tabs, public contest links, or full concept pages before the first pick.

Screen-By-Screen Layout

Screen 1: Game Frame

Purpose: establish the fantasy draft idea and trust boundary in one lightweight step.

Regions:

• Compact title and one-sentence game frame.
• Trust boundary line: no money, no prizes, no brokerage, no advice.
• Local/mock/prototype data label or note that appears before stock data.
• Primary action to start a quick draft.
• Optional compact "How it works" disclosure.

Primary control:

• Start quick draft.

Secondary controls:

• How it works.
• Skip to pick, only if user intent or return state supports it.

Screen 2: Pick Boundary And Chooser Entry

Purpose: explain the user's immediate task before showing choices.

Regions:

• Short prompt: "Your first move is choosing one company as a fantasy pick."
• Pick-not-trade reminder.
• Search input and/or suggested recognizable choices.
• Data label close to chooser entry.
• Optional progress cue.

Primary control:

• Search or select a suggested company.

Secondary controls:

• Browse all local choices.
• Back to game frame.

Screen 3: Guided Stock Chooser

Purpose: help the user make a valid first pick with both comprehension and speed.

Regions:

• Search input supporting company name and ticker.
• Recognizable local/mock choices.
• Availability/taken/unavailable states.
• Inline helper explaining valid game pick criteria.
• No-results and missing-stock recovery.

Primary control:

• Select an available stock choice.

Secondary controls:

• Clear search.
• Show all choices.
• Return to prior micro-step if the user needs the frame again.

Screen 4: Selected Stock Confirmation

Purpose: make the first pick intentional without looking like an investment action.

Regions:

• Selected company name and ticker.
• Availability status.
• Primary "Make fantasy pick" action.
• Pick-not-trade copy.
• Local/mock data label.
• Recovery action to choose another stock.

Primary control:

• Make fantasy pick.

Secondary controls:

• Choose another stock.
• View short explanation of data label if needed.

Blocked states:

• Duplicate/taken.
• Unavailable.
• Data unavailable.
• Not user's turn.

Screen 5: First Pick Recorded And Board Preview

Purpose: prove the guided sequence led to a real game move.

Regions:

• Success message naming the selected company as a fantasy pick.
• User's first draft slot filled.
• Compact participant/turn strip.
• Bot pick pending or recorded.
• Remaining slots or next-turn indicator.
• Trust and data label repeated unobtrusively.

Primary control:

• Continue draft or watch next bot pick, depending on later UI branch choice.

Secondary controls:

• Restart quick draft only if prototype scope supports restart.

Key Components And Controls

• Micro-step progress indicator or compact step header.
• Game-frame panel.
• Trust boundary line.
• Data label pill or text line.
• Search input supporting company name and ticker.
• Suggested recognizable stock choices.
• Stock result cards or rows.
• Availability badge: available, taken, unavailable, data issue.
• Inline helper copy for valid game picks.
• Selected-stock confirmation panel.
• Primary "Make fantasy pick" button.
• "Choose another stock" recovery action.
• No-results recovery block.
• First-pick success message.
• Compact draft-board preview.

All controls use game language:

• Use: pick, draft, game pick, choose, turn, board, first move.
• Avoid: buy, sell, trade, order, position, portfolio, recommendation, advice, profit, prize.

The progress indicator must not imply a long setup flow. If used, it should show only the current micro-flow to first pick, not the whole product.

Button And Link Behavior

• "Start quick draft" triggers StartQuickDraft and prepares the local draft session.
• "Continue" from the game frame advances to chooser entry without account creation.
• Search triggers SearchStockUniverse while preserving browse recovery.
• Suggested choices and browse rows come from BrowseStockUniverse.
• Selecting an available choice opens selected-stock confirmation.
• "Make fantasy pick" triggers MakeStockPick.
• Disabled "Make fantasy pick" displays the validation reason and next action.
• "Choose another stock" triggers ChooseAnotherStock and returns to chooser.
• "Show all choices" clears search and shows the recognizable local/mock universe.
• "How it works" expands inline and never routes to a separate full education page.
• Board continuation appears after FirstPickRecorded; bot continuation may be automatic, queued, or simulated with visible state.

Avoid:

• Any start action that asks for sign-up, payment, brokerage, or club setup.
• Any confirmation label that sounds like a trade or recommendation.
• Any skip behavior that hides trust/data posture entirely.

Spatial Density, Sizing, And Hierarchy

Density should be comfortable and guided:

• Each micro-step should fit in a mobile first viewport when possible.
• The stock chooser can be denser than the framing step, but it should not feel like a market table.
• Copy should be short, with disclosure for extra explanation.
• The primary action should remain visible without forcing the user through long text.

Hierarchy:

1. Current micro-step goal.
2. Trust boundary and data posture.
3. Stock choice action.
4. Selected-stock validation.
5. Board continuation.

The visual feel should be closer to a friendly game setup than a compliance flow. Trust copy should be visible and plain, not oversized legal copy.

Responsive Behavior

Mobile:

• Single-column step flow.
• Step header, trust line, and primary action stack vertically.
• Chooser uses full-width rows or cards with large tap targets.
• Selected-stock confirmation appears inline or as a bottom sheet only if it preserves trust/data labels.
• Board preview follows success in the same vertical flow.

Tablet:

• Game frame and chooser can sit in adjacent regions after the first step.
• Selected-stock confirmation may appear beside the chooser.
• Keep step count and current action visible.

Desktop:

• Use a centered guided workflow or two-region layout.
• Avoid expanding into a marketing hero, finance dashboard, or full tutorial.
• Board preview can appear beside or below success after the pick is recorded.

All breakpoints:

• Preserve 44px minimum touch targets.
• Keep data labels and disabled reasons visible.
• Do not require horizontal scrolling.
• Do not let the step indicator crowd out the chooser.

Visual Tone

The tone is reassuring, game-like, and plain-spoken.

Useful cues:

• Short step headings.
• Friendly fantasy draft language.
• Clear "not a trade" framing.
• Calm trust/data labels.
• Lightweight board continuation.

Avoid:

• Legal disclaimer walls.
• Brokerage or portfolio visual patterns.
• Stock charts, price movement emphasis, gain/loss colors, or market-dashboard density.
• Prize, contest, betting, public leaderboard, or real-return cues.
• Tutorial illustrations that delay the first pick without helping comprehension.

Strengths, Risks, And Failure Modes

Strengths:

• Makes the fantasy-game frame explicit before the chooser.
• Reduces trust-boundary ambiguity for cautious first-time users.
• Supports users who need a little help without requiring full concept education.
• Creates a clear comparison against the faster search-first and browse-first branches.
• Makes the first-pick success feel earned and understood.

Risks:

• Extra steps may slow confident users.
• The guided sequence can accidentally become a tutorial wall.
• Overemphasized trust copy can make the product feel risky or legalistic.
• If the chooser is too late, first value suffers.
• If skip behavior is too prominent, the variation collapses into a search/browse path without testing the guidance thesis.

Failure modes:

• User abandons before reaching the chooser.
• User remembers the explanation but still does not know what to pick.
• The selected-stock confirmation still resembles an investment action.
• The board preview feels disconnected from the guided setup.
• The micro-step progress indicator implies a longer setup than actually exists.

Implementation Complexity

Rough complexity: medium.

Drivers:

• Requires the same local/mock stock universe, validation, and board preview as sibling variations.
• Adds micro-step state and optional local completion/resume behavior.
• Requires careful copy discipline to keep guidance short and trust copy non-alarming.
• Does not require accounts, external APIs, production market data, payments, brokerage, notification permissions, or multi-user backend.

Relative to siblings:

• More sequencing and copy complexity than Search-To-Pick Sprint.
• More concept framing than Recognizable Watchlist Browse.
• Less social-motivation complexity than Challenge Prompt Entry.
• Less board-system exposure before the first pick than Board-First Preview.

Primary implementation risks:

• Step state and skip/resume rules becoming more complicated than the first prototype needs.
• Guidance making the flow feel slower without materially improving comprehension.
• Trust and data labels becoming either too hidden or too dominant.

What UI Review Should Validate First

The next $ui-interview guided-micro-onboarding pass should validate:

• Whether the micro-steps feel fast enough for first-pick speed.
• Whether users understand the action is a fantasy game pick before choosing.
• Whether trust and data-label copy is visible without feeling alarming or legalistic.
• Whether the chooser appears soon enough.
• Whether skip or resume behavior is needed, and if so, whether it preserves the trust boundary.
• Whether first-pick success naturally transitions to draft-board continuation.

User Signal That Makes This Branch Ready For UI Interview

This branch is ready for $ui-interview when reviewers agree that its thesis is worth seeing visually:

• A guided comprehension path is meaningfully distinct from search-first and browse-first paths.
• The parent first-pick-speed boundary is preserved.
• Guidance is short enough that it can still compete on speed.
• Trust, data-label, and pick-not-trade constraints are explicit.
• Recovery states are concrete enough to guide UI screen design.

Future Experiment Route

Potential route after UI approval only: /experiments/guided-micro-onboarding.

No prototype buildout, implementation route, or shared production infrastructure should be created from this UX spec alone. It must first pass whole-set UX variation alignment and then route through $ui-interview guided-micro-onboarding.

This variation differs from siblings by making the entry moment a market-take challenge. Search and browse remain available, but they serve the prompt: choose the company that answers the challenge.

The branch does not add actual invite management, public contests, prize pools, club dashboards, creator marketplace mechanics, or production share links. Any social payoff is framed as downstream preview only until the replay/share/invite branch owns it.

Page And Flow Changes

The first-pick path is organized around a challenge prompt:

1. Challenge Start

- The user sees a concise prompt that turns the first pick into an answer.

- The prompt can be generic, friend-link contextual, group-chat contextual, or campus-club contextual.

- Trust copy sits directly under the challenge so competition does not imply money, prizes, brokerage, advice, or betting.

1. Challenge-Framed Stock Choice

- Search and browse choices are labeled as ways to answer the prompt.

- Company names and tickers are visible, but challenge language remains dominant.

- Local/mock/prototype-only data posture is visible near the chooser.

1. Selected Answer Confirmation

- Selecting a stock creates an "answer preview" rather than a finance-style stock detail.

- The primary action records the stock as a fantasy pick.

- Pick-not-trade copy appears next to the action.

1. First Pick Recorded And Board Preview

- Success confirms the challenge answer became the user's first fantasy pick.

- The board preview shows the picked company in the user's first slot.

- A small continuation cue can say the draft will compare picks later, without promising real returns, prizes, or advice.

Progression Model

The user advances through a motivation-led progression:

StartQuickDraft with challenge entry context -> BrowseStockUniverse or SearchStockUniverse -> selected StockChoice as challenge answer -> MakeStockPick -> FirstPickRecorded -> GetDraftBoardPreview -> AdvanceTurnAfterFirstPick.

Progression differences from siblings:

• The first meaningful interaction is accepting or answering a challenge prompt.
• The prompt supplies motivation before the stock chooser appears.
• Search and browse are parallel ways to answer the challenge, not separate paths.
• The selected-stock confirmation reads like "lock this game pick" rather than "review this stock."
• Board preview appears after the pick is recorded and reinforces that the answer counted in a draft.

Primary completion criterion:

• The user sees that their market-take answer became a no-money fantasy game pick and can continue into the draft board without needing invite, account, or share setup.

Onboarding And Activation Model

Onboarding is prompt-led and lightweight:

• Challenge line: "Which company would you draft first?"
• Context line: "Make one fantasy stock pick, then see how the draft plays out."
• Trust boundary: "No money, no prizes, no brokerage, no investment advice."
• Data label: "Prototype stock list: local/mock data for gameplay."

Activation occurs when:

• The user understands the first pick is an answer to a game challenge.
• The user chooses an available company by recognition, company search, or ticker search.
• The pick is validated and recorded.
• The board preview shows the answer in the user's first draft slot.

The onboarding should not explain full scoring, equal-dollar standings, share mechanics, invite flows, or league setup. It should create enough motivation to make the first pick.

Typical Workflow Sequence

1. User lands from a direct visit, friend-link-like context, group-chat prompt, or generic challenge start.
2. System displays a short challenge prompt and trust boundary.
3. User starts or accepts the quick draft without account creation.
4. System prepares a local DraftSession, participants, active user turn, StockUniverse, TrustBoundary, and DataLabel.
5. System shows a stock chooser framed as "answer the challenge."
6. User searches by company/ticker or browses suggested recognizable choices.
7. User selects an available StockChoice.
8. System shows selected answer confirmation with company, ticker, availability, data label, and pick-not-trade copy.
9. User confirms the fantasy pick.
10. System enters validating_first_pick.
11. If allowed, system records FirstPickRecorded, marks the stock taken, and completes the user's first turn.
12. System advances to board preview and queues or records compact bot continuation.
13. User sees the challenge answer recorded as the first pick and the draft continuing.

Sharing, Collaboration, And Permissions Model

This variation is social-motivation-first but solo-execution-first.

Allowed before first pick:

• Generic challenge copy.
• Optional contextual label such as "Friend challenge" or "Group chat take" when supplied by entry context.
• A preview that the result may be replayed or shared later.

Not allowed before first pick:

• Invite forms.
• Contact import.
• Account creation.
• Club setup.
• Public contest entry.
• Payment, entry fee, prize, wager, or brokerage connection.
• Permission prompts for notifications, contacts, or social accounts.

Permissions:

• No account.
• No group role model.
• No organizer controls.
• No public leaderboard or prize eligibility.
• No brokerage or payment permissions.

The collaboration model is deferred: the user is making a solo first pick that can later support a social result or invite branch after the board/standings proof exists.

Return-Use And Notification Model

Return-use is local and challenge-context aware:

• If local state contains an incomplete challenge prompt draft, return to the chooser with the prompt preserved.
• If a selected answer exists but is not recorded, restore the selected answer confirmation when local state exists.
• If the first pick was recorded, return to the board preview with the challenge prompt summarized.
• If local state is unavailable, restart with clear prototype-state copy.

No email, push, SMS, reminder, activity feed, friend notification, or challenge-expiration model belongs in this variation.

The product should not nag users who abandon a challenge. Recovery is a clear local resume or restart, not a social pressure loop.

Failure Recovery And Abandoned-Workflow Behavior

Challenge Feels Like Betting Or Prize Play

Symptom: the user interprets competitive language as gambling, a contest, or a cash-prize challenge.

Recovery:

• Keep no-money and no-prize copy directly under the prompt.
• Use "fantasy game pick" and "draft" language.
• Avoid "wager", "win cash", "profit", "stakes", "entry", "contest", or "prize" copy.
• Keep any later social payoff framed as replay/share, not reward.

Challenge Feels Like Investment Advice

Symptom: the prompt sounds like it is asking the user what to buy, sell, hold, or recommend.

Recovery:

• Phrase the challenge as "draft first" or "make a fantasy pick."
• Repeat that the pick is not a trade, recommendation, brokerage action, or investment advice.
• Avoid price targets, return promises, rankings, ratings, or "best stock" wording.

User Has No Challenge Answer

Symptom: the user likes the prompt but does not know what company to choose.

Recovery:

• Offer recognizable company suggestions.
• Let the user browse the local/mock stock pool.
• Copy: "Pick any available company from the game list to answer the prompt."

No Search Results

Symptom: user searches a company, nickname, or ticker that is not in the local/mock universe.

Recovery:

• Explain that the prototype uses a limited local/mock stock list.
• Preserve the challenge prompt and show available alternatives.
• Copy: "Not in this prototype list yet. Choose another game stock for this challenge."

Duplicate Or Taken Stock

Symptom: user selects a stock already taken by the user or bot.

Recovery:

• Show taken state as a draft rule, not a system failure.
• Message: "Already picked in this draft. Choose another game pick for your answer."
• Keep the user in the challenge-framed chooser with available alternatives.

Stock Unavailable

Symptom: a stock appears but cannot be picked.

Recovery:

• Disable the primary pick action.
• Explain the local game-list limitation.
• Offer "Choose another answer" with available choices.

Data Unavailable

Symptom: local/mock stock universe cannot load.

Recovery:

• Stop before chooser or confirmation.
• Show local/prototype data posture and retry action.
• Avoid showing unlabeled stock choices or stale challenge answers.

Not User's Turn

Symptom: bot continuation or turn state blocks user action.

Recovery:

• Explain that the user's challenge answer has already been recorded or that the current turn belongs to the bot.
• Disable pick action until a user turn is active.
• Keep board preview visible if the first pick has been recorded.

Abandonment

If the user leaves before selecting a stock:

• Returning resumes the challenge prompt and chooser when local state exists.
• If local state is unavailable, restart with the same generic challenge start.

If the user leaves after selecting but before confirmation:

• Returning can restore the selected answer confirmation when local state exists.
• If unavailable, restart with clear local-state copy and the challenge prompt.

If the user leaves after making the first pick:

• Returning shows the recorded pick and board preview when local state exists.
• If unavailable, restart with a prototype-state explanation.

Navigation Model

Primary navigation is prompt-to-pick:

• Challenge start.
• Challenge-framed chooser.
• Selected answer confirmation.
• First-pick success and draft-board preview.

Secondary navigation:

• Search by company or ticker.
• Browse recognizable choices.
• Choose another answer after selected confirmation or blocked validation.
• Compact "How this works" disclosure.
• Restart quick draft only for local-state or data-loading failures.

The variation should not introduce persistent social navigation, league tabs, invite flows, public challenge feeds, organizer dashboards, or full share-result screens before first pick.

Screen-By-Screen Layout

Screen 1: Challenge Start

Purpose: make the user want to answer with a fantasy stock pick.

Regions:

• Challenge prompt as the dominant heading.
• Context line explaining the no-account quick draft.
• Trust boundary line near the prompt.
• Local/mock/prototype data label before stock data appears.
• Primary action to answer the challenge.
• Optional compact "How this works" disclosure.

Primary control:

• Answer with a fantasy pick.

Secondary controls:

• Browse the game stock list.
• How this works.

Screen 2: Challenge-Framed Stock Chooser

Purpose: let the user choose a company as an answer, not as a finance transaction.

Regions:

• Prompt recap.
• Search input supporting company name and ticker.
• Recognizable local/mock stock choices.
• Availability/taken/unavailable states.
• Data label close to chooser.
• Compact trust reminder near the pick action area.

Primary control:

• Select an available stock choice as the challenge answer.

Secondary controls:

• Clear search.
• Show all choices.
• Return to prompt.

Screen 3: Selected Answer Confirmation

Purpose: make the challenge answer intentional while preserving the pick-not-trade boundary.

Regions:

• Selected company name and ticker.
• Prompt-answer phrasing such as "Your answer: [company]."
• Availability status.
• Primary "Make fantasy pick" action.
• Pick-not-trade copy.
• Local/mock data label.
• Recovery action to choose another answer.

Primary control:

• Make fantasy pick.

Secondary controls:

• Choose another answer.
• View short data-label explanation if needed.

Blocked states:

• Duplicate/taken.
• Unavailable.
• Data unavailable.
• Not user's turn.

Screen 4: First Pick Recorded And Board Preview

Purpose: prove the challenge answer counted as a draft move.

Regions:

• Success message naming the selected company as the recorded fantasy pick.
• User's first draft slot filled.
• Compact participant/turn strip.
• Bot pick pending or recorded.
• Remaining slots or next-turn indicator.
• Trust and data label repeated unobtrusively.
• Optional line foreshadowing later comparison without promising returns or prizes.

Primary control:

• Continue draft or watch next bot pick, depending on later UI branch choice.

Secondary controls:

• Restart quick draft only if prototype scope supports restart.

Key Components And Controls

• Challenge prompt header.
• Entry-context label.
• Trust boundary line.
• Data label pill or text line.
• Search input supporting company name and ticker.
• Recognizable stock choice cards or rows.
• Availability badge: available, taken, unavailable, data issue.
• Selected answer confirmation panel.
• Primary "Make fantasy pick" button.
• "Choose another answer" recovery action.
• No-results recovery block.
• First-pick success message.
• Compact draft-board preview.

All controls use game and answer language:

• Use: challenge, answer, pick, fantasy pick, draft, board, turn, choose another answer.
• Avoid: buy, sell, trade, order, position, portfolio, recommendation, advice, profit, prize, wager, stake, contest entry.

The challenge prompt must not overpromise share or invite behavior. It can foreshadow social comparison, but the first-pick branch still completes at board continuation.

Button And Link Behavior

• "Answer with a fantasy pick" triggers or proceeds through StartQuickDraft and prepares the local draft session.
• Search triggers SearchStockUniverse while preserving browse recovery.
• Browse choices come from BrowseStockUniverse.
• Selecting an available choice opens selected answer confirmation.
• "Make fantasy pick" triggers MakeStockPick.
• Disabled "Make fantasy pick" displays the validation reason and next action.
• "Choose another answer" triggers ChooseAnotherStock and returns to the challenge-framed chooser.
• "Show all choices" clears search and shows the recognizable local/mock universe.
• "How this works" expands inline and never routes to a separate full concept or rules page.
• Board continuation appears after FirstPickRecorded; bot continuation may be automatic, queued, or simulated with visible state.

Avoid:

• Any entry action that asks for account, contacts, payment, brokerage, invite, or club setup.
• Any challenge button that implies betting, prize entry, financial return, or investment recommendation.
• Any share/invite call to action before the first pick is recorded.

Spatial Density, Sizing, And Hierarchy

Density should be energetic but restrained:

• The challenge prompt should dominate the start screen without becoming a marketing hero.
• The chooser should appear quickly after the prompt.
• The selected answer confirmation should be compact and action-focused.
• Social context should stay as a small motivator, not a large feed or community surface.

Hierarchy:

1. Challenge prompt and action.
2. Trust boundary and data posture.
3. Stock choice as answer.
4. Selected answer validation.
5. Board continuation.

Mobile constraints:

• The prompt, trust line, and primary action should fit in the first viewport.
• Chooser cards or rows must remain large enough for touch.
• Any contextual friend/group label should not crowd out the search/browse controls.

Desktop constraints:

• Use a focused prompt-plus-chooser layout.
• Avoid expanding into public contest, social feed, or finance dashboard composition.
• Board preview can appear beside or below success after the pick is recorded.

Responsive Behavior

Mobile

• Single-column prompt-to-chooser flow.
• Challenge prompt, trust line, and primary action stack vertically.
• Chooser uses full-width rows or cards.
• Selected answer confirmation appears inline or as a bottom sheet only if it preserves trust/data labels.
• Board preview follows success in the same vertical flow.

Tablet

• Prompt recap and chooser can sit in adjacent regions after the first screen.
• Selected answer confirmation may appear beside the chooser.
• Keep challenge context visible without consuming the majority of the viewport.

Desktop

• Use a centered challenge surface with chooser below or beside it.
• The board preview may appear as a compact adjacent panel after success.
• Avoid public leaderboard, trading dashboard, or large social feed patterns.

All breakpoints:

• Preserve 44px minimum touch targets.
• Keep data labels and disabled reasons visible.
• Do not require horizontal scrolling.
• Keep no-money/no-prize/no-advice language close to the prompt and pick action.

Visual Tone

The tone is competitive, social, and game-like, but not speculative.

Useful cues:

• Challenge prompt copy.
• Friendly group-chat or fantasy-draft language.
• Compact contextual labels such as "Market take" or "Friend challenge" when supplied.
• Clear "not a trade" framing.
• Lightweight draft-board continuation.

Avoid:

• Gambling, wagering, cash-prize, tournament, or entry-fee cues.
• Brokerage or portfolio visual patterns.
• Stock charts, price movement emphasis, gain/loss colors, or return promises.
• Advice-like prompts such as "What should people buy?"
• Public leaderboard or creator-contest styling before trust is established.

Strengths, Risks, And Failure Modes

Strengths:

• Gives users a motivating reason to make the first pick.
• Maps naturally to group chat, friend debates, campus-club prompts, and social sharing later.
• Differentiates Draft Stonk from neutral simulators or finance tools.
• Creates a clean bridge to the downstream replay/share/invite branch without requiring it now.
• Can make the first pick feel like an opinionated game move rather than data entry.

Risks:

• Competitive framing can accidentally imply betting, prizes, or public contests.
• Social framing can overpromise share/invite functionality outside this branch's scope.
• Challenge language can drift into investment advice if wording is imprecise.
• Users who arrive without a market take may stall unless browse suggestions are visible.
• Too much challenge copy can delay first-pick speed.

Failure modes:

• User thinks the challenge requires money, stakes, prizes, or a formal contest.
• User expects multiplayer or invite setup before first pick and is disappointed.
• The selected answer confirmation resembles an investment recommendation.
• The social prompt distracts from the stock chooser.
• Board preview feels like a dead end because the promised comparison/share payoff is not yet available.

Implementation Complexity

Rough complexity: medium.

Drivers:

• Requires the same local/mock stock universe, validation, and board preview as sibling variations.
• Adds entry-context prompt state and copy variants.
• Requires careful trust-boundary copy because competitive framing raises betting/advice confusion risk.
• May need optional challenge-context fields in local state, but does not require accounts, invites, contacts, notifications, external APIs, or production share infrastructure.

Relative to siblings:

• More social/copy complexity than Search-To-Pick Sprint.
• More motivation framing than Recognizable Watchlist Browse.
• Less step-state complexity than Guided Micro-Onboarding.
• Less board-system exposure before the first pick than Board-First Preview.

Primary implementation risks:

• Challenge context becoming an implicit product-path expansion into public contests or league operations.
• Copy and visual hierarchy implying stakes or advice.
• Social promise exceeding what the first-pick branch can deliver.

What UI Review Should Validate First

The next $ui-interview challenge-prompt-entry pass should validate:

• Whether the challenge prompt increases motivation without slowing first-pick speed too much.
• Whether users understand the action is a no-money fantasy game pick, not a bet, trade, recommendation, or contest entry.
• Whether search and browse remain obvious under challenge framing.
• Whether optional friend/group context feels useful without requiring invite setup.
• Whether selected answer confirmation avoids investment-action language.
• Whether first-pick success naturally transitions to draft-board continuation and later share/replay possibilities.

User Signal That Makes This Branch Ready For UI Interview

This branch is ready for $ui-interview when reviewers agree that its thesis is worth seeing visually:

• Social challenge framing is meaningfully distinct from search-first, browse-first, guided, and board-first paths.
• The parent first-pick-speed boundary is preserved.
• Challenge motivation does not require account, invite, prize, public contest, or league setup.
• Trust, data-label, and pick-not-trade constraints are explicit.
• Recovery states are concrete enough to guide UI screen design.

Future Experiment Route

Potential route after UI approval only: /experiments/challenge-prompt-entry.

No prototype buildout, implementation route, or shared production infrastructure should be created from this UX spec alone. It must first pass whole-set UX variation alignment and then route through $ui-interview challenge-prompt-entry.

This variation differs from siblings by making the draft board visible before the first stock choice is confirmed. Search-To-Pick Sprint delays the board until success, Recognizable Watchlist Browse leads with the stock pool, Guided Micro-Onboarding leads with explanation, and Challenge Prompt Entry leads with motivation. Board-First Preview leads with turn context and the empty game slot the user is about to fill.

The branch does not add full standings, equal-dollar scoring comprehension, live performance charts, league management, public leaderboards, prize language, or multiplayer invitation flows. The board is a compact first-pick frame, not the full draft product.

Page And Flow Changes

The first-pick path is organized around a compact board frame:

1. Quick Draft Board Preview

- The user sees a small draft board with the user's first slot empty and active.

- A current-turn indicator makes the first task explicit: make your first fantasy stock pick.

- Trust copy and data posture sit near the board header so the board does not look like a portfolio, brokerage screen, or leaderboard.

1. Embedded Active-Turn Chooser

- The chooser is presented as the action for the active turn.

- Search and recognizable browse options are available inside or directly below the active slot.

- Available/taken/unavailable states appear as draft rules, not financial availability or trading restrictions.

1. Slot-Fill Confirmation

- Selecting a stock shows a preview linked to the empty board slot.

- The primary action records the stock as a fantasy pick.

- Pick-not-trade copy appears beside the action and is repeated in the selected preview.

1. First Pick Recorded And Board Continuation

- On success, the empty slot fills with the selected company/ticker.

- The current-turn indicator advances to compact bot continuation or pending next move.

- The user sees the first pick counted in place, making the continuation feel natural.

Progression Model

The user advances through a board-led progression:

StartQuickDraft -> GetDraftStartSummary -> GetDraftBoardPreview -> BrowseStockUniverse or SearchStockUniverse inside active turn -> selected StockChoice -> MakeStockPick -> FirstPickRecorded -> updated GetDraftBoardPreview -> AdvanceTurnAfterFirstPick -> optional RecordBotPickContinuation.

Progression differences from siblings:

• The board preview appears before the user chooses a stock.
• The first task is visually anchored to the user's empty draft slot.
• Search and browse are subordinate to the active turn, not the whole surface.
• Success is shown by filling the board slot in place, not by moving to a separate success screen first.
• Bot continuation is easier to foreshadow because the board already shows participants and turn order.

Primary completion criterion:

• The user sees that their first available company became a fantasy game pick in the draft board's active slot, and understands the draft can continue without mistaking the board for investing, betting, prizes, or portfolio tracking.

Onboarding And Activation Model

Onboarding is board-native:

• Board header: "Quick fantasy stock draft"
• Current turn: "Your turn: make pick 1"
• Active slot label: "Empty game pick"
• Trust boundary: "No money, no prizes, no brokerage, no investment advice."
• Data label: "Prototype stock list: local/mock data for gameplay."
• Chooser prompt: "Choose a company for this draft slot."

Activation occurs when:

• The user understands the empty slot is a game move to fill.
• The user finds an available stock through company/ticker search or recognizable browsing.
• The selected stock is validated and recorded.
• The board updates in place with the pick in the user's first slot.
• The turn state advances enough to prove the pick counted and the compact bot draft can continue.

The onboarding should not explain full scoring, equal-dollar standings, league setup, player management, or replay/share payoff. It should make the first turn self-evident.

Typical Workflow Sequence

1. User lands on or starts a quick draft.
2. System creates or prepares a local DraftSession with user and compact bot participants.
3. System displays a small board preview: participants, first round slots, user's active empty slot, and current turn.
4. System displays trust boundary and local/mock/prototype data label near the board and chooser.
5. User chooses the active slot action.
6. System shows search and recognizable stock choices inside the active turn area.
7. User searches by company/ticker or browses suggested recognizable choices.
8. User selects an available StockChoice.
9. System shows a selected-stock preview attached to the empty board slot.
10. User confirms the fantasy pick.
11. System enters validating_first_pick.
12. If allowed, system records FirstPickRecorded, marks the stock taken, and completes the user's first turn.
13. System fills the board slot with the selected company/ticker.
14. System advances turn state and queues or records compact bot continuation.
15. User sees the first pick counted and understands how the draft proceeds.

Sharing, Collaboration, And Permissions Model

This variation uses a board to imply turn structure, not live collaboration.

Allowed before first pick:

• Compact user and bot participant labels.
• Turn order preview.
• Empty first-round slots.
• Taken-state preview once a pick is recorded.

Not allowed before first pick:

• Invite forms.
• Contact import.
• Account creation.
• Real multiplayer presence.
• Public leaderboard.
• Prize eligibility.
• Club setup.
• Brokerage or payment permissions.

Permissions:

• No account.
• No role management.
• No group setup.
• No public contest entry.
• No notification permissions.
• No brokerage or payment permissions.

The collaboration model is simulated/local for the first-pick branch. The board can show a bot or placeholder opponent only to make draft continuation legible.

Return-Use And Notification Model

Return-use is board-state aware:

• If local state contains an unfilled active first slot, return to the board preview with the chooser ready.
• If a selected stock exists but is not recorded, restore the selected preview attached to the empty slot.
• If the first pick was recorded, return to the updated board preview with the user's first slot filled.
• If compact bot continuation was recorded locally, show it as game continuation.
• If local state is unavailable, restart with clear prototype-state copy.

No email, push, SMS, reminder, digest, activity feed, or friend notification belongs in this variation. The board itself is the return surface.

Failure Recovery And Abandoned-Workflow Behavior

Board Feels Too Heavy Before First Pick

Symptom: the user sees participant rows, slots, or turn order as unnecessary setup before choosing.

Recovery:

• Keep the board to one compact first-round preview.
• Show only the current slot, one or two bot slots, and turn status.
• Collapse secondary board detail on mobile.
• Keep the chooser immediately visible.
• Avoid full standings, historical picks, tables, or league controls.

Board Looks Like A Portfolio Or Trading Dashboard

Symptom: the user reads the board as holdings, positions, performance, or account data.

Recovery:

• Use "draft", "turn", "slot", "pick", and "game" language.
• Avoid shares, quantities, balances, gains/losses, P&L, charts, orders, portfolio value, and price-movement emphasis.
• Keep no-brokerage and no-advice copy visible near the board header.
• Display stock identity as company/ticker game labels, not as live market instruments.

Board Looks Like Betting Or Prizes

Symptom: the user interprets participants, slots, or future standings as a contest with stakes.

Recovery:

• Keep no-money and no-prize copy next to the board.
• Avoid prize, wager, entry, pot, cash, payout, odds, and leaderboard hype.
• Defer public ranking or share payoff to later branches.
• Use compact bot continuation rather than competitive prize framing.

User Does Not Know What To Pick

Symptom: the board makes the task clear, but the user still has no stock idea.

Recovery:

• Show recognizable suggested companies inside the active turn.
• Provide browse-first choices and a search escape hatch.
• Copy: "Pick any available company from the game list for this slot."
• Avoid requiring ticker knowledge.

No Search Results

Symptom: user searches a company, nickname, or ticker not present in the local/mock universe.

Recovery:

• Explain that the prototype uses a limited local/mock stock list.
• Keep the active board slot visible so the user's goal remains clear.
• Offer suggested available alternatives.
• Preserve the search term and provide "Browse available game stocks."

Duplicate Or Taken Stock

Symptom: user selects a stock already taken by the user or bot.

Recovery:

• Show the stock as taken on the board or chooser.
• Disable the pick action.
• Message: "Already picked in this draft. Choose another game pick."
• Keep the user's active slot open and return focus to available choices.

Stock Unavailable

Symptom: a stock appears in the universe but cannot be picked.

Recovery:

• Mark the choice unavailable in the chooser and selected preview.
• Explain the rule in game terms: "Not available for this local draft."
• Provide "Choose another stock."
• Keep the active slot unchanged.

Data Unavailable

Symptom: local/mock stock choices or board state cannot load.

Recovery:

• Show a prototype data message.
• Avoid implying live-market outage or brokerage failure.
• Provide retry and restart quick draft actions.
• Keep trust copy visible.

Not User's Turn

Symptom: local state indicates the turn advanced or the board is temporarily on a bot continuation state.

Recovery:

• Show current-turn state clearly.
• Disable pick action until the user turn is active.
• If this is caused by stale state, provide "Return to your pick" or restart local draft.

Abandoned Before Pick

Symptom: user leaves after seeing the board but before recording a pick.

Recovery:

• Restore the board preview with the active empty slot if local state exists.
• Preserve selected stock preview when available.
• If no local state exists, restart with "Start quick draft" and prototype-state copy.

Abandoned After Pick

Symptom: user leaves after first pick is recorded.

Recovery:

• Return to board preview with the pick filled in.
• Show bot continuation state if recorded.
• Make continuation available without account creation.

Navigation Model

Navigation is board-contained and shallow:

• Entry lands directly on the quick draft board preview.
• The board, active turn chooser, selected preview, validation result, and success state live in one flow.
• Search and browse are local panels or inline sections inside the active-turn area.
• Recovery actions return to the active slot or chooser, not to separate error routes.
• Post-success continuation stays on the board preview.

The variation should not introduce persistent side navigation, full dashboard tabs, standings tabs, account routes, league-management routes, or public leaderboard routes before first pick.

Screen-By-Screen Layout

Screen 1: Quick Draft Board Preview

Purpose:

• Show that this is a game draft and the user has an active slot to fill.

Required content:

• Compact product/game title.
• Trust boundary line.
• Data label.
• Current-turn indicator.
• First-round board preview.
• User active empty slot.
• One or two bot/placeholder slots.
• Primary active-slot action to choose a stock.
• Search or browse entry visible without scrolling on typical mobile viewports when feasible.

Behavior:

• StartQuickDraft creates or restores a DraftSession.
• GetDraftStartSummary and GetDraftBoardPreview populate the preview.
• If the board cannot load, show local/prototype state recovery rather than a finance-system error.

Screen 2: Active Turn Chooser

Purpose:

• Let the user fill the active board slot with an available stock.

Required content:

• Active slot context.
• Search input for company/ticker.
• Recognizable suggested choices.
• Availability/taken/unavailable labels.
• Local/mock data label near stock choices.
• Inline trust reminder.

Behavior:

• BrowseStockUniverse supplies recognizable choices.
• SearchStockUniverse filters by company name, ticker, and recognizable label.
• Selecting a stock opens the selected-stock preview.
• Taken or unavailable choices remain visible with disabled pick action and recovery copy.

Screen 3: Selected Slot Preview

Purpose:

• Confirm that the selected stock will fill the user's active game slot.

Required content:

• Selected company name and ticker.
• Active board slot relationship.
• Availability status.
• Pick-not-trade copy.
• Data label.
• Primary action: "Make fantasy pick" or equivalent.
• Secondary action: choose another stock.

Behavior:

• Confirming calls MakeStockPick.
• Loading state indicates validation, not order placement.
• Validation failure returns the user to the active slot with recovery.

Screen 4: First Pick Recorded Board

Purpose:

• Show the pick counted in the board frame.

Required content:

• User first slot filled with company/ticker.
• Success message using fantasy-game language.
• Turn advanced or bot continuation state.
• Compact next action to continue the draft.
• Trust and data labels still visible.

Behavior:

• Success follows FirstPickRecorded.
• Board preview refreshes through GetDraftBoardPreview.
• AdvanceTurnAfterFirstPick and optional RecordBotPickContinuation update the board state.

Key Components And Controls

Core components:

• Compact draft board preview.
• Current-turn indicator.
• Active empty slot.
• Participant mini-rows or slot chips.
• Active-turn stock chooser.
• Search input.
• Recognizable stock choice cards or rows.
• Selected-slot preview.
• Validation result message.
• Trust boundary line.
• Data label badge.
• Compact bot continuation cue.

Controls:

• Start quick draft / restore local draft.
• Choose stock for this slot.
• Search company or ticker.
• Select stock choice.
• Make fantasy pick.
• Choose another stock.
• Browse available game stocks.
• Retry local stock list.
• Restart local draft.
• Continue draft after first pick.

Language guardrails:

• Use: pick, draft, game pick, slot, turn, board, choose, available, taken.
• Avoid: buy, sell, trade, order, position, portfolio, profit, loss, wager, prize, cash, advice, recommendation.

Button And Link Behavior

Primary actions:

• "Start quick draft" creates or restores DraftSession.
• "Choose stock for this slot" focuses the active-turn chooser.
• "Make fantasy pick" calls MakeStockPick for the selected StockChoice.
• "Continue draft" advances from first-pick success into the compact board continuation.

Secondary actions:

• "Choose another stock" clears selected preview and returns to active-turn chooser.
• "Browse available game stocks" opens or scrolls to the recognizable choice list.
• "Retry" reloads local/mock stock choices or board state.
• "Restart local draft" discards local prototype state only after confirmation.

Links:

• "How this works" may expand a compact inline explanation.
• Data label help may expand inline.
• No external brokerage, account, payment, invite, public contest, or leaderboard links are present.

Disabled/loading behavior:

• While validating, the primary button uses game copy such as "Recording pick..." rather than finance copy.
• Taken/unavailable states disable the primary pick action and explain the next action.
• Not-user-turn state disables pick action until turn state returns or local recovery is chosen.

Spatial Density, Sizing, And Hierarchy

Density should be compact but not dashboard-dense.

Hierarchy:

1. Current turn and active empty slot.
2. Chooser or selected preview attached to the slot.
3. Trust boundary and data label.
4. Secondary bot/participant preview.
5. Recovery and explanation.

Sizing guidance:

• Board preview should fit in the first viewport with the active action on mobile when feasible.
• Active slot should be visually stronger than bot slots.
• Stock choices should be large enough for touch selection.
• Trust and data labels should remain visible but visually quieter than the active turn.
• Avoid dense financial tables, sparkline grids, or ticker-tape layouts.

The board should feel like a small game state, not a full app shell.

Responsive Behavior

Mobile <=640px

• Stack board header, active slot, chooser, and selected preview vertically.
• Show only the most relevant board slots at first: user active slot plus compact bot/next cue.
• Collapse secondary participant details behind small labels or inline chips.
• Keep the active chooser and trust/data labels visible near the first action.
• Avoid horizontal board layouts that force side scrolling.

Tablet <=1024px

• Use a two-zone layout: compact board preview above or beside the chooser.
• Active slot and chooser can sit in the same card/section.
• Bot continuation may appear in a secondary row.
• Search and recognizable choices can use a two-column grid if space allows.

Desktop >1024px

• Board preview can sit beside the chooser, with the active slot visually connected to the selection panel.
• Keep board width constrained so it does not become a dashboard.
• Use whitespace to separate game state from stock choices.
• Do not introduce persistent app navigation or financial-dashboard panels.

Visual Tone

Tone should be game-board clear, compact, and trustworthy.

Suitable direction:

• Familiar fantasy draft board cues.
• Turn and slot language.
• Light game-state affordances.
• Recognizable stock identity through company/ticker labels.
• Compact trust and data labels.

Avoid:

• Brokerage dashboards.
• Portfolio holdings tables.
• Stock chart dominance.
• Leaderboard hype before trust is established.
• Prize, betting, wager, cash, or odds styling.
• Heavy legal disclaimer walls.

Strengths

• Makes the fantasy draft frame visible before the first pick.
• Shows the exact destination of the first pick, reducing "what happens next?" uncertainty.
• Uses game structure to distinguish the product from trading, portfolio, or advice tools.
• Makes duplicate/taken states easier to explain as draft rules.
• Creates a strong contrast against search-first, browse-first, guided, and challenge-led variations.
• Can still run with local/mock data and no account.

Risks And Failure Modes

• Board chrome may slow the fastest first-pick users.
• The board may confuse users who do not know fantasy drafts.
• Mobile layout may crowd the stock chooser, trust boundary, or data label.
• If the board resembles standings or leaderboards, it can create betting/prize confusion.
• If company/ticker cards sit inside a board without clear data labels, users may over-read the choices as live investment instruments.
• If bot continuation appears too early or too busy, the user may focus on system mechanics before making a pick.

Implementation Complexity

Complexity: medium.

Reasons:

• Requires the same local/mock stock universe, validation, and board preview as sibling variations.
• Adds pre-pick board state and stronger turn/slot visualization before success.
• Needs careful responsive behavior so the board does not overwhelm mobile.
• Requires precise copy and visual hierarchy to avoid finance, betting, or leaderboard interpretations.

Primary implementation risks:

• Board state and chooser state becoming visually disconnected.
• Overbuilding the board into standings, league, or dashboard scope.
• Making unavailable/taken states look like trading restrictions rather than game rules.
• Hiding trust/data labels below the fold.

What UI Review Should Validate First

The next $ui-interview board-first-preview pass should validate:

• Whether the board preview before selection improves game comprehension enough to justify added chrome.
• Whether users understand the active empty slot as the first pick task.
• Whether the chooser feels naturally embedded in the current turn.
• Whether no-money, no-prize, no-brokerage, no-advice, and data labels remain visible.
• Whether the board avoids portfolio, trading, betting, prize, and leaderboard cues.
• Whether mobile layout preserves first-pick speed.
• Whether filling the slot after success makes continuation feel natural.

User Signal That Makes This Branch Ready For UI Interview

This branch is ready for $ui-interview when reviewers agree that its thesis is worth seeing visually:

• Board-first game framing is a plausible way to improve comprehension without blocking first pick.
• The active slot, chooser, and selected preview can be specified clearly enough for a UI proposal.
• The board can stay compact and first-pick scoped.
• Trust and data-label requirements are explicit enough to design.
• The variation remains meaningfully distinct from search-first, browse-first, guided, and challenge-led siblings.

Future Experiment Route

Potential route after UI approval only: /experiments/board-first-preview.

No prototype buildout, implementation route, or shared production infrastructure should be created from this UX spec alone. It must first pass whole-set UX variation alignment and then route through $ui-interview board-first-preview.