How to write a playtest survey

Learn how to write reliable playtest surveys, and discover games UX issues.

Last updated:

Survey design is one of those topics that looks simple, but it’s incredibly easy to make big errors that invalidate your results. They are particularly risky – unlike some other research methods, it’s hard to spot when your data is junk, and your conclusions are unreliable. 

Despite this, they are a very common research method, often used at the end of qualitative playtest studies, and an important skill for games user researchers to master.

In this issue we’ll look at the steps to designing a robust and reliable survey or questionnaire for your games user research study.

Sign up at the end of the article to get future monthly games user research lessons direct to your inbox.

How To Write A Playtest Survey

Designing surveys for games user research studies.

Decide what you want to learn

Before you start writing questions, you need to decide what you want to learn. These are your research objectives, and are different from the actual questions you will ask players. A research objective could be “is the difficulty of our game correct”, but you probably don’t want to ask that question directly to players in those words. 

Research objectives are best gathered by speaking to design colleagues, and understanding where the biggest risks for the game are & what do we need to learn to make good decisions. Our first #gamesUXchallenge this month gives you the opportunity to practice generating them.

Having identified research objectives, consider whether a survey is the best method for answering them. Surveys are good for measuring things, for example opinions (“Does this level look good or bad”) or behaviour (“How many times did it take to complete this level”). They are less suitable for deep qualitative feedback which would require observation and probing to answer (“Why did players take 20 attempts to complete this challenge”)

Remember – the research method should always be informed by the research objectives. Starting with a method (“today I’m going to run a survey”), will lead to low impact findings

Decide your sample

After deciding what you want to learn, think about who needs to answer your questions – who are your real players.

A common mistake I see online is sampling by convenience – e.g. getting whoever you can to fill out the survey. This is a waste of time. If you’re not confident that they are really your players, you’re gathering a lot of opinions and thoughts from people who would never buy your game. Pointless.

Some places to consider looking include forums for competitor games, using twitter hashtags and using facebook ads to recruit players. However any recruitment methods will introduce a bias into your participants that you should anticipate, and consider. Offering incentives – money for taking part – can help make your respondents more ‘typical’.

Putting careful thought into “who are the right people to ask this question to”, “how can I find them” and “how can I convince them to fill out my survey” are important for making sure your data is representative of your real players.

Ready to finally start your games user research career?

Every month, get sent the latest articles on how to start a career in game development, and find games user research jobs.

Plus get two free e-books of career guidance from top games companies

Free Games User Research Ebooks

Write your questions

Each research objective should have one or more questions that try to find an answer. Some rough examples are here: 

A table. It shows research objectives in one column (how difficult a level or challenge is) and a matching survey question on the other side (how easy or difficult was this level)

Scales are a very common way of capturing answers to surveys and can include:

An overall numerical score – asking players to rate something out of 10.

A two-directional scale – with two conflicting ideas on each side of the scale. Make sure that they are opposites, or this one gets confusing. For example (“Very bad” to “very good”)

An agreement scale – asking players if they agree with a statement. (“Strongly disagree” -> “Strongly agree”)

When writing the text for your questions, keep the following points in mind:

  •  Will my player understand the question? Do they know what I’m asking about. Do I use language they are familiar with.
  •  Will they be able to remember the thing you are asking about? Are we asking about something that is recent enough for them to have a real opinion?
  • Will they be able to decide on a correct answer? Is this something they actually have an opinion on? And are they comfortable telling you the answer, or is it socially embarrassing to say?
  • Will they be able to enter the answer that matches their true feeling? Make sure your scale will allow them to give their true opinion. Asking them to rate from “neutral” to “good” is no help if they think it’s “bad”

A really powerful combination is combining rating questions with a open-ended question asking ‘why’ This does not replace interviews though, because a survey doesn’t allow the deep interrogation that is often required to really understand what players are thinking or doing.

Some tips for questions:

  • Avoid leading players by providing opposite statements in the question text e.g. instead of asking how difficult was the game, ask how easy or difficult was the game.
  • Bold key words in the question, so it’s easy to pick up the meaning from skimming it: How were the graphics in this level?
  • Keep question text short and direct, so they are easy to understand. Rate this level is clearer than Please provide a rating based on what you thought about this level
  • Be clear – use the same words that players do (interviews can help reveal this), and avoid jargon. What did you think about this character’s DPS won’t make sense to many players.
  • As with interviews, a good structure is to go from broad questions to direct questions. Ask ‘overall, how was the game‘ before asking specifics such as ‘how easy or difficult was using the jetpack’
  • Avoid yes/no questions as they are too closed and force players to give strong binary answers. Rating scales, or asking players to explain, allow more nuance to emerge.
  • Keep the survey short.
  • Never ask about future behaviour. Questions like will you buy this game have always been to correlate poorly with real behaviour, giving you unreliable conclusions. It’s much safer to ask about things they have previously done “What was the last game like this you bought” to get answers that are accurate

I’ve also gathered some excellent tips for survey design from the community. Find them all at the end of this section.

Pilot your survey

Ask a colleague or friend to answer your questions before you send it to players, and ask them what they think each question means. Doing this while sat with them, allows you to ask them questions about each question as they fill it out. This quickly reveals where they haven’t understood your question or the words you use.

Make your playtest survey for real

Use a survey tool to create your survey for real. Google Forms is free, and has some basic survey logic so can be appropriate for simpler surveys. 

More advanced tools, like SurveyMonkey or Qualtrics can be a good next step once you’ve reached the limit of what Google Forms can do.

Distribute your survey

Send your survey out to participants (or ask them to fill it in after coming in for a playtest). The best method of doing this is probably clear after doing the work to ‘decide your sample’ earlier.

Analyse the findings

Analysis is a whole topic in itself, but before we get started, we need to clean up our data.

I personally would always recommend exporting my data into a spreadsheet, rather than using the survey tool’s built in analysis tools, to help explore it. We looked in a previous issue at some tips for how to handle quantitative data

The data we have collected will usually have some issues with it. Some people will not have filled out the survey properly, and would have clicked through as fast as they can, or given some impossible answers, and we want to remove them from the data set. Read through the responses, review the start and end times to see how long people took on the survey, and look out for tell-tale signs such as ‘rating every question the same’ to indicate which participant data needs to be removed.

Analysis and finding meaning in the data is another skill to practice – but we’ll save that for a future newsletter deep-diving into analysis. 

Learn more about writing playtest surveys

When writing this post, I asked the community for their tips. I received so many that I had to spin them off into a separate post – read the expert tips for writing a playtest survey.

Elizabeth Zelle (who kindly submitted some of our expert tips), gave an excellent talk about survey design for games at a previous GRUX conference. Watch Elizabeth’s talk here

I also am a huge fan of the work of Erika Hall, and it would be remiss of me not to link her post about the dangers of surveys. Essential reading before you write your own.

Author image

Meet the author

Steve Bromley is an expert user researcher, who works with studios of all sizes to run playtests, and integrate user research into the game development process.

Learn more

Keep Exploring

How much to playtest

How much playtesting is enough?

When to start (and stop) playtesting throughout game development.

Scope Studies For Impact

Scope your studies to increase research impact

How to scope games user research studies for impact – uncovering the context for decision making, and setting sensible objectives.

budget for games user research

How to budget for games user research

How much does user research cost, what to budget for user research, and how best to spend the budget you have to de-risk game development.

Master Games User Research

Free monthly new articles teaching playtesting & how to be a games user researcher. Join the most interesting conversations about games user research, discover job opportunities, and be introduced to new ways to think about game development.

Which best describes you?(Required)