I'm Mitchell Vizensky

My Process

I design game features players come back for, and I get them playable as early as I can. A team learns more from ten minutes with a rough build than from a week of reviewing mockups, so my process is built around getting to something real, putting it in front of players, and letting what we learn steer the next step.

1. Frame the problem

Every feature starts with two questions: what problem does this solve for players, and what does the business need it to do? I work with product and engineering to agree on both up front, then write down how we'll know it worked, such as a retention, engagement or revenue target. That target follows the feature all the way to launch.

2. Learn from players and data

Next I learn as much as I can, as fast as I can. I look at how players use the game today in our live data, talk to players, and tear down how other games handle the same problem: what they got right, what they missed, and what we can do better. At The Pokémon Company International I set up the user research process for our Game Studio team, so this step is built into how we plan, not tacked on at the end.

3. Prototype early, in code

This is where my process differs most from a classic UX workflow. Once I have a direction, I build a working prototype, often with AI coding tools, so the team can play the idea instead of imagining it. Flows and wireframes still happen in Figma, but a playable build answers the questions a static mockup can't: how it feels, how long it takes, and whether it's fun. It also gets everyone, from engineers to leadership, reacting to the same thing.

4. Test with players, then iterate

I test early and often: grey-box playtests, internal sessions, unmoderated tests and surveys, depending on the question. I watch for where players hesitate, what they misread, and what makes them smile. Each round feeds the next version of the prototype, and I keep going until the results are clear rather than until the schedule says stop.

5. Polish and build with engineering

With the design proven, I move to final visual design, motion and the details that make a feature feel good to use. I work in Unity alongside engineers, often building UI layouts myself so what ships matches what we designed. Clear specs and shared components keep the build fast and consistent.

6. Launch, measure, improve

Launch is the start of the next loop. For risky features we roll out in stages or test variants against each other. After launch I check the results against the target we set in step one and use what we learn to tune the feature and shape the next one. Then we take a moment to celebrate as a team before moving on.

When a stakeholder disagrees

Disagreement is useful. It usually means someone sees a risk I haven't. I start by listening to understand what they're worried about, then share the player research and data behind my recommendation. Often the best answer combines both ideas. When we still can't agree, a quick prototype or test settles it better than a debate, and if we ship their version, I measure it and bring back the results. Trust comes from being right about the players, not from winning the argument.

What it's like to work with me

• I listen first and steer conversations toward ideas we can test.
• I make things real fast, so decisions happen sooner and with more confidence.
• I explain design decisions clearly, in writing and in the room, to engineers, artists, product and leadership.
• I care about both sides of a feature: how it feels to players and what it does for the business.