DEV Community

Cover image for The Scoring Gap: What a Carnival Shooter Teaches Us About Real Design
Sam Novak
Sam Novak

Posted on

The Scoring Gap: What a Carnival Shooter Teaches Us About Real Design

There’s a story Jesse Schell tells in The Art of Game Design that every developer and designer should have pinned to their desk.

It starts with a carnival shooter game built for families. During playtests, everyone was having a blast—moms, dads, kids. The smiles were there, the engagement was high. But the data showed something odd: Men were consistently outscoring women.

The team dug in, expecting a skill gap. What they found was a behavioral gap.

The Men: Tended to "spray and pray," firing as fast as possible to hit as many targets as possible.

The Women: Tended to slow down, line up their shots, and play for precision.

The game only tracked raw points. Because "spray and pray" generated more hits per minute, the system quietly rewarded one strategy and punished the other. The fix? They added a second score column for accuracy.

The mechanics stayed the same, but the experience changed for half the audience. Suddenly, both styles had a way to "win."

The Demographics Trap
It’s easy to look at that story and see a "gender" lesson. It’s not. It’s a behavioral lesson.

As devs, we often build "loops" that accidentally favor a specific type of user:

Tutorials that assume you already know the genre's "unspoken" rules.

Scoring models that only value speed over quality.

Onboarding flows that ramp up in difficulty only if you’ve used similar SaaS tools before.

These aren't demographic failures; they are observation failures. When we only reward one interpretation of our system, we leave users behind without even noticing they were there.

"A Game for Everyone is a Game for No One"
We hear this mantra all the time. It’s about 60% right. If you sand off every edge to please everyone, you end up with "design oatmeal"—bland and unmemorable.

But there’s a better way to read it: Make your system readable from multiple angles.

Think about RPGs. They’ve mastered this for decades. A world contains tanks, healers, glass cannons, and stealth players. They all exist in the same ecosystem, but the system supports their distinct behaviors. That’s not a compromise; that’s depth.

Playtesting > Personas
The reason Schell’s team caught the issue wasn’t because they had a "Female Persona" slide in a deck. It’s because they watched real humans play.

The most important skill for a designer isn't creativity—it's listening.

Creativity gets the prototype built.

Listening tells you if the prototype actually works.

Designing Beyond Yourself
The old advice "Design the product you want to use" is a great starting point, but it's a terrible finish line. You are one person with one set of habits. A pacing choice that feels "snappy" to you might feel "stressful" to someone else.

The goal isn't to please the entire planet. The goal is to ensure that if your audience is narrow, it’s because you intended it to be—not because you accidentally locked the door on everyone else.

The Takeaway
Don’t design for demographics. Design for behaviors. Watch how people actually use your software. Notice when two groups approach the same system differently. Then, ask yourself: Does my design reward those differences, or does it punish them?

The gap between a product that accidentally excludes people and one that purposefully serves a focused audience is the gap between carelessness and craft.

Want to dive deeper into how we apply these design principles?
You can see more about this and other deep dives over at our blog:
👉 https://itembase.dev/blogs/design-for-behaviors-not-demographics

Top comments (0)