Most Important Skill for Developers – Adaptability

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!