What a seven-year-old taught me about playtesting

My son Jacob is seven years old and he is the best playtester I have ever worked with. He can barely read, he can't articulate why a thing is bad, and he has no understanding of what code is. None of that matters. What he has, that I don't, is zero patience for nonsense.

I want to write down some specific moments because I think they generalise. If you build games — or really any software for non-technical users — these are the kinds of things you will learn the hard way unless you have a small human in your house who will tell you, with absolutely no diplomatic filter, that the thing you just spent four hours on is bad.

The flap that was too floaty

When we were building Flappy Dunk — which started as Jacob's pitch, "what if the flappy bird was a basketball and the pipes were hoops?" — the first playable version had a flap that I'd carefully tuned for what I thought felt like a "real" basketball arc. Slow rise, slow fall, gentle gravity. I was proud of it.

Jacob played it for thirty seconds and said, "Daddy, why is the ball so slow? It doesn't feel like a basketball, it feels like a balloon." He was right. A real basketball has a snappier rebound than I'd given it. I had been so focused on making the physics "correct" in some abstract way that I'd missed the much more important thing, which was matching the player's mental model of what a bouncing basketball feels like. Two hours of retuning gravity and I had something Jacob actually wanted to keep playing.

The button he couldn't see

In an early build of Decision Wheel, the spin button was in the top-right corner. It was clearly labelled. It was a big button. Jacob played for a minute and asked, "where do I make it go?" I pointed at the button. "Oh," he said, "I didn't see that."

It turns out that when you can't read fluently, you don't scan a page the way an adult does. You look at the big colourful thing in the middle, and if there's no interaction affordance there, you assume the thing is broken. Adults will read the whole page looking for the button. Kids will close the tab. I moved the spin button to dead-centre under the wheel and never had the problem again. I now do this on every game by default. Centre the primary action. Don't make a kid hunt.

The unfair death

Frog Hopper had a bug in an early version where the frog's collision box was slightly larger than the visible sprite. The visible frog would clearly clear a car, then die. As an adult, I would have shrugged and said "the hitbox is a bit generous, fair enough." Jacob played it twice and threw the iPad face-down on the couch. "It's not fair. I made it past the car."

The thing is, he was right. Players don't see hitboxes; they see sprites. If your sprite clears the obstacle, the player should not die. This is now an iron rule for me. Make the hitbox a little smaller than the sprite, never bigger. It feels generous to the player, which makes them think they're skilled, which makes them want to play more. Forty years of arcade design knew this. I had to be told by a seven-year-old.

The loading screen that ate his attention

One game I won't link because I rewrote it after this lesson had a fairly typical "Loading..." screen with a spinning circle that showed for about three seconds while assets fetched. Jacob saw the screen, waited about a second, said "this game is broken," and left. Three seconds is not a long time to an adult. It is several lifetimes to a seven-year-old. Every game on the site now either ships its assets inline so there's nothing to load, or it shows something interactive while it waits — even just a button you can click to make a sound. Nothing dead.

What changed for me as a designer

The pattern across all of these is the same: I was designing for the version of me that would patiently push through small frictions, instead of for the actual humans who would not. Kids amplify that. They show you what your friction budget really is, because they have none.

If you don't have a seven-year-old at home, the workaround is to playtest with anyone outside your engineering brain — a non-technical friend, a partner, a parent. Watch their hands, not their face. The moment they hesitate, you've found something to fix. The moment they put the device down, you've shipped too late.

If you do have a seven-year-old, listen to them. They will be ruthless. They will also be right.

— Chris