ui-interviewconfirmedprototype tiersearch-to-pick-sprint

UI Interview — Search-To-Pick Sprint

Approved. Proposed UI for the fastest valid first-pick path of Draft Stonk (fantasy football, but for stocks). Final compiled YAML was provided and the canonical UI branch packet has been written to design/ui-search-to-pick-sprint.md. This page renders the complete UI branch packet, an interactive 4-state mockup, and the approval gates that were satisfied.

Command: $ui-interview search-to-pick-sprint · Parent branch: first-pick-speed · Canonical packet: design/ui-search-to-pick-sprint.md · Interview log: design/ui-search-to-pick-sprint-interview.md · Page: alignment/ui-interview-search-to-pick-sprint.html

Interview provenance: live-ui-interviewStage 0 interrogation r1: completeBranch decision: approve

Interview Stage

This is a full UI-mode branch review of one UX variation (search-to-pick-sprint) for one user flow (first-pick-speed). Stage-0 interrogation (round 1) ran to completion with the user: the UI Assumptions Manifest was confirmed and all five open UI decisions were answered. This is not requirements-only mode and not an evidence-synthesis review — provenance is live-ui-interview.

Status: confirmed. Final compiled YAML was provided (assumptions all-hold · decisions reflected · visual approve · coverage complete · destination approve · branch approve · route build-ui-screens) and the canonical files were written. Next step is $build-ui-screens search-to-pick-sprint to build the visual screens on fixture data.

Scope Read

AreaResolved value
Parent product topicdraft-stonk
Parent user-flow branchfirst-pick-speed
Selected UX variationsearch-to-pick-sprint (first pending_ui_interview child)
Source UX artifactdesign/ux-variations-first-pick-speed.md
Route candidate after approval/experiments/search-to-pick-sprint
Prototype boundaryLocal/mock fixtures only. No app scaffold, auth, database, brokerage, payment, live market data, or production analytics.

Source evidence

Interactive Mockup — 4 States

Concrete enough to judge layout, hierarchy, controls, copy, and trust treatment. This is an ephemeral preview, not production code — no data is saved.

Preview only · tap a state or click inside the flow (type is simulated) ·

Draft StonkNo money · No prizes · Game picks only

State legend: S1 search-first frame → S2 recognizable rows (Available / Taken / Unavailable) → S3 pick-not-trade confirmation → S4 first pick recorded with the board preview (slot 1 filled, bots on the clock, remaining count). Full standings, scoring, and share are intentionally absent.

Gate · assumptions / confidence

Confirmed UI Assumptions Manifest

All six were confirmed in interrogation round 1 (no corrections, no flags). Re-confirm they still hold before design proceeds.

KeySourceConfirmed assumption
product-user-context[spec]Mobile-first fantasy stock draft game; this branch serves users arriving with a stock/ticker/market take in mind.
branch-and-siblings[spec]Optimize fastest valid first pick; stay comparable to browse-first, micro-onboarding, challenge-prompt, board-first siblings.
pages-and-entry[spec]One experiment route, four screen states: search start, results, selected preview, recorded + board.
nav-and-hierarchy[research]Search + pick confirmation dominate the first viewport; trust/data labels near the action; longer explanation collapsed.
components-controls-states[spec]Search, rows, availability badges, selected preview, "Make fantasy pick", validation, browse fallback, data label, trust line, board preview; nine+ states.
visual-and-stack[codebase]No app scaffold; propose mobile-first game-like web on local/mock fixtures; avoid brokerage dashboards / chart dominance / account chrome / marketing structure.

Do the six confirmed assumptions still hold as the basis for this UI design?

Gate · candidate / verdict

Confirmed Open UI Decisions

#DecisionConfirmed answer
1First viewport priorityOne compact game-frame line; search input immediately below in the first viewport. No hero/onboarding/dashboard first.
2Trust copy placementShort trust line near title/search; repeat pick-not-trade inside the selected-stock preview; longer explanation collapsed behind "How it works".
3Search result shapeTouch-friendly rows (mobile) / compact rows (desktop); company name first, ticker second, availability badge, subtle local/mock label, no charts.
4Board preview timingCompact board preview immediately after success: slot 1 filled, next bot turn state, remaining draft length. No full standings/share.
5Visual tone guardrailsEmphasize draft turns, game picks, recognizable company identity; avoid candlestick charts, buy/sell colors, portfolio terms, cash-prize hype, legal walls.

Are the five resolved UI decisions correctly reflected in the mockup above?

Gate · candidate / verdict

Proposed Visual Direction

No brand palette exists in the repo (no colors/mascot/logo defined). This is a proposed starting direction — an open decision, not a locked constraint.

Approve the proposed visual direction (draft console + monogram tiles + no buy/sell colors)?

Route Map, Pages & Page-By-Page Anatomy

Single route /experiments/search-to-pick-sprint — one continuous surface advancing through four screen states. No global shell: only a wordmark + trust chip; no sidebar, tab bar, marketing header/footer, or account chrome.

S1 — Quick Draft Search Start

Regions: wordmark + trust chip → game-frame headline → supporting line → dominant search input → data label → empty-state helper (2 example chips) → collapsed "How it works". Primary control: search input (desktop autofocus; mobile not autofocused). Copy: headline "Draft a stock like a fantasy pick."; placeholder "Search a company or ticker"; data label "Prototype stock list — local/mock data for gameplay."

S2 — Search Results (same surface)

Results render inline as the user types. Canonical row (defined once, repeated): monogram tile · company name (primary) · ticker (secondary) · availability badge. No price, no chart. Variants: Available (teal, tappable), Taken (muted, strikethrough, disabled), Unavailable (muted, disabled), Data issue (retry). No-results recovery lives in the same region with a preserved term + browse fallback.

S3 — Selected-Stock Preview

Regions: back-to-results → selected company (monogram + name + ticker) → availability → pick-not-trade line → data label → primary "Make fantasy pick" → "Choose another stock". Blocked states replace the primary action with a reason + next action: duplicate/taken, unavailable, data-unavailable, not-your-turn. Copy: "You're making a game pick — not a trade or recommendation."

S4 — First Pick Recorded + Board Preview

Regions: success ("First pick recorded") → draft board preview: order strip with user slot 1 filled, next-turn indicator (bots on the clock), remaining draft length → repeated trust + data label (unobtrusive) → continue. Excluded here: full standings, equal-dollar scoring, share/invite.

Parent flow, siblings & coordination

Components, Controls & States

Component inventory

Search input (name + ticker) · ticker monogram tile · result row (4 variants) · availability badge · selected-stock preview card · primary game-pick button · validation/blocked message · browse-fallback button · "How it works" disclosure · trust chip + pick-not-trade line · data-posture label · draft-board preview (order strip + turn indicator + remaining count) · success confirmation.

Control behavior

Interaction states (canonical)

empty search · loading local/mock list · results shown · no results · row hover/focus/active · selected · duplicate/taken · unavailable · data-unavailable (retry) · validating first pick · success · not-your-turn · bot continuation pending/recorded.

Link inventory

In-branch only. No external, auth, account, or share links. Disclosure and browse-fallback are state switches, not routes.

Responsive & Accessibility

Responsive

Accessibility (baseline, not optional)

Prototype-First & Per-Screen Batch Plan

Prototype-first boundary

Per-screen batch plan (for /build-ui-screens)

  1. Batch 1 — Search Start (S1): shell strip, trust chip, game frame, search input, data label, empty-state helper, "How it works".
  2. Batch 2 — Results (S2): canonical row + 4 variants, results list, clear-search, no-results recovery, browse-fallback entry.
  3. Batch 3 — Selected Preview (S3): selected card, pick-not-trade line, primary pick, blocked variants, "Choose another stock".
  4. Batch 4 — Recorded + Board (S4): success, order strip with filled slot 1, turn indicator, remaining count, bot-continuation state.

Minimum-UI stop: after Batch 4 the first clickable journey is walkable end-to-end on fixtures.

Open Questions, Risks & Non-Goals

Open questions

Risks & mitigations

Non-goals

No standings/equal-dollar scoring; no share/invite; no account/auth; no real market data or prices-as-signal; no brokerage/portfolio/P&L UI; no candlestick charts; no legal-disclaimer wall; no persistent global nav; no sibling browse-variation surface.

Gate · coverage checkpoint

Coverage Checkpoint

Pages (4 states) · components (13) · controls (7) · states (13) · responsive (3 breakpoints) · accessibility (keyboard, color-blind, SR labels, reduced motion) · recovery (no-results, taken, unavailable, data-unavailable, not-your-turn). Is anything missing before the canonical spec is written?

Is the page/state/control/responsive/recovery coverage complete?

Gate · artifact destination & proposed file changes

Artifact Destination & Proposed File Changes

On final approval, the following canonical writes happen (destination and mutation scope are the same path set here, so they are combined):

PathAction
design/ui-search-to-pick-sprint.mdWrite UI branch packet (canonical).
design/ui-search-to-pick-sprint-interview.mdWrite interview log.
design/flow-tree-draft-stonk.yamlAdd ui_experiments[] entry + decisions[] record under search-to-pick-sprint.
research/_working/preliminary-ui-interview-research.mdArchive to docs/history/archive/…, then remove.
alignment/ui-interview-search-to-pick-sprint.htmlConvert reviewconfirmed.
alignment/index.htmlAdd/refresh index entry.

Approve these canonical destinations and the mutation scope?

Gate · candidate / verdict

Branch Decision

Record whether this UI direction is a valid branch of the wireframe tree. This is a branch decision, not implementation approval.

Decision for the Search-To-Pick Sprint UI branch:

Gate · post-approval route

Post-Approval Route

On an approve decision, the recommended next route is /build-ui-screens search-to-pick-sprint (build the visual screens from this approved packet), later followed by /logic-wiring.

Confirm the post-approval route.

Compile Responses

Answer the gates you can, then compile. Partial responses are fine — they focus the next revision. You do not need to answer every gate to send emphasis, concerns, or clarification requests (use the section feedback controls for those).