How do you research a game nobody will take a user interview for?

Standard UX research methods — lab studies, moderated usability tests, contextual inquiry, think-aloud protocols — were built for enterprise software and consumer web apps. Casual F2P mobile games break several of their assumptions at once.

The primary player is 45+, global, playing in 3-minute snatches between other things. They are exactly the demographic least likely to accept a Zoom interview about a word puzzle. Even if they did, the Hawthorne effect would distort what you measured — being observed playing a casual game reshapes the play. The whole point of a casual game is that no one is watching.

You have, instead, two kinds of data. Hard quantitative signals — retention curves, session length, conversion funnels, A/B test deltas — tell you what is happening but not why. And the game's own surface — every competitor's build, every screen, every loop, every monetisation hook, observable to anyone with the App Store and patience. The research strategy has to do most of its work in that second register: the games themselves as the research substrate.

Over six months, the work became a small library of repeatable frameworks — three in particular did most of the heavy lifting. This case study is about those three.

The Onion Peel method treats a game as a set of nested systems. At the centre sits the core mechanic — the single action a player repeats that defines the product. Every other layer orbits it, adding complexity and meaning the further out you go.

The seven rings, from inside out:

• Core mechanic — the repeated action that makes the game a game. In Crossword Jam, it's "swipe letters to form a word." Strip this out and nothing works.
• Core loop — the immediate features that wrap the mechanic: puzzle → reward → next puzzle. Everything that directly touches the core action every session.
• Secondary loop — features that support the core loop without being part of it. Hints, undo, difficulty ramping, lives/energy.
• Progression system — the circular progression of play; level maps, world unlocks, the sense that the player is moving somewhere.
• Meta layer — systems that reward the core loop and give the player reasons to return between sessions. Collections. Daily missions. Event calendars. (The same layer where the Collection System case study lives.)
• Economy / monetisation — the shop, the coins, the ad placements, the IAP surfaces. Interacts with every inner layer but deserves its own frame because it has its own logic.
• Social — anything that makes the game social: friends, leaderboards, tournaments, clubs, gifting. For many casual games this ring is thin; for some it's the whole product.

Placed side by side — Crossword Jam and its direct competitors across the same seven layers — the Onion Peel surfaces a shape of investment. Two games may look similar at the core and differ sharply at ring 5 or 6. One game may be hollow in the middle but heavily social on the outside. Those shapes are arguments: we are under-investing in meta compared to peer A; we are over-investing in social compared to peer B; our economy ring does twice the work it should because layer 5 is empty.

The framework also composes with others. The meta layer at ring 5 is exactly where the Collection System proposal eventually landed — that case study is a direct downstream artifact of a competitor teardown that showed meta-hollowness across peers.

Where Onion Peel answers "what layer is this feature on?", the System Map answers "what does this feature connect to?". It's systems thinking in the lineage of Donella Meadows — nodes and edges instead of rings.

Each feature is a node. Each feature also belongs to one or more loops (core / meta / social). Edges connect features that reinforce each other: shared state, shared rewards, shared player motivation. The map is colour-coded by loop — a blue node sits in the core loop, yellow in meta, green in social.

The insights come not from the nodes but from the edge density. A feature with five strong edges is load-bearing; tearing it out breaks four other features. A feature with one edge is an orphan; it may be live in production but it's floating. A loop whose internal edges are all thin is a loop that looks like a loop but isn't actually closing on itself — the player isn't getting pulled back by anything.

Two structural patterns recur, once you start drawing these maps:

• Many casual games ship dozens of features that have no edges into the main loop. Each was someone's pet project, correct in isolation, disconnected in aggregate. The map makes this visible in a way a feature list doesn't.
• The opposite pattern — two features nobody thought of as linked, turning out to share a reward currency or a progression trigger, accidentally propping each other up. Rippling out this kind of link into a design intent tends to produce the biggest quick wins.

Ran across a set of peer and adjacent casual word games, the three frameworks produce a single comparative artefact — a long-form teardown that places each competitor next to the others along the same axes. Below: a composite of that work.

Running the same three frameworks across ~8 competitors stops being a research exercise and starts being an argument-generator. Every feature pitch at the subsequent product-planning session could be anchored to: "peer A invests here, peer B doesn't, we're between them; based on the System Map this change would reinforce the meta layer without destabilising the core loop; Octalysis says we'd be paying Drive 4 and borrowing from Drive 6, which is fine because we're currently over-indexed on 6."

That kind of argument is only available to a team that has done the teardown work. The whole point of the toolkit is that the work, once done, is durable. The Onion Peel diagrams age well — the layers themselves don't shift even as specific games update. The System Maps take a week to refresh. Octalysis audits take a day. This is why the frameworks were the deliverable, not the individual reports.