The Rules Are the Interface: What Board Games and RPGs Teach Us About Technology

Every System Is a Game

Every piece of technology you use is a game. That's not a metaphor stretched to fit a headline. It's a working definition. A game is a set of rules, a set of goals, and a set of feedback signals that tell you whether you're getting closer to those goals. Your banking app has all three. So does your email client, your smart thermostat, your company's expense-reporting system, and every AI chatbot that has ever told you it can't help with that.

Most of us don't think about technology this way because nobody hands us a rulebook. We learn the rules by poking at the system until it pokes back. We find out a password needs a special character only after we've typed one without it. We discover the spam filter's logic only when an important message lands in the junk folder. The rules are there. They're just hidden behind the interface, and sometimes the interface is the rules.

Tabletop gamers have a different relationship with rules. When you sit down to play a board game or a tabletop role-playing game, the rules are on the table, literally. Someone opens the box, unfolds the rulebook, and reads it aloud, often badly. Players argue about what a sentence means. They look up edge cases. They house-rule the parts they don't like. Over a few years of regular play, a hobbyist builds a remarkable set of instincts: how to learn a system quickly, how to spot a rule that will break the game, how to tell when a player is technically correct but ruining the evening for everyone.

Those instincts turn out to be exactly the ones we need in a world shaped by software, algorithms, and increasingly by artificial intelligence. The people who design board games and the people who design technology face the same core problems. How do you teach someone a system they've never seen? How do you reward the behavior you want without rewarding behavior that only looks like it? What happens when one player gets so far ahead that nobody else can catch up? Where do rigid rules need to give way to human judgment?

This article walks through those problems one at a time, using examples from the gaming table to shed light on the screens we stare at every day. You don't need to be a gamer to follow along, and you don't need to be an engineer. You only need to accept one idea: the rules are the interface. Whoever writes the rules decides how the experience feels, who wins, who loses, and who gets to change the rules next.

If you play games, you already know more about technology design than you think. If you build technology, the hobby has been running free experiments on your behalf for decades. Either way, it's worth pulling up a chair.

The Rulebook Problem: Teaching a System Nobody Asked to Learn

Ask any group of board gamers what the worst part of the hobby is, and many will say the same thing: learning a new game. Not playing it. Learning it. A thick rulebook full of icons, exceptions, and phrases like "see page 14" can kill a game night before the first turn.

Good game designers know this, and the best of them treat the rulebook as part of the game's design, not an afterthought. Over the years the hobby has developed a toolkit for teaching that any software team would recognize.

Learn by playing. Many modern games ship with a "first game" setup or a scripted tutorial scenario. Instead of reading forty pages before touching a component, you read four, start playing, and learn the remaining rules when they become relevant. Software calls this progressive disclosure: show people what they need now and reveal complexity as they grow into it.

Reference cards and player aids. The most useful sheet of cardboard in many boxes is the one-page summary of a turn. Experienced players rarely re-read the rulebook. They glance at the aid. This is the equivalent of a well-designed menu, a keyboard shortcut cheat sheet, or a clear status bar. It assumes you already know the concepts and just need a reminder of the sequence.

Iconography that means one thing. Good games use a symbol consistently everywhere it appears. Bad games reuse a symbol for two slightly different ideas, and players spend the whole night arguing about which meaning applies. Software suffers from the same problem when a trash can icon sometimes means "delete forever" and sometimes means "move to a folder you can recover from."

Components that teach. In a well-made game, the physical pieces suggest how they're used. A card with an arrow on one edge wants to be placed next to something. A board with a numbered track around its border is obviously keeping score. Designer Don Norman, in his classic book The Design of Everyday Things, popularized the idea that objects should communicate their own use, so a door handle tells you to pull and a flat plate tells you to push. Board games are full of these affordances, and the best ones reduce the rulebook to a confirmation of what the components already suggested.

The lesson for technology is simple and routinely ignored. Documentation is not where you explain a confusing system. Documentation is where you confirm a clear one. If your users need a manual to perform the most common task, the problem isn't the manual.

The gaming table also teaches something about who does the teaching. In most groups, one person reads the rules ahead of time and explains the game to everyone else. That person becomes the interpreter, and their explanation shapes how the whole table understands the game, mistakes included. Groups regularly discover months later that they've been playing a rule wrong the entire time.

Technology has the same dynamic, and AI is making it more visible. More and more people now learn software by asking an assistant how to do something rather than reading the help pages. That assistant is the friend who read the rulebook. When it explains well, onboarding becomes painless. When it confidently gets a rule wrong, users may play the game incorrectly for months without knowing. The takeaway for builders is to make the system self-explaining enough that a mistaken explanation gets corrected by the interface itself. The takeaway for users is the one every gamer eventually learns: when something seems off, check the actual rulebook.

Players Optimize What You Score, Not What You Meant

Here's a piece of game history that surprises people. The ancestor of Monopoly was designed as a warning. In 1904, Lizzie Magie received a patent for The Landlord's Game, which she created to show how concentrating property in a few hands drives everyone else into poverty. The game was meant to make players uncomfortable with the outcome. Decades later, a descendant of her design became one of the best-selling board games in history, and most people play it to enjoy bankrupting their relatives.

What happened? The scoring system won. Whatever a designer intends, players chase what the rules reward. Monopoly rewards accumulation and elimination, so that's what players learned to love. The intended moral lesson lived in the designer's head. The incentives lived on the board.

Gamers see this constantly. Give players points for a behavior, and they'll find the cheapest possible way to earn those points, even if it defeats the spirit of the game. Competitive players call it "playing the rules, not the theme." Game designers call the most extreme versions "degenerate strategies": approaches that are technically legal, wildly effective, and boring or miserable for everyone at the table. A good playtest process is largely a hunt for degenerate strategies before the public finds them.

Economists have a name for the broader phenomenon. Goodhart's Law, usually paraphrased as "when a measure becomes a target, it ceases to be a good measure," describes what happens when people are judged by a number. The number stops reflecting the thing it was meant to track, because people learn to move the number directly.

Technology is full of Goodhart traps:

• A social platform that measures success by time spent in the app will tend to promote whatever keeps people scrolling, which isn't always what leaves them better informed or happier.

• A customer support team scored on how quickly tickets are closed may close tickets quickly whether or not the problem was solved.

• A software team measured by lines of code written will write more lines of code, which is rarely the same as writing better software.

• A recommendation algorithm rewarded for clicks will learn which headlines get clicked, not which articles were worth reading.

Artificial intelligence raises the stakes. When we train an AI system, we usually give it something to optimize, a measurable signal that stands in for what we actually want. Researchers have catalogued many cases where systems found unexpected shortcuts: maximizing the score in ways the designers never intended, satisfying the letter of an objective while missing its point. The field often calls this "specification gaming," and the name is apt. It's the same degenerate-strategy problem that playtesters hunt for, except the player is relentless, tireless, and very good at finding loopholes.

The gamer's solution is worth borrowing. First, assume that any scoring system will be exploited and test it adversarially before release. Bring in the friend who always breaks games. Second, use multiple scoring paths so that no single metric dominates. Many celebrated strategy games deliberately offer several routes to victory that balance against each other. Third, keep a human in the loop who can say "that's technically allowed, but it's not the game we're playing."

The most important lesson is humility about intent. Lizzie Magie knew exactly what she wanted players to feel. The rules taught something else. Whenever you design a system, whether it's a board game, a performance review, or an AI reward function, ask a blunt question: if someone played this purely to win, what would they do? Then decide whether you can live with the answer.

Runaway Leaders and the Physics of Feedback Loops

Every experienced board gamer has lived through this game night. One player gets a lucky break early. That advantage lets them earn more resources, which lets them build more, which earns them even more resources. By the halfway point, everyone at the table knows who's going to win. The remaining hour is a formality, and the players who are behind start checking their phones.

Designers call this the runaway leader problem, and it comes from a positive feedback loop: success produces the means for more success. Positive feedback isn't bad on its own. It's what makes building an engine in a strategy game feel satisfying, and it's what makes the late game of many classics feel dramatic. But unchecked, it turns a contest into a coronation.

The counterweight is negative feedback: mechanisms that make it harder to stay ahead or easier to catch up. Game designers have invented dozens of them:

• The leader is a target. In many negotiation and area-control games, players naturally gang up on whoever's winning, so the social dynamics of the table act as a brake.

• Catch-up mechanics. Some games give trailing players better options, cheaper actions, or first pick in the next round.

• Hidden scores. If nobody knows exactly who's ahead, nobody gives up, and the leader can't coast.

• Diminishing returns. The tenth of something is worth less than the first, so hoarding stops paying off.

• Short games. Sometimes the simplest fix is ending before the snowball gets big.

The Settlers of Catan, first published in 1995 and now simply called Catan, is a useful example. Production is tied to dice rolls, so even a strong position can have a bad run. Trading requires other players' cooperation, and the table quickly learns to stop trading with whoever is closest to winning. The robber can be placed to choke the leader's best resource. None of these mechanisms guarantees a close game, but together they give trailing players hope, which is what keeps them engaged.

Now look at technology through the same lens. Digital markets are notorious for positive feedback loops. A platform with more users attracts more developers, which attracts more users. A search engine with more traffic gets more data, which improves its results, which brings more traffic. Economists call these network effects, and they explain why so many technology markets end up with one dominant player. Compared to a board game, there's no table to gang up on the leader, no hidden scoring, and no end of the game.

AI adds another loop. Systems that learn from user interactions can improve fastest where they're already used most. Recommendation systems can amplify whatever is already popular, so popular things become more popular and newcomers struggle to be seen. In content feeds, music services, and online marketplaces, the rich-get-richer effect is built into the plumbing unless someone deliberately designs against it.

This is where the designer's mindset helps. Asking "is this fair?" in the abstract tends to produce arguments. Asking "where are the feedback loops, and which direction do they push?" produces a map. Once you can see the loops, you can decide where to add friction: discovery features that surface new creators, interoperability that lets people take their data elsewhere, diversity requirements in recommendation results, or policies that stop one advantage from compounding into all the others.

The gaming table teaches one more thing here. Players will tolerate losing. They won't tolerate a game where losing was decided an hour ago and they're still required to keep playing. Systems that feel predetermined lose the trust and engagement of the people inside them. That's true for a Saturday-night board game, and it's true for a digital economy.

The Game Master: Where Rules End and Judgment Begins

Board games try to anticipate everything. Tabletop role-playing games admit they can't.

When Dungeons & Dragons was published in 1974 by Gary Gygax and Dave Arneson, it built on a long tradition of tabletop war games, a lineage that reaches back to Kriegsspiel, the Prussian military training game developed in the early nineteenth century. Early war games ran into a stubborn problem. The more realistic they tried to be, the more rules they needed, and the rules could never cover every situation a battlefield might produce. One answer, used in some versions of Kriegsspiel and adopted wholeheartedly by role-playing games, was to give an experienced umpire the authority to decide outcomes the rules didn't cover.

In role-playing games, that umpire became the game master, or GM. Players can try anything they can describe. Want to swing from the chandelier, talk the guard into a bribe, or rewire the spaceship's reactor with a hairpin? There may be no rule for that. The GM decides whether it's possible, what it costs, and what roll, if any, determines success.

Many games formalize this with a principle players often call "rule zero": the GM can change, ignore, or invent rules to serve the game and the table. Rule zero isn't a license for tyranny. A GM who abuses it soon finds an empty table. It's an acknowledgment that written rules are a tool, and that the real goal, everyone having a good time telling a story together, sometimes requires a human to make a call.

This is one of the most important ideas in all of system design, and technology keeps having to relearn it. Software is rule-following machinery. It's excellent at applying the same logic consistently, at scale, without fatigue or bias from a bad mood. Those are real virtues. But software has no rule zero unless someone designs one in. When a situation falls outside the rules, the system either forces it into a category that doesn't fit or refuses to act. Anyone who has argued with an automated phone tree, been locked out of an account by a fraud algorithm, or had a legitimate request rejected because a form lacked the right checkbox has met a game with no GM.

AI changes this picture in an interesting way. Large language models and other modern AI systems can handle ambiguous, open-ended requests far better than traditional rule-based software. In a sense, they can improvise. That makes it tempting to hand them the GM's chair. Indeed, people already use AI tools to generate dungeon maps, voice non-player characters, brainstorm plot hooks, and run solo adventures.

Used well, that's a genuine creative gift. But the GM role involves more than improvisation. A good GM reads the room. They notice when a quiet player hasn't had a moment in the spotlight. They know when a rule should bend because bending it makes a better story, and when it shouldn't because fairness matters more. Above all, they're accountable to the people at the table. If a ruling feels unfair, players can push back, discuss it, and change it next session.

That's the line worth drawing for any system, gaming or otherwise. Automate the bookkeeping. Let software, and increasingly AI, handle the math, the lookups, the first draft, and the routine cases. Keep a human in the GM's chair for decisions that involve fairness, exceptions, and real consequences for people. And make sure every system has a way for the players to say, "Wait, that ruling doesn't seem right," and be heard by someone who can change it.

The question isn't whether machines can make judgment calls. Increasingly, they can make plausible ones. The question is who answers for the call when it's wrong. At the gaming table, everyone knows the answer. In technology, it's worth insisting that someone does.

Cooperative Games and the Alpha Player Problem

Cooperative board games flip the usual setup. Instead of competing against each other, players work together against the game itself. Pandemic, designed by Matt Leacock and published in 2008, is the best-known example: players are disease specialists racing to cure outbreaks spreading across a world map. Everyone wins together or loses together.

Cooperative games are wonderful for families, newcomers, and anyone who dislikes the sting of a friend beating them. But they come with a famous design flaw, one the hobby named long ago: the alpha player.

The alpha player is the person at the table who knows the game best and, with the best intentions, starts telling everyone else what to do. "You should move here. No, play that card. Trust me, it's the optimal move." Because all information is shared and everyone's on the same team, there's no reason not to listen. Soon one person is effectively playing a solo game while everyone else moves pieces on their behalf. The group might even win more often. But most of the people at the table didn't really play.

Designers have developed several countermeasures:

• Hidden information. Some games let each player see cards or details no one else can, so no single person has the full picture.

• Limited communication. Certain co-ops restrict what players can say about their hands, forcing them to make their own decisions.

• Time pressure. Real-time games give players too little time to wait for instructions.

• Distinct roles. When each player has unique abilities, they're the natural expert on their own part of the plan.

All of these do the same thing: they make every player's judgment matter.

Here's why this belongs in an article about technology. We are all about to have a very knowledgeable player sitting next to us at the table. AI assistants can suggest the next sentence of an email, the next line of code, the next move in a spreadsheet, the next step in a diagnosis. Often their suggestions are good. Sometimes they're better than what we would have come up with alone. And the easiest thing in the world is to start accepting every suggestion, until we're no longer really playing.

The risk isn't that the AI is malicious. The alpha player isn't malicious either. The risk is quieter. When people stop making decisions, they stop building the skill to make them. They stop noticing when the expert is wrong, because they've lost the context needed to judge. And over time, the group as a whole becomes fragile: if the alpha player leaves the table, nobody else knows how to play.

Good cooperative design suggests better ways to work alongside AI. Keep distinct roles: let the tool handle what it's good at, like drafting, searching, summarizing, or calculating, while people own the decisions that need context, values, and accountability. Ask the tool to explain its reasoning rather than just giving an answer, so you keep learning the game. Occasionally do things the slow way on purpose, the way a group might ban table talk for a round to give everyone a turn at thinking. And treat suggestions as advice from a teammate, not instructions from a boss.

The best cooperative games leave everyone at the table feeling they contributed something nobody else could. That's a reasonable standard for any tool we invite into our work. If an assistant makes you faster but leaves you feeling like a spectator in your own job, the design, or the way you're using it, could be better.

Session Zero: Designing for Trust Before the Game Begins

One of the most useful ideas to come out of the tabletop role-playing community in recent years isn't a rule at all. It's a meeting.

Many groups now begin a new campaign with what's called a "session zero." Before anyone rolls a die, the players and the GM sit down and talk about the game they want to play. What tone are we going for: heroic, gritty, comedic, horror? How often will we meet? How much combat versus conversation? Are there topics anyone would rather not see in the story? What happens if someone has to miss a session?

Alongside session zero, the hobby has developed a set of lightweight safety tools. "Lines and veils" is a common one: a line is something that won't appear in the game at all, while a veil is something that can happen but "off screen," without detail. Another widely used tool is the X-card, created by designer John Stavropoulos: a card placed on the table that any player can tap to remove content they're uncomfortable with, no explanation required. Some groups use simple check-ins at the end of each session to ask what worked and what didn't.

None of these tools are complicated. What makes them powerful is that they establish trust before it's tested. Everyone agrees up front on what the game is, what it isn't, and how to raise a problem. When something goes wrong, there's already a shared language for addressing it, so a moment of discomfort doesn't turn into a ruined friendship.

Technology rarely has a session zero. We install an app, scroll past the terms of service, click "accept," and start playing a game whose expectations were set by someone else. Most terms of service are written to protect the company, not to inform the player. They're the opposite of a session zero: a long, one-sided rulebook nobody reads, with no conversation and no veto.

This matters more as technology becomes more personal. An AI assistant that can read your email, a smart speaker that listens in your kitchen, a fitness tracker that knows your heart rate: each of these is a long campaign with a lot of potential for discomfort. Without clear upfront expectations, people discover the boundaries only by crossing them, usually when they learn their data was used in a way they never imagined.

What would a session zero look like for technology? A few principles translate directly:

• Plain-language expectations. Say what the system does, what it doesn't do, and what it will do with your information, in words a normal person would use at a kitchen table.

• Meaningful choices up front. Let people set their own lines and veils: what data is off-limits, what features they don't want, what kinds of content they'd rather not see.

• An easy X-card. Provide a simple, judgment-free way to stop, undo, opt out, or delete. If leaving is hard, people don't trust staying.

• Regular check-ins. Revisit consent when the system changes, rather than assuming yesterday's "yes" covers tomorrow's new feature.

Organizations deploying AI internally can apply the same idea. Before rolling out a tool, hold an actual session zero with the people who will use it. What is it for? What data should never go into it? Who reviews its output before it goes out the door? What do we do when it makes a mistake? Teams that answer those questions early tend to have far fewer painful surprises later.

The tabletop community learned something many technology companies are still learning: people are willing to go to surprising, even uncomfortable places together when they trust the table. Trust isn't a feature you bolt on after launch. It's the first session of the game.

Legacy Games: When the Rules Change Permanently

For most of board gaming's history, a game reset when you put it back in the box. Whatever happened last night, the next game started fresh. Then, in 2011, designer Rob Daviau released Risk Legacy, and the hobby discovered a new idea.

In a legacy game, decisions are permanent. You write on the board. You put stickers on cards that change them forever. You tear up cards and throw them away. Sealed envelopes and boxes open when certain conditions are met, introducing new rules mid-campaign. Your copy of the game slowly becomes unlike anyone else's. Pandemic Legacy: Season 1, co-designed by Daviau and Matt Leacock and released in 2015, brought the format to a huge audience and earned a reputation as one of the most highly rated board games ever made.

Legacy games feel thrilling precisely because they're irreversible. A choice carries weight when you know you can't take it back. But that same quality introduces design challenges that will sound familiar to anyone who works with software.

State accumulates. After ten sessions, the game's current rules are the original rules plus every change made along the way. Players need to track what's been altered, and forgetting a sticker applied three games ago can quietly break things. Software developers know this as technical debt and configuration drift: systems that have been patched so many times that nobody's sure exactly how they behave.

Mistakes are permanent. If you misread a rule and destroy the wrong card, there's no undo. Some players keep photos of components before modifying them, a homemade version of backups. Technology teams learned long ago that every change should be reversible when possible, which is why version control, backups, and staged rollouts exist.

Players need a record. Many legacy games include a logbook where players write down what happened each session: who won, what changed, what was unlocked. The log turns a pile of altered components into a story, and it helps everyone remember why things are the way they are. This is exactly what a good changelog or version history does for software.

Now consider the systems around us. Almost every piece of modern technology is a legacy game. Apps update overnight. Features appear and disappear. Terms change. AI models get retrained and start responding differently to the same question. Unlike a board game, users don't open the sealed envelope themselves; the envelope gets opened for them, often without notice. One morning the rules are different, and the only clue is that something familiar stopped working.

The legacy-game designer's toolkit offers sensible guidance for anyone building systems that change over time:

• Announce the envelope. Tell people when rules are about to change, and why. Surprises are fun in games; in tools people depend on, they erode trust.

• Keep the logbook. Maintain a readable record of what changed and when. When AI systems are updated, a plain explanation of what's different helps users recalibrate.

• Reserve irreversibility for things that deserve it. Permanent changes should be deliberate and rare. For everything else, provide an undo.

• Protect the save file. People's data, history, and work are their copy of the game. Changes to the system shouldn't wipe out what they've built.

There's a deeper lesson, too. Legacy games work because the players are partners in the change. They open the boxes, apply the stickers, and make the choices that reshape the game. The story belongs to them. When technology changes, the healthiest versions feel similar: users understand what happened, have some say in it, and can see how their own choices shaped the system they now live in. The worst versions feel like someone else is playing your copy of the game.

Play as Practice for a Designed World

It's easy to dismiss games as a hobby, something people do to unwind after the real work is done. But games have always been a way for people to practice living inside systems. Chess has been used for centuries as a way to think about strategy. Kriegsspiel trained officers. Today, millions of people spend their evenings learning new rule sets, testing strategies, negotiating with rivals, cooperating with friends, and arguing about fairness. That's not a break from understanding technology. It's rehearsal for it.

Pull the threads of this article together and a short list of lessons emerges, useful whether you're building systems or simply living inside them:

1. The rules are the interface. How a system works and how it feels are inseparable. Whoever writes the rules shapes the experience.

2. Teach through the system, not the manual. Clear design does the teaching. Documentation confirms it. Be wary of any explanation, human or AI, that the system itself can't back up.

3. People play what you score. Every metric becomes a target. Assume it will be gamed, test it adversarially, and keep more than one path to success.

4. Watch the feedback loops. Advantages compound. Without deliberate catch-up mechanisms, systems drift toward runaway leaders and players who've stopped trying.

5. Keep a game master. Automate the bookkeeping, but keep accountable human judgment for exceptions, fairness, and decisions that affect people's lives.

6. Don't let the alpha player take over. Use powerful tools, including AI, as teammates with distinct roles, not as players who make every move for you.

7. Hold a session zero. Establish expectations, boundaries, and an easy way to say stop before trust is ever tested.

8. Treat change like a legacy game. Announce it, log it, make it reversible where possible, and protect the work people have already done.

None of these ideas belong to any particular technology. They were true when the most advanced tool at the table was a pair of dice, and they'll still be true long after today's AI models have been replaced by something we can't yet imagine. That's the advantage of thinking like a game designer: the specific components change, but the problems of rules, incentives, fairness, judgment, trust, and change stay remarkably constant.

So the next time you're frustrated by an app, puzzled by an algorithm, or deciding how far to trust an AI assistant, try asking the questions a seasoned gamer would ask. What are the actual rules here? What is this system rewarding? Who's running away with the game, and why? Who can I appeal to when a ruling seems wrong? Did anyone ask me what kind of game I wanted to play?

And the next time someone tells you board games and role-playing games are just for fun, you can agree. Fun is the point. But somewhere between the dice rolls and the rules arguments, players are learning how systems work, how they fail, and how people can make them better together. In a world increasingly run by rules we didn't write, that may be one of the most practical skills there is.

Pull up a chair. Read the rulebook. Then ask whether the rules are any good, because the most important move in any game is noticing that the rules can change.