A new studio.
No gravitas. An "easy" task.
The Daily Missions feature was the first major task for the new Prague studio inside Wargaming. Minsk HQ handed it over as a simple, no-changes-needed implementation. Their misfortune — and ours — was that it was seen first by the Prague design team before it went to production.
The solution envisioned by the other team had problems. UX problems, tech problems, and the kind of problems that come from designing without measurements in a technology stack that requires them.
We were a new studio with no track record inside the company. Every problem we identified required data to back it up. Opinion wasn't enough. Neither was common sense. Everything needed proof before anyone would listen.
Three problems.
Each one a fight.
- Mission cards in the garage were invisible. UX research confirmed players weren't noticing them. The solution: a subtle animation — visible from the corner of your eye, not distracting.
- The daily mission page was visually overloaded. Too much information competing for attention on every card.
- Re-rolling missions was a hidden interaction. The solution relied on the user hitting an unmarked part of a card — which would flip to reveal a button. No warning. No confirmation. One accidental tap and your re-roll was gone, blocked for 4 hours.
Active daily missions
All dailies done — bonus mission shown
Each of these required data. Not opinions — data. Research tests, comparative analysis, usage numbers. The work of justifying obvious UX decisions to people who'd already decided.
Internal staff.
Small study, clear signal.
I ran the user research myself, on internal staff. A small study — but the signal was clear. Cards in the old design were being overlooked. The new design reduced missed notifications to a negligible percentage.
I also gathered all possible combinations of mission text lengths, languages, and screen sizes — to prove that the new card design handled every edge case where the old one failed.
Because we were a new studio with no internal credibility. "It's bad UX" wasn't a valid argument. Numbers were. Every decision needed to be bulletproof before it went into a review with Minsk.
Not a web app —
in-game UI rendered via Gameface.
Worth clarifying before getting into the solution: World of Tanks UI was fully in-game, rendered via Gameface (Coherent Labs) — HTML, CSS, and React running inside the game client. This was part of a larger Flash/Scaleform to React/Gameface migration.
That meant design constraints that don't exist in a standard web context: exact pixel measurements, no browser dev tools, tech limitations that killed several otherwise good solutions. Constant back-and-forth with developers about what the technology could actually do.
The re-roll fix —
one more step, one fewer headache.
The original re-roll: the user had to tap an unmarked part of the card — no visual cue, no indication the area was interactive. The card would then flip to reveal the re-roll option. No warning that this was limited to once every 4 hours. No confirmation dialog. The action just fired. Accidental tap, re-roll gone, blocked for 4 hours.
Our solution: a visible re-roll button using the standard reload symbol, with text on hover. A confirmation popup before the action — informing the player this was only available once every 4 hours, so they could decide before it was too late. One extra step in the flow. Zero guessing.
Daily missions page
Re-roll button on hover
Confirmation popup
Because absolute visual minimalism isn't the goal — simplicity for the user is. One more step in the flow, one fewer guess. And one fewer forum post dragging the feature through the mud — which is where we measured satisfaction anyway.
The ghost button we proposed was rejected initially — it wasn't part of the design system. Getting it accepted required company politics, more data, comparative research showing how other games handle it, and a lot of patience teaching designers that minimalism and usability aren't the same thing. It also became a new element in the design system — something that wasn't there before we pushed for it.
Win.
What a price.
It also set something in motion that wasn't there before: A/B testing before features went to live production. Before this, testing happened late — after design and development were done, weeks before launch, when it was too late to change anything meaningful. This project changed that.
The knowledge gained on how to gather data inside that company, use it, and ultimately give users a better product — yes. Not all bad. It taught me when to push, when to let go, and how much patience is actually required to change something that was already decided.