I’ve been working on the technical aspects of a new class (well, new to me and to our program, anyway) on game usability and UX. Today I built two student assignments that will be play tests, one of a video game and one of a tabletop game. It made me want to take a moment to post a “what I think I know” post.
So here’s Phill’s five keys to a good play test.
- You need to put the game in the correct context. Sometimes building a focus group, or having a group of co-workers help you play test, just isn’t the right approach. Take, for example, a Dungeons & Dragons module. You need to find a specific group with experience together, and players who understand the basics of the rule system, in order to test that successfully. You don’t want your play test to be the narrative of a gaming group who couldn’t mesh. That’s not your game’s fault in most cases.
I’ve had my classes test modules with each other in class before, and time and time again I see the same refrain: “we don’t know the game well enough to talk about it.” It can also give a play tester an excuse to kind of “give up,” and you don’t want that sort of person tanking your data.Likewise, a sports game will be better tested by fans of that sport, a game using a property will be better judged by the fans of that property, etc. It’s basic rhetoric, but it’s important to remember.
- Don’t wait too long. It’s typical that people want to wait until they have an alpha build (or even a beta) to test a game, but user and play testing needs to start way earlier than that. You can user test a concept. You can play test from the first most basic prototype. And you should. If you don’t, there could be miscalculations you could have fixed when your game was a doodle in your notebook that exist in your beta build.
- Don’t over-do it. I found a reading today that says that 5 people is the perfect test size. The logic behind that is sound. I wouldn’t hesitate to expand a bit (it would be good to get a diverse sample, and it’s hard to get all the diversity you’d need from a group of five), but I think pushing past around 15 is a waste. Remember that you don’t necessarily need a huge mass of data. You need enough to see trends. It’s better to test quickly and iterate than to stagnate and test repeatedly.
- But you need to hit diversity. This is one of the problems that cuts across games– development, marketing, representation– so it clearly applies here, too. If you only have white guys play test your game, all you really know is what white guys saw, thought, experienced. You need to bring in women, people of color, and you need to try to not pick all fans of a specific genre or type of game. That might seem like it’s at odds with my first point, but the whole key is balancing things. You want your play test pool to look like your presumed audience.
- It’s better if you don’t conduct the test for your own game. This can be hard to avoid if you’re doing a small project, but generally speaking, YOUR bias, and the way you might frame questions and present ideas, could seriously taint your play testing. You’re better off having someone else do that work and seeing the data without watching the data as it comes in. You don’t want your knowledge of the person who makes a comment to cause you to take the comment in a context other than it was intended, e.g. “he just hated our game anyway!” It makes it too easy to ignore valid criticism and destroys context.
Happy testing!