A founder posts a job for a game designer. Forty applications arrive. Half are level designers with beautiful whitebox portfolios, a quarter are systems people with spreadsheets full of economy math, and the rest are generalists who’ve done a bit of everything on teams of five.
All of them are game designers. None of them do the same job. And the founder reading the pile still doesn’t know which one solves the problem that made them post in the first place, which is usually the real issue, because the job title was chosen before the problem was written down.
Three titles, three different jobs
The overlap is real, especially on small teams where one person covers all three. But the specializations diverge fast once a project gets past prototype, and the skills stop being interchangeable.
The game designer
Owns the core loop and the answer to “what is this game.” Works in pillars, references, and feel. On a mature team this role is closer to direction than production, deciding what the player does moment to moment, why it’s satisfying, and what gets cut when everything can’t fit.
The level designer
Turns mechanics into space. Pacing, sightlines, difficulty curves, encounter composition, and the specific craft of teaching a player something without a tutorial box. Level designers work in the engine most of the time—greyboxing, iterating, playing their own work until it stops annoying them.
The systems designer
Owns anything with numbers that interact. Progression, economy, combat math, crafting, retention curves, and monetization balance. Much of the job happens in a spreadsheet before it happens in the engine, and the good ones can tell you what breaks at day 30 before you’ve built day 3.
Hire the problem, not the title
Almost every bad design hire starts with a job post written before anyone articulates what was wrong. The post describes an ideal person. It should describe a broken thing.
Before looking for a game designer for hire, write one sentence describing what’s failing right now. “Players quit at level 12.” “The economy inflates by week three.” “The core loop is fine but the second hour is empty.” “Combat feels floaty.” Each of those sentences points at a different specialist, and none of them point at a title. The first is probably level design or progression. The second is systems, unambiguously. The third could be either. The fourth is often not a designer at all.
This matters more in a market with a lot of available talent. GDC’s 2026 State of the Game Industry found game designers had the highest layoff rate of any discipline over the previous twelve months, at 20 percent. You will get strong applicants. Getting strong applicants for the wrong role is a more expensive mistake than getting weak ones for the right role.
Genre changes the answer more than seniority does
A single-player narrative game and a mobile idle game both need design. They need almost entirely different design.
Narrative and campaign-driven projects lean level design and moment-to-moment craft — the economy is usually simple and the pacing is everything. Live-service and free-to-play projects invert that completely: content pacing matters, but the thing that kills the project is usually an economy that inflates, a progression curve that flattens, or a retention model nobody stress-tested. Competitive multiplayer needs both, plus somebody who understands balance as an ongoing operation rather than a launch state.
Supercell has been open about running very small teams with deep systems ownership, because in their genre the systems are the product. That’s a genre-specific answer, not a universal one. Copy it onto a story-driven single-player game and you’ll have excellent spreadsheets and a boring second act.
Sometimes the answer is an engineer
A meaningful share of what gets diagnosed as a design problem is actually a tooling problem. If your designer has to ask an engineer for a build every time they want to test a number change, they aren’t designing—they’re queuing. Iteration speed is a design constraint, and on most small teams it’s the binding one.
Compare the two purchases honestly. Bringing in a unity developer for hire to build a designer-facing tuning tool, expose values to a data table, and set up a fast iteration loop often produces more design output than the same budget spent on a second designer, because it removes the bottleneck between an idea and a testable build.
The same logic covers analytics. A designer who can see where players actually stop will find the problem in an afternoon. A designer working from intuition and a Discord channel will find it eventually, and “eventually” is the expensive part.
This is worth checking before any design hire, because it is cheap to check. Sit with whoever is doing design work now and watch them make one balance change. Count the steps between the change and seeing it in a build. If that count is above three, you have found your bottleneck, and it is not a headcount problem.
The Job Post Is the Diagnosis
Go back to the founder with forty applications and no way to sort them. The pile isn’t the problem. The problem is that nothing in the job post described a failure, so nothing in the applications can be evaluated against one.
Here’s the useful reframe: a job post is a diagnosis written in public. If you can’t state the symptom in one sentence, you’re not ready to hire, and interviewing forty people won’t get you readier — it’ll just make you pick whoever interviews best. Write the symptom first. The right specialist is usually obvious the moment you do, and the job post nearly writes itself.
Frequently Asked Questions
Can one designer cover all three roles on a small team?
Up to roughly ten people, usually yes, and most small studios operate that way successfully. The strain shows when the game has both a content pipeline and a live economy, since those pull in different directions daily. Watch for the point where your designer is context-switching between spreadsheets and greyboxing several times a day — that’s the signal to specialize.
What should be in a portfolio for each design role?
Level designers should show playable spaces with the reasoning behind pacing and sightline choices. Systems designers should show a model—an economy sheet, a progression curve—plus what happened when real players hit it. Game designers should show a decision they made, what it cost, and what they cut to protect it. Shipped work beats concept documents in all three cases.
Is it realistic to bring on a design specialist part-time?
For systems work, often yes. Economy and progression modeling has natural checkpoints and can be reviewed asynchronously, which makes part-time or contract arrangements workable. Level design is harder to split because it needs sustained time in the build. Core game design is hardest of all, since the role depends on daily context that part-time hours don’t accumulate.
How do you tell a design problem from a tooling problem?
Ask how many times your designer tested a change last week. If the answer is under five, iteration speed is the constraint and no amount of design talent will route around it. Fix the loop first — a data table, a tuning panel, a faster build — then re-ask whether you still have a design problem. Often you don’t.
