How to hire a game UI/UX designer

First, work out which role you need

"Game UI designer" covers at least three different jobs. Hiring the wrong one is expensive, because each is genuinely good at things the others are not.

On a team under about fifteen people, the generalist is almost always the right call. Splitting UX and UI across two freelancers works well in a studio with a design lead to hold them together, and badly without one.

When to bring one in

Timing changes the price more than negotiation does. The same work costs less and lands better when it happens in the right window.

1. 01

   Too early: before the core loop is playable

   The game is still changing shape. Anything designed now gets redesigned, and you pay twice. Exception: a quick flow sketch to prove a system is not too complex to explain.

2. 02

   Right: core loop playable, systems roughly known, menus not yet built

   Flow decisions are still cheap, the game is stable enough to design against, and the designer's output arrives before your engineers commit to a structure.

3. 03

   Late but workable: systems built, UI is placeholder

   A visual pass plus a usability review. You will inherit some structural constraints, but this is a common and perfectly reasonable place to start.

4. 04

   Expensive: after a bad launch

   Now you are paying for redesign, re-implementation and the reviews. Doable, but it is the most costly version of the same job.

Where to look

Whichever channel, judge on the same evidence. A referral with no case studies still needs to answer the portfolio questions below.

How to read a portfolio past the hero shot

Portfolio pages are optimised for the two seconds you spend on them. Spend twenty instead, and look for five specific things.

1. Full flows, not single screens. Can you see how a player gets from the title screen to a match and back? One gorgeous main menu proves illustration skill, not interface skill.
2. The unglamorous screens. Settings, key rebinding, error and empty states, a full inventory with 200 items in it. Anyone can make a title screen look good. These are the screens that reveal whether someone has shipped.
3. Written reasoning. Look for why, not just what. A case study that explains a rejected option tells you far more than one that narrates the final layout.
4. Range across genres, or an intentional niche. Both are fine. What is not fine is the same layout wearing five different colour schemes.
5. Evidence of implementation. Screenshots inside the engine, handoff specs, or a shipped link. Design that never survived contact with a build is a mood board.

Red flags worth walking away from

• No wireframes anywhere. It means structure is being decided in Photoshop, which is where structural problems become expensive.
• Every screen is a full-bleed illustration. Gorgeous, unimplementable, and usually unreadable in motion.
• Cannot answer "how would this work on a gamepad?" on the spot. This is not a trick question for anyone who has shipped on console.
• Quotes instantly without asking about scope. A number given before anyone counted the states is a number that will change.
• Won't do a paid test. A short paid task is normal and fair. Reluctance usually means the portfolio is not fully theirs.
• Vague about source files. Who owns the working files after delivery should be a one-sentence answer, not a negotiation.
• Talks only about tools. Fluency in Figma is table stakes. If the answers are all about software rather than players, the screens will be too.
• No questions for you. A designer who is not curious about your player, your platform and your constraints will design for none of them.

Twelve questions worth asking

Pick six. The point is not the answers, it is whether the answers are specific.

1. Walk me through a flow you designed that you later changed. What broke?
2. How do you handle controller navigation and focus order?
3. What do you need from us before you can start?
4. How do you handle text that is 40 percent longer after localisation?
5. What does your handoff to a developer look like, exactly?
6. How do you test that a HUD is readable during actual gameplay?
7. Which parts of this project would you push back on?
8. How many revision rounds are included, and what counts as a round?
9. What happens if we add a feature halfway through?
10. Do you design the states, or only the default view?
11. Who owns the source files after delivery?
12. What is the smallest useful thing you could deliver first?

That last question is the most revealing one on the list. A designer who can decompose your project into a first useful delivery is a designer who has worked inside a real production schedule.

The brief that gets you an accurate quote

Copy this. It takes ten minutes and it is the difference between a quote and a guess.

• Game: genre, one-line pitch, a link to a build, trailer or screenshots.
• Platform: PC, console, mobile, VR. Say which inputs must be supported.
• What exists: engine, art direction, existing UI, wireframes, anything already built.
• What you need: a numbered screen list, even a rough one. Ten guessed screens beat "the whole UI".
• Deadline: the real one, and what it is tied to (a demo, a festival, a publisher milestone).
• Budget range: a range is fine. Withholding it does not get you a lower price, it gets you a slower conversation.
• Decision maker: who approves the work.
• References: two or three games whose interfaces you admire, and one sentence each on why.

The paid test task, done properly

A test task of two to four hours is reasonable, respectful and reveals more than any interview. Unpaid spec work on your actual screens is not a test, it is free labour, and the good designers decline it.

• Pay their rate for the hours it takes. This is what separates a test from an audition.
• Use adjacent work, not your real screens. A settings screen for a similar game, not the settings screen you need shipped.
• Give a real brief, including a constraint: gamepad support, or a longest-string case.
• Ask for the thinking, not just the artwork. Two paragraphs on why they structured it that way is the actual deliverable.
• Judge the questions they ask before starting. That is the strongest single signal in the whole process.

Contracts, rates and what you should own

Before work starts, get four things in writing. That is the entire contract for most projects, and it prevents almost every dispute I have seen.

The first two weeks

Onboarding a designer badly costs more than hiring the wrong one. Front-load these and the rest of the project runs itself.

1. 01

   Day one: a build and an engineer

   A playable build, and fifteen minutes with whoever will implement the UI. Constraints discovered in week one are free; discovered in week six they are redesigns.

2. 02

   Day two: the content dump

   Real item names, the longest strings, the biggest numbers, the fullest inventory. Everything the layout has to survive.

3. 03

   Week one: flow before pixels

   Expect wireframes, not art. If you are being shown finished screens in week one, structure is being skipped and you will pay for it later.

4. 04

   Week two: one screen taken all the way

   One flagship screen finished to final quality, with its states. It sets the visual language and it is the cheapest possible place to have the argument about direction.

How to give feedback that does not cost you money

Feedback quality is the client-side skill that most changes the outcome. These four habits are worth more than any amount of haggling.

• Describe the problem, not the fix. "I lose track of which weapon is equipped" gets you a designed solution. "Make the icon bigger" gets you a bigger icon and the same problem.
• Consolidate before you send. One list from one decision maker. Contradictory notes from four people is the most expensive input a project can receive.
• Separate must-fix from preference. Say which is which. Designers will spend real effort on both unless you tell them not to.
• Respond to the stage you are in. Colour feedback on a wireframe wastes a round. Structural feedback after visual sign-off costs a rebuild.

When it is not working

Sometimes it does not click. The tells are usually visible by the second milestone: the same note has to be given twice, the work does not respond to the brief, or you are being shown decoration when you asked for structure.

Say it plainly and early, in writing, with a specific example. Most of the time it is fixable, because the cause is usually an ambiguous brief rather than an incapable designer. If it is not fixable, end it at a milestone boundary, pay for the work delivered, and take the source files with you. A clean ending at milestone two is far cheaper than an unhappy one at milestone five.