Last year I worked on a prototype developed for young kids in the age of 5 to 8.
I did a lot of prototype testing during the process, and I’m going to share my experiences about that in this post.
When I started the project, the fact that my primary user group was kids didn’t really concern me or take much of my focus. For some reason it seemed to have more effect on the visual design than on anything else.
But that changed once I sat down with the first couple of kids to do an initial prototype test. Boy did it change! The session was a disaster. A disaster from a “result” point of view, because I didn’t really get a lot of usable results from that first session. The reason? The kids were simply too unstructured for my structured approach.
I had done all the preliminaries: I created a test plan with objectives etc., written down some thoughts on user tasks, found the proper location and so on.
When it came to the actual test session, I did what I usually do: I introduced the kids to the environment they were about to test, I started to explain how the test would take place… and then the session took on a life of its own. Because kids, as I found out, are very, very different test subjects than adults!
Long story short, I’ve summarized some of the issues I occurred, and how I solved them. I hope they will become useful to you, if you ever get to test stuff on users aged under 10.
1. Kids can’t think aloud!
Not in the way we need them to in a traditional think-aloud test that is. Yes, they express emotions, like joy, excitement, disappointment etc., but formalizing their thoughts into output that would be useful data to us as usability testers, they cannot.
2. Introduce – observe
Because kids have a natural “try-fail-try-learn” approach to what they’re exposed to. And because they’re not afraid of failing and trying again 100 times in a row to get something right (an ability we sadly tend to lose as adults), they are not very likely to take a safe and “read-instructions first” approach to what you want them to test. They will simply click and see what happens.
That leaves you in a bit of a painful situation as a test facilitator, because you will have to go along with their attitude, and simply introduce them very shortly to the prototype and then set them free. You can probe them along the way to nudge them into areas of the interface, that you want them to try out, but you can’t control their user path.
The upside of that is that you get to observe the users’ natural behavior, as opposed to very controlled test sessions with adults who sometimes don’t give you their honest input (because they hate feeling stupid, even though we always tell them “we’re testing the site, not you!”)
3. Test at least twice in the same session
Since the kids are so fast and spontaneous in their way of interaction, and since you can only use probing to test specific areas, it is useful to ask them to play with the interface twice in the same session, and probe them to try the same features in both sessions. This will give you more precise observations.
I’m sure there are more things to consider when testing usability with kids, but these were my top 3. If you have anything to add, feel free to leave a comment!