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!


2 Responses

  1. I am usually meet with the one problem that kids are so spontaneous and dynamic in their way of interacting that you can rarely, put them in front of a piece of software without already have ruined the genuine kids interaction flow from there on – because as soon as you place them, and give them a task, you loose them… as long as they are left with the feeling “what is it you want me to do…” you wont get the real interaction flow – because most kids dont understand the concept of “user testing” even if you explain it to them. Kids need to have the feeling that they are the ones who decide, they are the ones in control. You take that away from them by placing them with a task… which can simply be: “here try this…” as long as you watch silently, some will still think “why are you watching, what is it exactly you want me to do with this…” – adult user testing involves somewhat the scenario of “acting” – acting as real user… kids have a hard time doing that… the only way i see it done, is by having so emersive content that they put them self in “flow” everything else will be somewhat false behavior, because they cant act it out… either they will love it or hate it, in that case they just do what they hope you want them to do…
    The intrinsic motivation factor is key, both with adult and kids usertesting… with adults, we are able to try and recreate the user journey..
    But the real behavior, the underlying reason on why the user feels the need to visit your software is missing, which is a major missing link for small kids.

  2. Hi Philip,
    Thanks for the input. I agree that there is no such thing as a “true” user journey or experience in a usability test environment with kids – but I would argue that the same is the case with adult test subjects. But it’s tricky, because it’s hard to filter the observations to get to the natural user behavior. It’s also essential to have a high fidelity prototype to test on. There is no way you would be able to test on a paper prototype with kids, as their abstraction level is very low.

Leave a Reply

Your email address will not be published. Required fields are marked *