UX Case Study · Companion Tool

Pokémon Battle Strat

PokéBattle · Competitive Edition — a Gen 9 battle lab

A data-driven companion tool designed to lower the barrier to entry for competitive Pokémon players by turning complex match-prediction data into actionable battle strategies.

Pokémon Battle Strat interface: dark battle calculator with quick matchups and a Predict button
The battle lab — win probability, field-modified damage, OHKO flags, checks & counters.
02 · The problem

Cognitive overload

Competitive Pokémon (VGC / Smogon) has a massive barrier to entry: players track 1,000+ Pokémon, thousands of moves and abilities, and run damage math on the fly — inside timed turns. The existing tools are highly functional but read like 2005 database tables: walls of stat numbers and spreadsheet calculators that cause extreme cognitive overload mid-battle.

The goal: a tool that translates complex math into actionable empathy — showing players why a decision fails, not just the failure itself.

03 · Role & scope

Where I sat in the build

ROLE

Lead UX/UI Designer & Researcher…and developer — I bridged the Python prediction backend into the interface myself.

TIMELINE & TOOLS

Spring 2026Figma · FigJam · Python (data & predictor logic)

THE CHALLENGE

Balance complex statistical prediction with a clean, split-second decision-making interface.

04 · User research

Two players, one timer

PERSONA 01

The Aspiring Competitor

Knows the games, intimidated by the meta. Wants to try ranked battles but bounces off damage calculators and tier jargon. Needs the tool to teach while it answers.

PERSONA 02

The Experienced Strategist

Already runs the math — slowly. Wants speed and trust: verify a call in seconds mid-ladder without breaking focus. Needs density without noise.

Insight 1 — speed is crucial. Mid-battle turns are timed; players can't spend 20 seconds reading stats. Every screen had to resolve to a verdict in under 5 seconds.
Insight 2 — predictive anxiety. Players struggled most with predicting the opponent's next move, not analyzing their own stats. The tool had to answer "what are they about to do?" — not just "what are my numbers?"
05 · Information architecture

Structuring the messy middle

The core flow: a player inputs team data, the predictor runs, and a battle strat comes back. The hierarchy problem was displaying type matchups, speed tiers, and win probability without cluttering a screen someone reads mid-turn. Early layouts that surfaced everything at once — the "dashboard dump" — were discarded: testers scanned past the verdict looking for it. The shipped structure buries nothing but ranks everything: verdict first, evidence beneath, depth on demand.

INPUT

Pick Pokémon; EV presets, natures and items constrain choice before paralysis sets in.

PREDICT

The Python predictor runs matchup math, speed checks and field conditions.

ACT

One verdict bar, threat flags, and the recommended line — readable in seconds.

Pokémon picker modal with search and generation filter tabs
Input: the full dex as searchable cards — gen filters kill scrolling.
Matchup setup: Mew vs Reshiram player cards with EV spreads and natures
One card per decision — spread, nature, item; the speed check answers before Predict is pressed.
06 · Bridging data & UX

The secret sauce: logic into glances

My multi-disciplinary edge on this project was translating the backend predictor into glanceable visual cues. The pivot came from usability testing:

WHAT FAILED

The prototype showed exact damage calculations — "Earthquake deals 82% to 96%." Users still paused to do mental math. Raw data is not UX; it violated the whole premise of cognitive offloading.

THE FIX

Distill calculations into color-coded threat levels — green / yellow / red action paths a player reads in under 5 seconds:

SURVIVES2HKO RANGEGUARANTEED OHKO
Prediction results with win probability bar and SURVIVES / 2HKO RANGE damage flags
Shipped: the predictor's output as flags and a single probability bar — the number is optional.
07 · High-fidelity design

Two core features

6v6 team builder with two six-slot teams and an Analyze button
FEATURE 1 — Matchup Analyzer: glanceable team-vs-team strengths, weaknesses and archetypes.
Matchup intel: checks and counters, speed tier context, strategy guide
FEATURE 2 — Move Predictor: the opponent's most likely actions, checks & counters, and speed-tier context.

DESIGN HIGHLIGHT

I chose a dark-mode interface to reduce eye strain during long sessions, and used bold, familiar Pokémon type-colors as the labeling system — recognition players already carry does the wayfinding for free.

08 · Walkthrough

One turn, three glances

The micro-actions of a single decision: the user inputs the opponent's lead, the predictor calculates the threat, and the tool instantly recommends the safest line.

Turn 1: input the opponent's lead Pokémon
Input the opponent's lead — speed verdict appears immediately.
Turn 2: the predictor calculates threat level
Predict — threat flags and win probability resolve the matchup.
Turn 3: recommended switch-in from team analysis
Act — role gaps and coverage point to the safest switch-in.
09 · Impact, validation & learnings

Closing the loop

< 30s
TO ASSESS A TEAM'S FLAWS — DOWN FROM 3+ MINUTES
< 5s
TARGET TIME-TO-VERDICT FOR ANY SINGLE MATCHUP SCREEN
"Felt much more intuitive than traditional calculators."— USER TESTING FEEDBACK

What I learned: designing for data-heavy, rapid-decision environments demands strict prioritization of content — the verdict earns the top of every screen, and everything else has to justify its distance from it.