We had been working on the multiplayer match flow for months. The pieces were complex — menus, matchmaking, lobby states, loading sequences, onboarding moments — and getting them to work together technically was going to take significant time and even more effort from a lot of people. At some point we looked at what we had and felt like we were close. The systems were laid out. The features were accounted for. It seemed like it was coming together.
So we wrote the player journey.
We sat down and described, in sequence, what a player actually experiences from the moment they decide they want to play a match to the moment they were in one. Not what the system does. What the player does, sees, waits for, interacts with, and feels at each step of the way. We wrote it out like a story — this happens, then this, then this — and somewhere in the middle of writing it we saw the problem clearly for the first time.
It was too long. And for most of that length, the player wasn’t doing anything. They were waiting. Watching. Sitting with a screen that didn’t ask anything of them and didn’t give them anything to engage with. The feature list hadn’t revealed this. The system design hadn’t revealed this. The months of technical ideation hadn’t revealed this. The player journey revealed it in the time it took to write a few paragraphs.
That’s what it’s for.
What A Player Journey Is
A player journey is a semi-theoretical account of what a player experiences, is supposed to feel, and interacts with through a feature, a loop, or a session — written from the player’s perspective, in sequence, as a lived experience.
It is not a feature list. It doesn’t describe what the system does or what options are available. It describes what the player encounters, in the order they encounter it, from the moment they engage with something to the moment they move on. It’s a story told in the second person — the uncomfortable perspective. You open the menu. You select a mode. You wait. You see this. You do that.
The form matters because sequence matters. Features that look fine in isolation can create friction, confusion, or boredom when experienced one after another. The player journey surfaces that friction because it forces you to walk through the experience in order, at the pace a player would actually move through it, without skipping the parts that feel slow or the transitions that feel abrupt.
It can be written for a single feature, a complete game loop, or an entire session. The scope depends on what you’re trying to understand. But the principle is always the same: describe what the player actually experiences, not what you intend for them to experience. The gap between those two things is where the most useful information lives.
Who Should Write One
Feature owners should write player journeys for their features. That’s the baseline — if you own a piece of the player experience, you should be able to describe what that experience is from the player’s perspective and how it connects to the features around it.
But here’s my personal opinion: everyone on the team should be able to write a reasonably coherent player journey for the game they’re working on. Not just their feature or how the player interacts with their discipline. The whole thing, in at least some amount of detail.
If they can’t — if a QA tester or an audio designer or an engineer can’t reasonably describe what a player does and feels through a feature — that’s a signal. Not about those people, but about how the feature has been communicated. The player journey is as much a communication test as it is a design tool. A team where everyone can describe the player experience with reasonable accuracy is a team that has been told what they’re building and why. A team where only one or two people can do it is a team operating with a significant gap between the people making decisions and the people executing them.
The Failure Modes
There are a few ways the player journey goes wrong and they’re all worth naming.
The first is the absence of one. Features get built, loops get assembled, sessions get designed — and nobody ever writes down what the player actually experiences. The experience exists only in the heads of the people who built it, distributed across disciplines in pieces that nobody has assembled into a complete sequence. This is more common than it should be and it tends to produce exactly the kind of gaps in judgement we found in the multiplayer flow — things that work individually but don’t hold together as a lived experience.
The second is the refusal. Sometimes the player journey doesn’t get written because someone knows what it would reveal. A feature that felt solid in concept starts to look different when you have to describe it from the player’s perspective in sequence. The slow moment becomes visible. The missing interaction becomes visible. The thing that doesn’t quite connect to what comes before or after it becomes visible. Writing it down makes the problem undeniable in a way that not writing it down doesn’t. Some people, consciously or not, choose not to write it down.
The third is the most insidious. This is the player journey that changes who the player is to fit the needs of the game — that describes a player who wants exactly what one feature provides, but then describes a different player for another feature, as if a player has exactly the patience the flow requires, who responds exactly the way the design needs them to. This version of the player journey isn’t a test. It’s a justification. And it tends to produce the same blindness as not writing one at all, because it never honestly confronts the gap between the experience that was designed and the experience that will actually be had.
The honest player journey assumes a real player. Someone with limited patience, incomplete information, and no particular obligation to engage with something that isn’t earning their attention. Writing for that player is harder. It’s also the only version that tells you anything useful.
Where It Fits
The player journey isn’t a standalone tool. It sits in a specific relationship with the other frameworks worth having.
Pillars tell you what the game should be. Success metrics tell you whether what you’re building is working. Vibes tell you whether something feels right. The player journey tells you whether the experience holds together as a lived sequence — whether the thing you’re building actually makes sense when someone moves through it in order, at the pace a real player would, with the information a real player would have.
They work together. A player journey that fails against your pillars is telling you something. A player journey that reveals a moment with no measurable success metric is telling you something. A player journey that describes an experience that nobody on the team would enjoy playing is telling you something very loudly.
Write It Down
Writing it down is the whole point. Not because the written version is perfect — it isn’t, it’s theoretical, it’s an approximation of an experience that won’t fully exist until someone plays it. But the act of writing it forces a sequence. It forces you to account for every step, every wait, every transition. It forces you to describe what the player is doing during the parts that feel obvious, which is usually where the problems are.
The player journey we wrote for the multiplayer flow was uncomfortable to write. The problem it revealed was real and it took more work to fix. But we found it before players did, which is the whole point of having the tool.
Write the player journey. Write it early. Write it honestly. Write it often. And if someone on your team can’t write one for the thing they’re building — find out why, because that’s probably where a problem resides.