Know Your Audience
As the Lead Game Producer here at Second Avenue Learning, part of my job is to make sure the vision for the product we’re building remains clear from the time the project is greenlit through shipping. As a studio that leverages Agile development methodologies, the fine details of the project change frequently based on a number of factors, but the target audience always remains the same. An Augmented Reality game designed to teach elementary-level math in the design document should not feature trigonometry in the final product.
That’s an extreme example, but the point is that it can be easy to lose sight of the original goal over the course of development as the minutia changes. We’re constantly learning and adjusting not just from project to project, but from sprint to sprint. Feedback comes from many directions: Internal build reviews, external playtesting, executive or client presentations and even 10 minute conversations by the Keurig machine. All of this feedback is aimed at improving the final product but with limited time and resources, concessions must be made, and should always be made with the target audience in mind.
This has been true for me in my many years of experience producing entertainment-level videogames, but has proven to be even more important in the serious game space. Activision wants as many people as possible to buy the latest Call of Duty installment and designs the games with this in mind, but in the educational and professional development space we often have a very specific type of end user we’re targeting. We ensure the small decisions made make along the way don’t end up alienating the target audience by checking in with them throughout the design and development process.
Find the Pain-Points
We’ll often start a new project by talking with teachers, instructors and parents about the pain points of teaching a particular topic – where they struggle the most, where most students disengage – and start designing something that addresses those points. If we can find those points and address them in our product, even in a small way, teachers will see the value in what we offer right away. We also design to the strengths of our medium. Serious games and simulations can explore concepts in ways other mediums cannot. We can slow down, pause or rewind time, for example, to better illustrate a scientific concept. We can allow users to interact directly with tools or concepts that would be dangerous or cost-prohibitive in the real world. This adds another layer or value to teachers as they can use our products to supplement the teaching methods they’re already using. Thinking about these points early in the process helps ensure the needs of the users are in the very DNA of what we’re building.
Test Early, Test Often
One of the most important things we do during development is test our ideas with members of the target audience and those who know them best. Usually in our world this means students and their teachers or parents. As we start designing specific mechanics, we’ll identify any pieces we think would benefit from hands on testing and prioritize them. We can then put early versions of those mechanics in front of players and see how they react to them.
While we typically have testers answer questions or write up their feedback after the test, the best feedback comes from simply watching how testers interact with the prototypes. Do they struggle to understand what is required of them? Do they need to ask us questions beyond the information we provided at the tart of the test? Are they staying reasonably engaged as they interact with our prototype? Oftentimes testers’ accounts of how their experience went in a post-session debrief will differ in some ways from what we observed during, so it’s important to pay attention while the testers are engaged.
We’ll make changes based on the feedback we collect, and then retest with some of the previous testers. We’ll also add new testers to the mix, to see if they struggled with the same things the previous group did after our changes. Testing early and often allows us to ensure that most users’ expectations are met once we’re ready to ship.
Be Ready to Scrap Ideas
Recently while designing a math app for elementary school kids, we came up with what we thought was an interesting mechanic for how players enter their answers. We didn’t want to take up a large portion of the screen with the default software keyboard, so we came up with something we hadn’t seen elsewhere and prototyped it. We all loved it internally but had concerns that it may not work well enough for someone with a 6-year-old’s motor skills. We developed the input prototype a bit further and put it in front of kids to see if they struggled with it and were thrilled to find out that all of our testers could use it with ease! Great news! We folded the mechanic into the main game and continued development.
At our first big playtesting session for the game itself, the flashy new input mechanic was in place, along with simple arrow buttons players could use to choose their answer as an alternative. To our surprise, almost all of the testers ended up settling on using the arrows exclusively by the end of the session, even though it was a bit slower and more cumbersome. It turns out users of that age will be drawn to what’s familiar and comfortable for them. After some internal discussion, we decided to scrap any further work on the new input mechanic and ship with a more familiar UI. Even though the mechanic itself tested well and we all liked it internally, there’s no point in including it if your users aren’t interested in it.
It’s critical that we’re aware of the needs of our end users and put as much focus as we can on what’s most important to them, or we’re not really providing anything of value. Regular check-ins and testing help us stay on that target, and being willing to walk away from things we personally value ensures that the users always come first. And you better believe we’ve got that fancy input mechanic on the shelf and ready once we find the right fit for it!