Game Design A Of Lenses

Working Through Game Design A Of Lenses in Practice

Jesse Schell's book came out in 2008 and quickly became one of those references everyone on a game dev team owns but rarely opens cover to cover. The framework is straightforward: over 100 lenses, organized into roughly six categories — the game itself, the player, the story, the technology, the business, and the fun. Each lens is a question or a perspective you can apply to any design problem. That's the simple part. The hard part is actually knowing when to reach for a lens and what to do when two lenses contradict each other. Here's the thing most people miss. The lenses aren't meant to be worked through in order. They're meant to be picked up, used, and put down depending on what's breaking in your project. I've seen teams treat the book like a checklist, going lens by lens, which takes forever and produces shallow results. Better approach: pick the single biggest problem your game has right now and find the lens that addresses it directly. If your player retention is tanking after the first level, pull up the "Player" section and start there. Don't waste time on the "Business" lens while your core loop is clearly the bottleneck.

Game Design A Of Lenses for Real Projects

The practical workflow I use is: identify the design decision or problem, map it to a category, then pick 3-5 specific lenses that interrogate that problem from different angles. For example, if I'm redesigning a combat system, I might grab Lens 6 (What is fun? — actually, dig into the specific fun sub-questions), Lens 47 (What are the player's goals?), Lens 59 (What is the player's motivation?), and Lens 95 (What is the emotional appeal?). Those four lenses together will expose gaps that no single perspective catches. I ran into a specific edge case a few years back working on a mobile puzzle game. We had designed what we thought was a solid difficulty curve, but playtest data showed players quitting at exactly level 7 every single time. We went through half a dozen lenses trying to figure out what was wrong without landing anywhere useful. Then Lens 23 hit me — the one about what the player is doing at each moment. We broke down the actual session at level 7 and realized the core mechanic they needed hadn't been introduced until that level. Players were being thrown into a situation they literally didn't have the tools to handle yet. We restructured the tutorial flow and the drop-off disappeared. The lens didn't solve it for us. It pointed us at the right place to look. One counter-intuitive insight that comes from actual use: the lenses that feel least useful at first are often the most important. The "emotional appeal" and "psychological" lenses seem fluffy until you're three months into development and your game works mechanically but nobody cares about it. Those lenses force you to articulate what the player should feel, not just what they should do. Another thing beginners consistently get wrong is assuming each lens gives a definitive answer. They don't. They're diagnostic tools. The answers come from your team's judgment applied to whatever the lens reveals.

The six categories serve as a mental filing system but they overlap constantly. A lens about story can inform mechanics. A lens about business constraints can reshape the player experience. Don't treat the categories as walls. They're just drawers in the same cabinet. There are real limitations to this approach. First, the book describes lenses but doesn't teach you how to synthesize conflicting answers. When Lens 12 says one thing and Lens 67 says another, you're on your own. That's where experience matters more than the framework. Second, the lenses were written primarily for traditional and digital entertainment games. Applying them to educational software, serious games, or simulation-heavy titles requires modification. The framework isn't universal out of the box. Third, and probably most importantly, using all 110 lenses on a single project is roughly equivalent to spending three weeks in meetings. You will not do that. Pick your battles. Most games only need 15 to 25 lenses applied thoughtfully across the development cycle. For a physical copy or eBook, you can find it at Jesse Schell's site or any major bookseller. It's titled The Art of Game Design: A Book of Lenses. There's no software companion or interactive version — it's just the book. The PDFs floating around the internet are pirated and frankly outdated since the second edition added new lenses. Buy the second edition if you can.

A practical tip that isn't in the book: print out your top 20 lenses and tape them to your wall. When the team hits a design deadlock, someone should walk over to the wall and read the lenses aloud. Hearing them spoken out loud changes how people engage with them. The act of reading Lens 43 ("What would the opposite look like?") out loud in a room full of designers always produces at least one idea nobody had considered before. It's a small ritual but it works consistently. The framework also works as a onboarding tool for new designers on a team. Give them the relevant section of lenses and ask them to apply five to the current project. Their blind spots become visible immediately, which is valuable whether they're a junior or a senior hire. It surfaces thinking patterns you wouldn't otherwise see in code reviews or design docs. If you're starting a new project from scratch, I'd recommend reading through the entire book once before you write a single line of design documentation. The second pass, the one where you actually use the lenses, happens naturally as problems arise during development. You don't need to memorize anything. Just know roughly what's in each category and you'll find yourself returning to the right pages automatically.