A guide to hiring game designers
Every game is a set of choices. What can the player do? What happens when they do it? What do they get, and why do they want to do it again? A game designer answers these questions and writes the answers down so a team can build them. This guide explains what game designers do, how the role differs from nearby roles and how to set up the work so it goes smoothly. It suits a solo founder with a first idea as well as a studio that needs another pair of hands.
What game designers work on
Design work spreads across a few areas. Mechanics are the actions a player repeats, such as jumping, aiming, building or trading. Levels are the places where those actions happen, with pacing that introduces new ideas at a fair speed. Systems are the rules that connect everything, such as progression, rewards, costs and difficulty. Experience design covers the first minutes, the tutorial, the menus and the feedback that tells the player how they are doing. Some designers cover all of this; others focus on one area, so say which one you need.
How this role differs from nearby roles
A game designer plans how the game plays, and a game developer writes the code that makes it run. If you already know your engine, our Unity developer and Unreal Engine developer pages cover the programmers who work in it. A UI/UX designer shapes screens and flows for apps and websites, which overlaps with game menus but not with game rules or levels. A graphic designer creates visuals for brands and marketing, not the look and feel of a game world. Use the game designer page when the question is what the game should be.
Who does what in a small team
- The designer decides the rules, the levels and the numbers, and writes them down.
- The developer builds them in the engine and tells the designer what is costly or risky.
- The artist makes the look of the world and the characters, working from the designer’s needs.
- The producer or founder decides the order of work and what to cut.
When two people share a job, name one owner for each decision. Arguments about a jump height are much shorter when everybody knows who has the last word.
What to decide before you hire
- The genre, the platform and the engine your game uses.
- Which part of the design you need first, such as the core loop, levels or the economy.
- Whether you need a person who writes documents, builds prototypes in the engine, or both.
- Who tests the game and how you will gather player feedback.
- Who has the final word when the designer and the developer disagree.
Reading a game designer’s portfolio
A shipped game shows that someone finished a project, but a team makes a game, so look for the person’s own part. Ask which mechanics, levels or systems they designed and what changed after players tried them. Good portfolios include design documents, level maps, spreadsheets or playable prototypes. Be careful with portfolios that only show finished screenshots. Ask for the reasoning, because a designer who can explain a choice can make the next one too.
Interview questions to try
- Describe the core loop of a game you designed. What did you change after the first playtest?
- How do you teach a new rule to a player without a long tutorial?
- A reward feels too easy to earn. How do you find out why, and what do you change first?
- How do you write a design so a developer can build it without guessing?
- Tell us about an idea you dropped because it cost too much. How did you decide?
Listen for examples from real projects, with what went wrong and what they changed. Doubt anyone who says every idea they had worked.
Run a small paid design task
Give each finalist a short brief that matches your game. Good examples are a one page design for a single mechanic, a rough layout for the first level, or a small economy sheet with a note on what could be exploited. Pay for the time. Compare how clear the writing is, how well the idea fits your game and how the person handles questions about your players.
Match experience to the stage
At the concept stage you need someone who can test ideas quickly and cut the weak ones. In production you need a designer who writes clear documents, keeps the team aligned and tunes values with care. For a live game, look for experience with events, rewards and data from players. Job titles differ between studios, so ask what each person owned instead of relying on the title.
Give them tools and a rhythm
Give your designer access to the design documents, the project board and the latest builds, and no more than the job needs. Keep your files and accounts in your own name. In the first month, talk at least once a week and play the build together. After that, a short note each week and a review of the design document each month will do. Ask for the same simple update each time so it is easy to compare.
Working with developers and artists
Design goes well when the people who build it are in the conversation early. Ask the developer to review a design before it is final, so costly ideas surface while they are still cheap to change. Ask the artist what the look needs from the design, such as space for a menu or a clear shape for a pickup. A short weekly play session with the whole team keeps everybody looking at the same game.
Mistakes to avoid
- Hiring a developer to also decide what the game should be, with no clear owner for design.
- Writing a very long document that nobody reads instead of a short one that stays current.
- Skipping prototypes and playtests until the game is nearly finished.
- Adding new features before the core loop is fun on its own.
- Letting a contractor own your design files or project accounts.
Need the person who builds the game as well? Read about how to hire a game developer or a Unity developer, and see how hiring works on our pages.















