UX Variations — Tactical Battle

1. Guided Battle Drill

Design thesis: The first battle should behave like a competent field instructor: reveal only the next tactical job, then remove scaffolding as the player proves comprehension.

Target user fit: Players new to the deck/base hybrid, browser trial users, and campaign players who need confidence before systems depth.

Parent-flow relationship: Same battle contract, but progression is segmented into drill cards: deploy, scout, capture, build, counter, commit, finish.

Flow changes

1. Scenario opens on a concise operation order with three visible goals: secure near points, establish the command chain, break the Soviet push.
2. Band A deployment is constrained to a small first set until the player issues the first scout/capture orders.
3. Cover and suppression prompts appear only when a relevant unit is threatened.
4. First command-post surface is recommended, not forced.
5. Band B unlock produces a short deck-arrival moment naming what changed.
6. Save/reload drill appears as an optional checkpoint after first escalation.
7. Band C and wonder prerequisites unlock as a final battle drill.

Onboarding and activation model: Activation happens when the player builds a surface and sees the deck roster change immediately, with a short "Main Body now available" confirmation.

Typical workflow sequence: Read drill objective, act on map, receive focused feedback, unlock the next phase, repeat until the late commitment.

Sharing, collaboration, permissions: None in-slice; shareable output is a post-battle summary showing completed drills and the decisive moment.

Return-use and notification model: Restart offers "try without drill prompts" after one completion.

Failure recovery: If a player loses a command post or gets pinned, the drill switches to a recovery task: retreat, rebuild, counterattack.

Navigation model: Linear drill rail plus map hot spots.

Screen-by-screen layout direction: Operation order panel, contextual drill card, tactical map, compact deck tray, command-post progress strip, post-battle drill report.

Key components and controls: Next objective card, minimize guidance, replay hint, recommended build marker, save checkpoint button, restart scenario.

Button and link behavior: Primary button focuses the next drill target; secondary button dismisses guidance for the current phase; restart returns to scenario start.

Density and hierarchy: Low-to-medium density; map remains primary, guidance is prominent but collapsible.

Responsive behavior: Desktop-first; on narrower screens, drill cards collapse into a bottom sheet and the deck tray becomes segmented tabs.

Visual tone: Training-map clarity, annotated but not playful.

Strengths: Fastest route to first comprehension, strong onboarding, good for browser trial.

Risks: Can make the tactical battle feel solved; power users may resent staged reveals.

Implementation complexity: Medium, mostly stateful tutorial triggers and contextual copy.

Prototype first: First seven minutes through Band B unlock with three drill prompts and one recovery prompt.

Ready-for-ui signal: User can explain cover, capture, and command-post unlock without saying the game played itself.

2. Commander's Tactical Console

Design thesis: The first battle should trust the player as an operator and surface every important system: resources, command posts, deck bands, capture pressure, AI tempo, and save state.

Target user fit: Deck/division tacticians, WARNO/Steel Division veterans, and players who prefer dense tactical feedback.

Parent-flow relationship: Same flow, but the player can freely choose sequence from the start. The UX adds observability rather than guidance.

Flow changes

1. Scenario opens directly into a command dashboard over the map.
2. Deck roster shows all bands with locked prerequisites visible.
3. Command-post queue, damage, unlocks, and resource deltas remain persistent.
4. AI pressure appears as contact reports and objective pressure, not hidden AI state.
5. Save/pause status is always visible in the system strip.
6. Post-battle report emphasizes build timings, capture control, and unit preservation.

Onboarding and activation model: Activation occurs when the player sees the complete deck plan and intentionally chooses an escalation path.

Typical workflow sequence: Scan dashboard, issue map orders, inspect deck locks, choose build surface, monitor AI pressure, time late commitment.

Sharing, collaboration, permissions: No collaboration; exportable battle log or screenshot-friendly after-action table.

Return-use and notification model: Return loop is "beat your timing": restart with prior build-order metrics visible.

Failure recovery: Alerts escalate from watch to warning to critical for pinned units, damaged command posts, and command-score drain.

Navigation model: Persistent tactical console with tabs for Deck, Command, Objectives, Log.

Screen-by-screen layout direction: Full map center, left deck/command rail, top resource/status bar, right objective/intel rail, bottom selected-unit inspector.

Key components and controls: Sortable deck list, prerequisite checklist, build queue, alert log, pause/save/reload controls, filters.

Button and link behavior: Command buttons issue orders or focus map entities; locked items open prerequisite detail; log items pan camera to source.

Density and hierarchy: High density; compact typography, tables, icon-backed status chips.

Responsive behavior: Desktop-only for evaluation; tablet collapses one rail; mobile is out of scope except read-only after-action review.

Visual tone: Military operations room, utilitarian and restrained.

Strengths: Best branch for expert agency and system legibility.

Risks: Highest onboarding cliff; may validate power-user desire while failing broader first-session clarity.

Implementation complexity: High because it needs synchronized status surfaces.

Prototype first: Opening through first Band B build with persistent deck prerequisites and command-post state.

Ready-for-ui signal: User praises control and can act faster without losing tactical cause/effect.

3. Map-First Operational Battle

Design thesis: The battlefield should teach the system. Objectives, terrain, and enemy movement lead; deck and command-post UI appears when the map creates the need.

Target user fit: Campaign wargamers and tactical players who need spatial stakes before abstract deck logic.

Parent-flow relationship: Same battle, but entry begins with the map situation rather than fixed-deck planning.

Flow changes

1. Scenario opens on the Helmstedt map with front-line annotations and objective clusters.
2. The player receives a map-based opening task: secure the road junction and recon both flanks.
3. Deck tray stays compact until the player selects a command-post or deploy zone.
4. Command-post build sites are visible terrain objects with construction radius and vulnerability.
5. AI escalation is communicated through map reports: dust columns, artillery markers, recon sightings.
6. Band C late commitment is presented as a battlefield breakthrough, not a menu milestone.

Onboarding and activation model: Activation happens when the player sees that building a command post at a contested location changes the map and roster at once.

Typical workflow sequence: Read terrain, choose lane, capture, build where the map permits, react to spotted AI pressure, commit late support.

Sharing, collaboration, permissions: Shareable artifact is a post-battle map snapshot with capture swings and breakthrough route.

Return-use and notification model: Restart focuses alternate lane plans: center rush, flank economy, conservative build.

Failure recovery: Lost territory triggers fallback lines and rebuild site suggestions rather than abstract alerts.

Navigation model: Map-first, with contextual overlays and minimal permanent chrome.

Screen-by-screen layout direction: Large tactical map; overlays for capture ownership, cover, line of fire, build radii; collapsible lower deck tray; right-side situational messages.

Key components and controls: Overlay toggles, map objective cards, build-site markers, recon/contact pings, after-action heat map.

Button and link behavior: Overlay toggles persist per session; objective cards pan to map; build markers open command-post choices.

Density and hierarchy: Medium density; terrain, objectives, and unit positions dominate.

Responsive behavior: Desktop uses overlay controls; tablet moves overlays into a bottom drawer; mobile only for future spectator/review.

Visual tone: Living operational diorama with restrained military cartography.

Strengths: Best at selling the war-map fantasy inside a battle.

Risks: Deck × command-post novelty can become secondary or under-explained.

Implementation complexity: Medium, weighted toward map overlays and battlefield markers.

Prototype first: First five minutes with objective overlays, capture clusters, and contextual build-site reveal.

Ready-for-ui signal: User talks about terrain and command-post placement as strategic choices, while still noticing deck unlocks.

4. Deployment Plan First recommended next $ui-interview

Design thesis: The first battle should make the player understand the fixed 11th Armoured deck before the first shot, then let command-post construction unlock Band A / Band B / Band C availability under pressure.

Correction note: The prior doctrine framing was rejected because the real research supports fixed decks, deployment bands, and command-post unlocks, not doctrine-as-player-strategy.

Target user fit: Deck/division tacticians, theorycrafters, and players judging whether the deck × command-post hybrid is actually distinctive.

Parent-flow relationship: Same battle, but the pre-battle and opening frame centers on UK 11th Armoured fixed deck, visible locked bands, and a player-authored deployment queue.

Flow changes

1. Scenario opens with a Deployment Plan for 11th Armoured: recon and infantry first, Comet timing, artillery observers, and the Centurion Trial Troop as the preselected mockup wonder.
2. The deck roster is displayed through unit category tabs such as INF, REC, VEH, ARMOR, AT, ARTY, AIR, SUPPORT, and WON, with A/B/C availability as subordinate timing sections.
3. The player arranges a planned deployment queue from fixed deck cards, including locked future entries with prerequisites.
4. The map starts immediately after confirmation, with quick-click access to planned deployments and an override path through the normal deployment menu.
5. Command-post completion advances planned availability rather than behaving like a generic tech unlock.
6. Late wonder checklist is visible from the start but clearly unreachable until the Advance Command Post and battlefield control.

Onboarding and activation model: Activation happens before battle when the player can predict how command-post choices will make Comets, observers, and air support arrive.

Typical workflow sequence: Deployment Plan -> arrange deployment queue -> confirm -> tactical entry -> quick-click planned deployments or override via deployment menu -> command-post unlock -> after-action comparison.

Sharing, collaboration, permissions: Shareable artifact is an after-action comparison of planned deployment order vs actual deployment order.

Return-use and notification model: Restart prompts the player to refine the Deployment Plan with prior timings.

Failure recovery: If the player falls behind, the deployment-plan panel offers adaptation paths: stabilize with Assembly Area, contest center with artillery, or rebuild command chain.

Navigation model: Deployment Plan into tactical map; in-battle plan panel remains accessible.

Screen-by-screen layout direction: Pre-battle Deployment Plan, unit category roster tabs, command-post dependency diagram, tactical map with deployment-plan side panel, after-action plan comparison.

Key components and controls: Fixed deck badge, unit category tabs, A/B/C availability sections, reorderable-looking deployment queue, prerequisite checklist, command-post dependency diagram, after-action timeline.

Button and link behavior: Queue controls arrange planned deployments without changing deck contents; locked cards reveal prerequisite surfaces; after-action timeline jumps to battle events.

Density and hierarchy: Medium density; deck identity gets the first read, map takes over after start.

Responsive behavior: Desktop uses a side-by-side deployment-plan and map transition; tablet stacks; mobile defers the pre-battle deployment-plan review to a full-screen step.

Visual tone: Staff briefing plus armored-division identity; precise, confident, and readable.

Strengths: Directly tests the riskiest product claim: deck identity authored before battle, executed through command posts in battle.

Risks: If too abstract, first-time players may feel they are reading a build guide instead of entering a fight.

Implementation complexity: Medium; requires pre-battle state, dependency diagrams, and after-action path logging.

Prototype first: Deployment Plan into tactical entry, planned deployment quick-click, first command-post choice, and Band B unlock.

Ready-for-ui signal: User can explain the 11th Armoured Deployment Plan, why a command post changed deck availability, and wants to replay with a different deployment queue.

5. Resilient Skirmish Loop

Design thesis: The first battle should prove that a browser tactical session can be trusted: pause, save, reload, fallback, rebuild, and recover are part of the combat loop rather than utility afterthoughts.

Target user fit: SP campaign wargamers who punish missing saves, brittle sessions, and unfair AI; browser skeptics.

Parent-flow relationship: Same battle, with explicit recovery and interruption beats inserted into progression.

Flow changes

1. Scenario opens with a compact readiness panel: objective, save status, pause availability, restart path.
2. First combat phase introduces retreat, pinning recovery, and fallback lines.
3. First command-post build includes visible vulnerability and repair/rebuild affordances.
4. Mid-battle asks the player to perform a save/reload confidence drill.
5. AI pressure is tuned to create one recoverable setback before Band C.
6. Post-battle report includes resilience outcomes: reload success, command-post recovery, units saved, comeback path.

Onboarding and activation model: Activation happens when the player survives a setback and sees state restore/recovery work reliably.

Typical workflow sequence: Fight, get pressured, pause/save/reload or retreat, rebuild command chain, counter-escalate, finish.

Sharing, collaboration, permissions: Shareable artifact is a comeback/recovery after-action log.

Return-use and notification model: Resume battle is a primary entry next to restart; autosave status is explicit.

Failure recovery: This branch makes recovery the centerpiece: pinned units, damaged posts, lost points, and bad saves all have visible routes.

Navigation model: Tactical map with persistent resilience/status strip and recovery prompts.

Screen-by-screen layout direction: Readiness panel, tactical map, save/pause strip, recovery objective cards, reload confirmation, after-action resilience report.

Key components and controls: Pause, manual save, autosave indicator, reload, restart, fallback objective, repair/rebuild command, recovery warnings.

Button and link behavior: Save writes current state; reload confirms state timestamp; restart requires confirmation; recovery prompts pan to fallback or repair target.

Density and hierarchy: Medium-low density; status trust and recovery states are highly visible.

Responsive behavior: Desktop and tablet supported; mobile remains a future spectator/resume review only.

Visual tone: Calm command reliability under pressure.

Strengths: Best branch for validating browser-first trust, SP-first expectations, and interruption resilience.

Risks: May feel procedural if the setback is too artificial or if recovery interrupts tactical momentum.

Implementation complexity: Medium; depends on save-state fidelity and recovery-state instrumentation.

Prototype first: Opening through first setback, manual save, reload, and command-post recovery.

Ready-for-ui signal: User trusts the session enough to experiment and says recovery made the battle more replayable, not more tedious.