Recently, I was on the Professor Game podcast and was asked if I had one piece of advice for someone who was going to make educational games. I said,
Test your game early and often with actual students and teachers. None of us are nearly as good as we think we are at guessing what students will find engaging to play or difficult to learn.– Me
Changes we made earlier due to co-design
As one of the National Science Foundation VITAL Prize finalists, we are provided with an educator consultant. Ours works for a school district in Ohio. (Shout out to Isabel). We also have been meeting with teachers, students and others in the ecosystem (think museums, after school programs). Here are some of the changes we made as a result of those discussions.
Our in-game assessments already signified with sound (a happy or annoying sound), color (green or red), texture (solid or dashed border) and text, if you got it correct or incorrect. Players also have to click on the box to continue so at least they had to interact with it. They couldn’t just click, click, through a game without paying attention to whether they were right or wrong. Teachers loved this aspect of the assessments.
However, they wanted us to make two changes. First, there should be an option to direct players to a DIFFERENT next block if they get it wrong, but it should be OPTIONAL. As one teacher said,
Sometimes, I want every student to see the material, whether they got the answer correct or not, because I want to emphasize it. Other times, I just want re-teaching for kids who missed a concept.– VITAL Prize Discovery Round teacher
The second change they wanted to see was, an optional hint button, where they could give the player a hint, like “To divide one fraction by another, invert the second fraction and then multiply.”
Here is where the co-design part came in. As developers, we think of things like, “Well, what if there isn’t a hint?” As experienced educational software developers, we know that sometimes users forget, don’t want or don’t have time to include an incorrect URL or hint. The software should still work. However, if there is no hint, it will be confusing to have a hint button that does nothing.
So, we coded each problem that if a hint is provided, the hint button appears in the top right corner, and if there is no hint, it doesn’t.
Then, there was the student aspect. Does the game actually work to teach? Because we are still in the design phase, we just tested each level with two or three students.
All levels were tested with a student at the targeted grade level, and then, usually, a student below and above that grade level.
The four test points were:
- Did they understand the instructions, what they needed to do, with no assistance?
- Were the students at and above grade level able to complete the task?
- Did the below grade level student find the task difficult?
- Did the students, especially the grade-level tester, find the task sufficiently engaging that they completed it without complaint, excuses or quitting the task?
All of these decisions, to keep some features and add others, I am certain would have happened the first time it hit a classroom, but working with teachers as co-designers pushed these changes earlier in the design process – and that’s a good thing.
There was a lot more that happened, but I need to get back to coding those changes. If you’re interested in developing educational software yourself, check out our 7 Gen Blocks.
If you’d rather we do the heavy lifting, we’d be happy to develop learning software for you, probably at a cost far lower than you think.