From Student to Designer: Part 4 – Design Tests

As usual, my advice is specific to design and to seeking a more traditional job in AAA development, as opposed to breaking in as an indie, but most of it can be applied elsewhere. This is just my personal advice, so I recommend getting others to review your work for second and third opinions, and ultimately make your own decisions.

Part 1: Websites & Resumes
Part 2: Portfolios
Part 3: Cover Letters
> Part 4: Design Tests
Part 5: Interviews
Part 6: Entry Level Design Jobs


What Is a Design Test?

A design test is a test of your design skills where a studio asks you to perform some kind of design work as part of the interview process. Usually a design test is timed (i.e. one week in your spare time seems to be pretty common). Sometimes the design test is on-site as part of the interview process, where you are given anywhere from one to four hours to complete an assignment by yourself.

I’ve done several design tests, been given (and passed on) a few more, and even designed one. When writing this article, I reached out to a lot of other people in the industry for their advice and experiences. The type of work varies depending on what kinds of games a company makes and what work designers do there. Design tests may ask you to:

  • Analyze or deconstruct mechanics or systems in an existing game
  • Take an existing mechanic or system and propose changes to meet a new design goal
  • Design and document a chunk of new gameplay in an existing game, such as a new feature, gameplay mechanic, weapon, boss, puzzle, etc.
  • Design and document a new level or mission to an existing game or within certain parameters, including all the information needed to put that level into production.
  • Implement a level in a particular toolset.

These tests are pretty always specific to the studio. A company that makes puzzle games will have a design test that involves designing a puzzle, whereas a company that makes third-person shooters will probably have you design a level for one of those. A mobile company that makes free-to-play games may test your knowledge of monetization, the audience, and platform, but a AAA studio probably won’t since that’s not part of the job of a designer. So the best way to prepare for a design test is to know what kinds of games the studio makes.

The design tests usually have a number of requirements and limitations that they expect you to follow when doing the test. In my experience, these kinds of constraints are usually realistic and mirror normal development of a game, thus keeping the scope of your work in check.

Not all studios have design tests. Studios that do have design tests may only selectively choose who needs to complete them or give them to everyone no matter the position. I think they are more common in junior roles, where there are more applicants and those applicants have less experience, so as a student (which you, reading this, probably are!) you are likely to come across them.


Why Are There Design Tests?

The design test is a supplement to the interview process – it’s just another way to filter applicants and find out which one is best for the job. Most design tests are sent out before or between interviews or take place during an on-site visit.

There’s a few key things that someone can discover from a design test that can be hard to learn otherwise:

  • Evaluate your skills in the genre assigned, assuming you have no previous professional experience.
  • Help identify designers that will need to be micromanaged and hand-held through the design process, as opposed to those that can make intuitive leaps and show initiative and creativity.
  • If you have a realistic understanding of game development process and scope of work you’re detailing out.
  • If you care about the quality of your work and will finish your work to a high standard of polish. I can see this in the presentation, completeness, and quality of the design test submission.
  • If you’re able to communicate your designs clearly and effectively in ways that everyone, not just designers, can understand.
  • If you can plan ahead for many different test cases (“what if the player does x?”), and spec out mechanics with a certain level of completeness. This is kind of asking if your design is water-tight.
  • If you can plan ahead for all kinds of details that affect other departments. Examples: audio cues, lighting, dialogue and story moments, cinematic events, identifying destructible objects or new assets specific to newly-design mechanics.
  • If you did proper research on, and have familiarity with, the studio’s games, or games in the same genre.
  • If you can follow directions!

One thing to keep in mind is that while a design test is a “test” and not final work, I would treat it like you are documenting something that needs to fit into a final game. Work on it knowing (‘pretending’) that this is work that you need to make as part of your job, and that you may be handing it to your leads or peers for review or to other departments as information they need to know.



So when asking others for their experience with design tests, a lot of people shared real-life examples, many of them old and no longer being used, and others actually available publically (if you know how to google for it).  I’ve still summarized and anonymized them since it’s bad practice to share design tests verbatim (it’s kind of like sharing exam questions during finals week). This also means I changed a bunch of key details so, no, don’t expect to see these exact ones anywhere. The below examples come from a big cross-section of studios, from indie to mobile to AAA to third- or first-party studios.

It’s common to see a combination of design tasks that ask you to analyze a game, modify a game, and design a new game (substitute “game” for “mechanic” or “level”). A smaller subset also asks you to implement that game (or mechanic or level) in a game development toolset. This is how I’ve divvied up the types of questions or tasks assigned. But design tests can be anywhere from one to ten different tasks, depending on the studio and the questions they are asking.

Analysis Examples

  • Take two games and analyze their strengths and weaknesses.
  • Take the studio’s existing game and create a flowchart of one of the gameplay loops.
  • Take a successful free-to-play game and analyze it. Explain how monetization works.
  • Deconstruct a competitor’s game and analyze its structure and gameplay.
  • Take an existing game and pick one feature that you think it does best.
  • Deconstruct a level you have shipped in a previous game, including your design process from beginning to end.
  • Compare and contrast how two games implemented the same feature
  • Document a given gameplay mechanic

Modification Examples

  • Take the studio’s existing game and identify a feature you would cut, and explain why.
  • Design a new feature for the studio’s game
  • Balance gameplay values for a specific design goal, such as with a spreadsheet
  • Take a singleplayer gameplay mechanic and adapt it for a multiplayer environment, or vice versa
  • Take an existing premium game and explain ow you would make it free-to-play with monetization

Creation Examples

  • Design a game that could ported to a different platform at a later date, such as the iPhone or Oculus Rift.
  • Design an extensive first-person shooter level in an existing franchise
  • Design a new mobile game, and spec out all the relevant details (story, setting, abilities, puzzle elements).
  • Design a choice-based dialogue tree that fits within an existing franchise. Spec out the consequences/rewards for each path.
  • Design a pitch for a new level in an existing franchise, including level design documentation.
  • Design a level that suits both singleplayer and cooperative gameplay mechanics for a given franchise.
  • Design a new weapon, ability, enemy, or mechanic that fits into an existing game.

Implementation Examples

  • Design and implement a new mission or level with our in-house (3D) tools, including new gameplay mechanics.
  • Design and implement a new level with our in-house (2d) tools, including new gameplay mechanics.
  • Design and build, in the engine of your choice, a singleplayer combat space.
  • Design a new level for an existing singleplayer game, and then implement it in the engine of your choice.
  • Take a level design document and use it to implement the level with our in-house (3D) tools

Now, keep in mind: there’s a bunch of design tests easily within reach if you use google. Tests are normally a lot more specific – I’ve seen everything from one sentence to several pages of specifications. Like I mentioned above, tests are usually context sensitive to the studio you are applying for. If I applied to, for example, the studio that makes Assassin’s Creed, I might expect a test on creating a mission for an open world game, or designing a space meant to be traversed from many angles, or to design a new stealth weapon for the player to use.



Below I’m going to outline some tips on how to complete a design test which, depending on the size and questions asked, can be pretty daunting.

Some of these seem like a lot, and they are. Doing paper level design layouts gets a LOT easier with practice, especially if you have some development experience behind you. So if you go around and compare your results to professional level design documentation, don’t get too disheartened.

When I talked to fellow designers in the industry, the main pieces of advice that came up were:

  • Follow the rules!
  • Understand and use space, scale, and metrics appropriately
  • Flesh out story, character, and drama as it pertains to player experiences
  • Presentation of the final submission matters
  • Be thorough and concise in any written portions

Follow the Rules

This advice is first for a reason! Some tests are deliberately vague, which means that part of the test is you coming up with the right set of information to communicate your design. But this is uncommon among design tests – typically, there’s a whole ton of very specific details they want you to follow.

“Design a level with one unique platforming element, two visually distinct areas, and three enemy types. The enemies must fulfill requirements X, Y, and Z. The platforming elements must do A, B, and C. The player can move at speed G, jump at height H, and has abilities M and N. Introduce ability O halfway through the level.”

That’s a made up summary, but you get the idea – tests can get very specific. Sometimes a person hands in a test and the applicant made the most awesome level… but instead of one unique mechanic, they added three, and instead of an outdoor level, it’s a cavern.  If they can’t work within the guidelines for a test, how are they going to work within scope on a 50-person team? Or, if it’s an indie or mobile studio, they may be thinking about budget right there. In practice, a designer can be told “you can have ONE new thing in your level, but you got to make it worth the work.” That’s part of what design tests are going for – they want to see you take on these restrictions and still surprise them.

Mind you, no one likes a rules lawyer. I suggest you follow the intent of the rules, and don’t try slipping anything in under a technicality. If you realize you’ve been fudging the rules, then either scale back or admit it and address it in your documentation – give alternatives that cut down the scope if your initial proposal can’t work.

Space, Scale, and Metrics

This advice is specific to level design tests.

Designing levels can be hard unless you have, and follow, a set of metrics. Know how fast a player can move, how high they can jump, what the optimal range for combat is, how wide a hallway is, how many steps make up a realistic staircase.

Most game companies put all their metrics in meters so if you’re an American you should get used to this.It’s also a lot easier to design spaces for humanoid characters in meters – a person 2m high (6ft), a nice even number. 2D sidescrolling games are a bit different – you may measure things in tiles instead. Below is an example of the kind of metrics you’d want to take into account when designing a 3D space:

The player is 2m high and about .5m wide and can move at 8m/s. Low cover is .5m high, and high cover is 1m high or larger. Roofs are at least 4m tall. Hallways are 6m wide at minimum. Stairs and ramps can rise at a rate of 1m over 4m horizontally. Optimal combat distance for assault riffle like enemies is around 30m, and snipers around 60m. Combat focus should change no more than 90 degrees from the player’s current heading.

Now, don’t follow those metrics exactly – it changes for every game, and every genre, and there are major considerations for singleplayer vs. multiplayer (the latter, of course, needing a lot more space). The sooner you get into the habit of following metrics, the better.

When creating maps, make sure you’re accounting for these metrics and scale. Create a set of objects or symbols in your layout tool of choice (photoshop, etc.) that represent reuseable chunks of your level – floors, walls, pieces of cover (if applicable), doors, interactive objects, etc.

Some things to think about when you’re designing a space on paper, especially a 3D space mapped to a 2D layout:

  • Check the height of ceilings and make sure the player won’t bump their head, have difficulty moving around in, has room for a camera to float around in if this is a third-person game, or that it doesn’t seem too massive or tiny.
  • Think about what the player can see at any given point. Look at the level through their eyes. Take into account what may be occluded or revealed as the player moves through the space.
  • Use a variety of scales to create different moods – claustrophobic spaces and giant open spaces feel very different. When navigating through an environment, switch these up.
  • Clearly identify the boundaries of the gameplay space, especially in outdoor environment. If the player decides to wander away, what stops them from leaving the area?
  • Use a variety of different shapes. Most pieces of geometry are built off of rectangles, but don’t be afraid to add curves, circular rooms, or structures with many sides (hexagons, octagons).
  • Take into account verticality, especially in 3D level design layouts. Balconies, bridges, staircases, pits, hills, elevators, ziplines – all of these can add interesting elements for the player, whether it’s combat, traversal, exploration, or puzzle-solving. All good 3D games make use of these elements, so learn to design with them and how to illustrate them on a 2D layout.

Story, Drama, and Character

In any test where you are designing something with a narrative, you should take into account the overall story and feeling of the level or mission. On the job, you may not be writing the story itself, but you might be responsible for deciding what the player’s moment-to-moment goals are, the pacing of the level as tension rises and falls, and what makes the level (or mission) thematically tied together and stand out in the player’s mind.

One tool I recommend is to create a small pacing chart. This is a graph of the intensity of the level over time, so you’ll see a line that rises and falls and spikes at certain moments. On this line, you mark out major events – new mechanics, combat encounters, boss battles, cinematic or story moments, new visually distinct areas, etc.

If you have 20 minutes of gameplay, then at about 15 minutes you should hit the ‘boss battle’ or the major end climax. At about minute 5 the introduction should be over and real challenge arise, About halfway you might want to surprise the player (i.e. the objective reveals a new goal, they’ve reached a new area, etc.). You want to have highs and lows of intensity and mix where story development goes (low intensity moments) and where the action takes place (often high intensity moments). Obviously, what a “high” and a “low” are depends on the genre – is it a puzzle game or a first-person shooter? (Don’t ask me about pacing in roguelikes – if that’s what’s on your design test, good luck!).

When you’re doing a level design test, I highly recommend you make one of these – even if it’s a thumbnail size – and use it to keep a birds-eye-view on your content.

Here’s the kind of questions you can ask yourself while you’re designing:

  • What are the highs – the most intense points – and lows? Is there too much non-stop action, leading to player fatigue? Is it too slow without enough action or reveals? What surprises the player?
  • What is the mood of a specific space or area? Haunted and suspenseful, or Hollywood Action Film? This kind of information informs art, lighting, audio, fx in that area (explosions going on in the background? Low-level fog everywhere?).
  • What are the major cinematic moments?
  • Do you have allies with you or NPCs that can contact the player? Are there intel drops, notes, or other written information in the level? If so, what kind of information do they give the player?
  • Did you design a boss or enemy? What kind of motivations do they have? Does the environment they are in and their abilities match the enemy design? Does the space need different considerations based on the enemy, such as a flying or swimming enemy, or one many times the size of the player?
  • Is the ending satisfying, narratively? Did the player succeed, or did the villain get away? Does it both satisfy the player (give them something they feel they accomplished) and leave them with a cliffhanger (inviting them to continue playing)?

Presentation Matters

Hand in a highly polished presentation. As a fellow designer said, “Pretend you’d submit it as a walkthrough published in a magazine.” That seems like a high bar but… you are competing against a lot of people who want the same job. Do the best work you can do, but present it nicely too. One of the reasons presentation is important is that it’s a reflection of the quality of work you do and your commitment to polish.

Some tips for improving presentation (mostly applying to level design layouts):

  • Unless you are a professional illustrator, don’t hand-draw level designs. Use software like Illustrator or Visio or Photoshop and it will be much easier on you, and you can fix mistakes faster.
  • Use color and icons, and include a key. I want to be able to scan your map and find all enemies, all objectives, or all pickups at a glance (for example, enemies are red circles, objectives are yellow, pickups are blue).
  • Include annotations and callouts for key events or moments for the player throughout the level, and number them so I know the order in which the player encounters them. You can do annotations with just numbers as a second sheet that says what they are, but I think putting them into the map itself as description bubbles (and keeping the text short!) is more effective.
  • Use side diagrams as needed, even if they are thumbnail size, to help communicate the 3D environment when you’re drawing it on a 2D page. Don’t worry about isometric layouts – they are notoriously hard and I don’t think anyone expects them.
  • Check for spelling and grammar. If you don’t have someone else to proofread, then read your work aloud to yourself.
  • Ask someone to look over your work and give you feedback, particularly another designer or someone with good design sense.
  • Look at video game walkthroughs for examples of concise, clear instructions and ideas on how to layout, color-code, and communicate content in your map.

One thing I would suggest: if you’re making a 2D layout, and the design test doesn’t ask for it to be printable, don’t worry about fitting it into several 8.5″ x 11″ sheets of paper. My experience is that people in the industry all look at layouts on the computer anyway, usually as a .PDF, so it can be any size or shape needed to fit all the content into it, with the viewer zooming and panning for additional details.

Complete, Thorough, & Concise

The ability to write clearly and concisely is a skill honed from years of practice. (When it comes to concise, based on the length of my articles, I am certainly not there yet). One thing I’ve seen on friends’ design tests is a lot of words to say relatively simple concepts – long paragraphs, not much use of white space, too many long sentences that lose sight of the original goal. It can be hard, but really try to pare down what you’re saying into short manageable chunks.

If you have to detail out a level or a new game, make good use of headings, bullet points, and lists to help separate content and make it more readable. Images can say a lot, so think about adding small sketches to illustrate your points – sometimes it’s easier to explain the pacing in a level with an image than with several paragraphs. Imagine that someone needed to take your document and know everything possible about a single element – how easy is it for them to get that info?

Remember, treat anything you write as though it needs to be used by others (leads and peers at your studio, in and out of the design department). One of the ‘truths’ of game development is that no one reads documentation – the reality is that most documentation is bloated and written poorly and hard to keep up to date. Write your document and then imagine putting it in a time capsule and pulling it out a year later to update it. How easy will it be to make the relevant changes? Will you need to read (and re-read) the whole thing? Can you scan it to find the details that you need to change? Are all the details there or are there things missing? This gets into what I referred to early as water-tight – taking into account “what if the player does X”.


When To Refuse a Design Test

Sometimes it’s worth your time to do a design test, and sometimes it isn’t.

I would advise against doing a design test if you haven’t already talked with someone qualified to hire you (i.e. a lead or director, not HR). I don’t think studios should ask applicants to invest the time in a design test if they aren’t already serious about hiring them. But there are many studios that send out tests blindly, so it’s your call as to whether to engage.

Remember, you are interviewing the studio as much as they are interviewing you. If a studio sent me a design test via an automated response immediately after applying, I would say they failed the interview. (This has happened. I decided I did not want to work for that studio).

Not all design tests are created equally. Of those I’ve seen, I think most of them are fair and several of them ask much too much of applicants. I probably wouldn’t do a design test that had me implement a level with scripting in an engine from scratch, no matter how cool the job. But I may be willing to do a lot more work for a highly desirable and competitive studio (like, say, Epic Games) than a new mobile startup with a short history.

There are conflicting opinions on the usefulness of design tests for judging applicants, and whether they are potentially exploitative by asking people to do unpaid work in exchange for the chance to get a job. The latter is known as “spec work” and you’re more likely to run across it in art and graphic design roles in entertainment and advertising. There are also exploitative companies out there that may ask an applicant to do a ‘test’, turn them down for the job, and then go on to use their work in the final game anyway (with questionable legality). Some people have valid worries that if a studio asks you to do a ridiculous amount of work for a design test, then they may be equally exploitative to their own employees (crunch hours, poor quality of life).

For some further reading, I recommend the blog post “Just Say No To Employment Tests” by Stephen Dinehart – you should definitely read the comments for the variety of responses and opinions.

Personally, I think design tests are useful, and I don’t resent doing them and I find the results very insightful. If you’ve never had a job in the game industry, you may not be able to afford to be as picky as someone with several years of experience because job opportunities are much rarer. But that doesn’t mean you have no choice in the matter. Keep that in mind when you’re balancing the need for a job with the amount of work a company asks you to do.