Case study · Concept · 2026
Vanguard takes an atmospheric medieval class-selection screen and rebuilds it as a complete preparation journey: understand the role, compare the loadout, deploy. Critique, flow, screens and a working prototype.
01 / The starting point
The older concept has real atmosphere: steel, smoke and heraldry. The information behind the choice is where it struggles.
Every stat reads “9”. Nothing says out of what, or what a point is worth.
Class rank sits beside combat attributes and looks like one of them.
Cards show items but not their names, and equipped looks the same as selected.
The button does not say whether it confirms, queues or deploys.
These are observations from a design critique, not findings from user testing.
02 / The flow
Each step answers one question and names the next action. Then the paths that usually get forgotten: cancel, locked, and failure.
“What does the original communicate?”
Strong character and faction imagery carry the world. Repeated numbers and unnamed equipment leave the interpretation to the player.
“Does this class fit how I want to play?”
Relative trait labels and named, equipped items support a one-line role description.
“What changes if I choose the poleaxe?”
Equipped, Preview and Locked are three distinct, named states. Cancel keeps the halberd.
“What am I joining with?”
Team, class, loadout and mode in one place. Deploy is the explicit join action.
Class → loadout → preview → equip → review → deploy → joining → joined
Preview poleaxe → cancel → halberd retained → review → deploy
Inspect glaive → rank requirement → return → equipped item unchanged
Deploy → joining → failure → selection retained → retry or return
03 / The screens
Three companion screens in the same visual language. Weapon traits and unlock rules are illustrative design content, not balance values.
01 / Class selection
Reach, mobility and protection describe the class trade-off. A short role statement helps newcomers, and named equipment with Equipped labels establishes the current state. Review Loadout says what happens next.
02 / Loadout comparison
The current halberd, the previewed poleaxe and the locked glaive use explicit text states. Side-by-side traits explain what changes. Equip Poleaxe commits; Cancel Preview keeps the halberd. The lock explains its rank requirement.
03 / Deployment review
Team, class, equipment and match context come together. “Loadout updated” confirms the earlier change, Edit Loadout is the way back, and Deploy is the only join action.
04 / The build
The same journey as a React prototype: preview and cancel, locked items, equip, review, deploy, and recovery when joining fails.
Runs from Remi’s portfolio. Open it full screen ↗
05 / How we would prove it
No outcomes are claimed for a study. This is the moderated test we would run with five or six players of mixed genre familiarity before implementation.
Recorded: wrong-state interpretations, accidental commitments, completion without prompting, and whether selections survive recovery. Then focus visibility, reading order, contrast and living-room readability.
Your flow next
Send a screenshot or a build. You get the same treatment: critique, flow, screens, and a version that runs.
