Approximate Reading Time: 7 minutes

I have spent much of my life thinking about, and working with systems.

Computer systems. Educational systems. Organizational systems. Family systems. Legal systems. Agricultural systems. Ecological systems.

More recently, I have been thinking about how law firms might translate the idea of “trauma-informed practice” into actual procedures rather than leaving it as a collection of good intentions.

Somewhere in the middle of that discussion, something clicked.

I realized that many of the tools I instinctively use when looking at systems come from game design.

And then I realized something larger:

Game design may be one of the most complete models we have for thinking about systems in general.

Not because everything is a game. It isn’t. It really isn’t.

But games are self-contained systems deliberately constructed around the experience and behaviour of people operating inside them (a.k.a. “The Players”). And that last part turns out to matter enormously.

Everything Is a System

A system does not need to be complicated.

It needs components that interact.

A law firm is a system. A school is a system. A family is a system. A hospital is a system. A housing cooperative is a system. A pasture is a system. An ecosystem is a system.

Each contains some combination of:

• actors;
• rules;
• resources;
• constraints;
• information;
• choices;
• incentives;
• feedback;
• time;
• consequences.

Change one component and something else is affected.
Sometimes the change is exactly what we intended.

Sometimes it isn’t.

That is where systems become interesting.

A law firm may have a perfectly reasonable procedure. Consider a hearing that’s been ordered:

The Court sends the hearing information.
The lawyer receives it.
The assistant handles logistics.
The client receives what they need.

Nothing about that sounds problematic.

But if nobody owns the specific task of confirming that the client actually knows how to attend the hearing, the system can produce a client sitting at home three hours before court wondering whether she is supposed to be there in person or whether a link will appear.

Nobody designed that outcome.
The system produced it.
And yet, it’s still a systems problem.

It is also exactly the kind of problem game designers encounter constantly.

The Rulebook Is Not the Game

One of the most important lessons in game design is that the rules you write are not the game.

The game is what happens when actual players encounter those rules.

You can design an elegant mechanic and discover that nobody uses it. You can create a reward you think will encourage cooperation and discover that it encourages hoarding. You can carefully balance resources and watch one unexpected strategy completely dominate play. You can write crystal-clear instructions and then sit beside a playtester who has no idea what to do.

A poor designer says:

The player is doing it wrong.

A good designer says:

Interesting. What did I design that made this response sensible?

That is a profound shift in perspective.

And I think many non-game systems would improve dramatically if their designers adopted it.
A policy may be what the organization says should happen. It says very little about what the ‘players’ will do about it.

The system is what people actually experience when the policy meets reality.

The Player Is the Difference

There are many approaches to systems thinking, design, gap analysis, and process improvement. They all offer useful tools.

But game design adds something I now think is fundamental:
It centres the design on an autonomous participant.
The player is not simply the recipient of the system.
The player is the reason that the game exists in the first place.

• The player observes.
• Interprets.
• Makes choices.
• Experiments.
• Misunderstands.
• Learns.
• Gets frustrated.
• Finds shortcuts.
• Develops strategies.
• Uses the system in ways the designer never anticipated. (aka gaming the system)
• And then the system responds.

That creates a continuous loop:

system ? player ? behaviour ? feedback ? new behaviour ? changed system state

That loop is the game.

But it is also what happens in classrooms, workplaces, legal systems, families and communities.

Human systems cannot be adequately understood by looking only at their formal structure because humans are not passive components.

We respond to the system…
Then the system responds to us.

Good Game Designers Watch What Players Do

This may be the most transferable habit in game design.
You do not merely ask whether your design makes theoretical sense.
You put it in front of people.
Then you watch.
Where do they hesitate?
What do they misunderstand?
What do they ignore?
Where do they become frustrated?
What behaviour emerges repeatedly?
What do they think is important?
What information are they missing when they need to make a decision?
What are they doing that you never imagined they would do?
Then you change something.
And test again.

Design ? observe ? identify gap ? modify ? test ? repeat.

That is also debugging.
It is also good instructional design.
It is also gap analysis.
It is also good organizational development.
And, stripped of the jargon, it is simply a disciplined way of asking:

What did I expect to happen, what actually happened, and why?

The Smallest Change Can Be the Most Important One

One of the reasons I have become suspicious of large-scale reform is that enormous systems are remarkably resistant to being “fixed.”

I learned this years ago in education.
Trying to fix the education system is probably a fool’s errand.
But changing one part of a course can transform what happens to hundreds of students.
(and if another instructor decides to adopt that same small change, that one change can propogate).

The same applies elsewhere.
Suppose a law firm wants to become more trauma-informed.
It could undertake a major cultural transformation.

Or it could notice that uncertainty is particularly difficult for many traumatized clients and ask:

Where does our existing process create uncertainty unnecessarily?

Then make a tiny change.

Example: Three business days before every hearing:

Confirm the client knows the date, time, attendance mode, lawyer attending and remote link if required.

That is not revolutionary.
It may require no additional lawyer time
It can probably be automated.

But to the client who would otherwise spend two days wondering whether they have been forgotten, the effect can be enormous.

Game designers understand this kind of leverage.
Changing one rule can transform an entire game.

Systems Produce Emergent Behaviour

Games also provide an unusually visible demonstration of emergence.

The rules of chess are relatively simple.
But, as we know, chess itself is not.
GO is even simpler, and some say, more challenging to play well.

The game consists of a gridded board and Black and White stones. That’s it. Players take turns placing stones on the grid.The goal is to control more empty space than your opponent by surrounding enemy stones completely in order to take them off the board.

That’s it.

 

Complex behaviour emerges from interactions among simple rules. Real-world systems work the same way. Nobody deliberately creates a policy saying:

Make clients anxious.

Instead:

The Court sometimes sends links late.
Different people receive different messages.
Assistants are busy.
Lawyers assume administration is being handled.
Clients assume someone will tell them what they need to know.

All perfectly understandable.
Together they can create chaos.

Again:

Nobody chose the outcome. It was not deliberately designed.

This is one of the most important reasons to think systemically. If we concentrate only on individuals, we keep trying to correct the person closest to the visible failure.

The assistant should communicate better.
The teacher should try harder.
The client should be more patient.
The student needs to pay attention.
The employee should remember.

Sometimes those things are true.
But the more useful question is often:

What does the structure make easy, and what does it make difficult?

Game designers are taught )or learn) to think that way constantly.

Design for Real Players, Not Ideal Ones

Many systems are quietly designed around imaginary people:

• The ideal employee remembers everything.
• The ideal student reads all the instructions (especially the syllabus!).
• The ideal client remains calm while waiting.
• The ideal patient understands medical terminology.
• The ideal citizen completes the form correctly.

Then real humans arrive.

Good games cannot afford this fantasy. Games are systems that people voluntatarily interact with. That is KEY. If players become too frustrated in a game, they abandon it. Even worse: they tell their friends. The most important aspect determining a game’s success or failure is word of mouth; in other words: the clients.

Players will forget rules.
They will miss information.
They will make strange choices.
They will optimize things the designer didn’t intend them to optimize.
They will bring different abilities, knowledge, motivations and histories.

So good game design tries to make desired behaviour easier through the structure of the system itself.

That principle transfers almost everywhere:

Do not rely on people being heroic when you can make the system helpful.

If something must happen every time, build a trigger.
If people repeatedly miss important information, move it.
If a task is routinely forgotten, automate the reminder.
If a process produces the same failure repeatedly, stop treating each occurrence as a new accident.

The system is telling you something.

Game Design Is Not Gamification

This distinction matters.

Applying game design to real-world systems does not mean adding points, badges, leaderboards, prizes or artificial competition.

That is what is often imagined when people think about gamification. That’s what is obvious and superficial. It’s not what good gamification does.

The deeper transferable knowledge from game design is about:

• • agency;
  • feedback;
  • decision-making;
  • information;
  • constraints;
  • incentives;
  • interaction;
  • emergence;
  • iteration;
  • experience.

The important question is not:

How can we make this more game-like?

It is:

If this WERE a game, in what ways would it be broken?
(One of my favorite questions, made famous by Sebastian Deterding)

Which naturally leads to: What can game design teach us about how people actually experience and respond to systems?

That is a much larger question.

Game Design is a Wonderful Way to Teach Systems Thinking

This realization leads to another possibility.
Systems thinking is often taught abstractly.

• Feedback loops.
• Causal diagrams.
• Stocks and flows.
• Leverage points.

All useful concepts—but abstraction alone does not teach most people to see systems.

Games may.
Give people a small system they can manipulate.
Let them change one rule.

Run it again.
Watch something unexpected happen.
Ask why.

Change another rule.
Watch the first problem disappear and a new one emerge.

Then give them a completely different problem and ask:

Do you recognize the same structure here?

That last step is crucial.
The goal is not simply to teach someone to solve one problem.

The goal is to teach them to recognize:

These two apparently unrelated problems have the same shape.

That is abstraction.
That is transfer.

That is Forest rather than tTees.

This approach works precisely because games let us compress the feedback cycle. In the real world, the consequences of changing a policy may take years to emerge.

In a game, they may appear in twenty minutes.

The Forest, the Trees, and the Player Walking Through Them

I have often thought that people struggle with abstraction.
We see the immediate problem:

• The client did not receive the link.
• The student failed the assignment.
• The employee forgot the task.
• The player is hoarding all the resources.

Systems thinking asks us to move upward:

What CLASS of problem is this?

Game design asks us to move upward without losing sight of the person on the ground.

That may be why I now think of igame design as something of an apex model.

Pure systems analysis can become detached from human experience.

Human-centred design can sometimes become detached from the larger structure producing that experience.

Game design has to hold both simultaneously.

There is a system. There is a person inside it. The person changes behaviour because of the system. That behaviour changes what happens next, and the designer’s job is not merely to specify the system. The designer’s job is to understand the experience the system produces.

That principle transfers remarkably well.

• From games to classrooms.
• From classrooms to law firms.
• From law firms to housing cooperatives.
• From organizations to communities.
• Maybe even to the way we understand families and ecosystems.

To be clear: Everything is not a game.

But games may be one of the clearest places we can learn what happens when rules, environments and autonomous actors meet.

And once you learn to look at systems that way, it becomes easy to see games everywhere.