Notion for Game Design: An Honest Review After Two Years

Two years ago I started a solo prototype in Notion and told myself it would be different this time.

I’d been through the cycle before. Google Docs becomes too unstructured, you migrate to Notion, things feel great for two months, then by month four you’re back to using spreadsheets for half the work and a separate dialogue tool for the other half. This time I was going to do it right. I’d structure it properly. I’d set up the databases up front. I’d treat the workspace like a real production environment, not a notepad.

What I learned, across two projects and roughly 1,200 hours of design work in Notion, is that the failure mode of Notion-for-game-design isn’t about setting it up properly. It fails for structural reasons that no template can fix. This post is the specific list of those reasons, written for someone considering whether to invest the next year of their project life in the same tool.

The short version: Notion is the best general-purpose tool for game design that has ever existed. And it is also, unavoidably, a general-purpose tool. The gap between “good general tool” and “right specialised tool” is invisible until you cross it, and then it’s the only thing you can see.

What Notion is genuinely great at

Front-loading this so the rest of the post doesn’t sound like a hit piece.

The block model. Mixing rich text, columns, toggles, embeds, and inline databases inside a single document is a small miracle of UX design. A vertical-slice GDD with an embedded character gallery, an inline mood-board column, and a toggled-open mechanics list reads beautifully in Notion. Nothing else handles this composition as elegantly. Confluence’s editor feels like 2014 in comparison. Google Docs can’t even attempt it.

Database views. A single “Characters” database that shows up as a kanban on one page, a gallery on another, and a filtered table inline on a third. Same data, different lenses. This is genuinely powerful, and after using it for a while you stop noticing how rare it is.

Onboarding speed. Adding a contractor for a sprint takes ten seconds. No license dance, no install, no permissions theater. Just send the link. For small teams this is a real productivity multiplier.

The sharing model. Public pages with a flick of a switch. Comments that thread cleanly. Page history that actually works. Notion’s collaboration story is enterprise-grade pretending to be consumer-grade, and you don’t notice until you go back to something that gets it wrong.

None of that goes away in the criticism below. The criticism is specifically about what happens when general-purpose flexibility meets the particular shape of game design work.

Where Notion breaks for game design

1. Cross-references are decorative, not structural

Game design has a property most other knowledge work doesn’t: every object you reason about is densely referenced by every other object, and the web of references is in constant motion.

A quest references its giver (a character), its location (a place), its objectives (which reference items, mechanics, flags), and its rewards (items again). Rename the character. And now their name appears in roughly 14 places, some of them in document bodies, some in linked database properties, some in inline mentions, some in the names of other related objects (“Lyra’s Lament” quest becomes wrong the moment Lyra is renamed). A character bio that doesn’t update when you rename the character isn’t just inconvenient. It’s actively misleading. It causes new team members to ask “wait, who’s [old name]?” three months later.

Notion has @-mentions and backlinks. Technically. In practice:

• @-mentions in page bodies don’t propagate well across reorganisation. Move a page to a new parent, and Notion’s mention sometimes preserves the old link, sometimes shows a broken state, and sometimes (this is the worst one) shows the current page title at the old link target.

• Renaming updates the mention text, but the URL slug doesn’t update. So external bookmarks rot silently. A contractor links to notion.so/.../old-character-name-abc123 in their notes; a week later you rename the character; the link still works (Notion routes by ID) but the URL now lies about what’s there.

• There is no “every mention of this character across every page” view. The “Backlinks” feature exists but only shows page-to-page links (pages where character X appears in the title or as a linked relation), not inline @-mentions inside other documents. For a character who appears in 22 docs, this is the difference between a useful index and a useless one.

The first time I renamed a major NPC, I found references to her old name in seven separate docs three months later, when a playtester asked “wait, is Maren the same person as Lyra?” The two names had drifted into being treated as different characters by everyone reading the GDD. That should not be possible in 2026.

The fix Notion gives you is: be more disciplined about always using inline @-mentions instead of typing names as plain text. This works for a single careful writer. It does not survive contact with two writers, or with you-six-months-later, or with a contractor onboarded in an afternoon.

2. Item-shaped content fights the page-shaped editor

Notion’s atomic unit is the page. Every character is a page. Every quest is a page. Every mechanic is a page.

That sounds fine until you realise what a character actually is. A character is a structured record. Name, role, portrait, voice sample, three-beat backstory, mechanical hook, relationships, arc. With optional long-form fields nested inside. It’s not a document. The first thing a Notion page shows you is a giant blank canvas inviting you to write paragraphs. The structure of “name, role, portrait, voice sample…” has to be invented by you, every time, for every character, and remembered consistently by everyone on the team.

The Notion workaround is to use a database with custom properties for the structured fields. This works for the structured fields. But your character’s bio, backstory, and relationships are long-form, not single-line. And Notion databases treat the page body as a separate surface from the properties. So you end up with characters split across three places:

1. Database properties at the top (name, role, status, tags)
2. The page body below the properties (backstory, voice samples, design notes. Long-form)
3. A separate “design notes” sub-page linked from inside the body, because the body becomes a junk drawer otherwise

After a year, nobody on my team knew which of those three places had the “latest” version of any given character’s voice direction. We started keeping a “current source of truth” tracking doc. That doc went out of date within a week. We gave up.

The structural problem: a character is one thing with internal structure, not three loosely-linked things. Notion’s data model can’t express that without splitting it. Specialised tools. Anything from Articy:draft to spreadsheets with macros to (full disclosure) the tool I ended up building. Represent a character as a single record with all its fields together, including the long-form ones, in one editable surface. The reason this matters is not aesthetic; it’s that a single surface eliminates the “where is the latest version” question entirely.

3. There are no game-specific blocks

Notion has roughly 20 block types. None of them were designed for games. Here’s what you’ll wish existed:

Each workaround takes 20 minutes to set up the first time, and breaks subtly the tenth time. None feel native. And the time you spend setting them up is time you didn’t spend designing. After two years, my best estimate is I spent 80-100 hours total wrestling Notion into shapes it didn’t want to be.

You’ll see online that this is the “trade-off for flexibility.” It isn’t. Specialised tools are flexible inside their domain and native to it. The trade-off is a tax you’re paying that you may not have noticed.

4. Performance becomes a real problem past 800 pages

This one is straightforward. Notion is fine at 200 pages. It becomes noticeably sluggish at 800. Past 1,500, search times measurably hit 1-3 seconds; database views with filters take 2-4 seconds to render; page loads stutter. At 2,500+ pages on a shared workspace, you wait for everything, and your team starts splitting work into multiple workspaces. Which kills the entire “everything in one place” pitch and recreates the cross-workspace coordination problems you switched to Notion to avoid.

A vertical-slice GDD for a small game easily crosses 800 pages once you have ~50 characters, ~80 items, ~20 quests, ~10 levels, each with sub-pages for variants and notes. A full game is comfortably past 2,500. Notion has known about this problem for years; the architecture they chose makes it hard to fix without a rewrite.

5. Branching content is genuinely bad

The thing I missed most building branching quests in Notion was conditional logic between objectives. “If the player has flag X set, skip to step 5. Otherwise continue to step 3.” This is a basic structure for quest design and Notion has no native way to express it. You get:

• Bulleted lists with indentation (no conditions, no links between steps)
• A linked database of “objectives” (no order, no flow visualisation)
• A Mermaid diagram embed (works, but it’s plain-text Mermaid syntax that no writer will edit)

I ended up doing all quest design in a separate Miro board, then pasting screenshots into the Notion quest pages. Every change had to happen in two places. Miro’s branching was good; Notion’s prose was good; the integration between them was a constant source of stale, conflicting truth.

Same story for branching dialogue. Articy:draft figured this out fifteen years ago; Notion does not have an answer.

The workarounds I tried, ranked by how long they lasted

I want to be honest about the timeline, because most reviews skip it. The cracks don’t show on day one. They show after the project has enough momentum that switching costs are real.

The pattern is consistent: each workaround buys you two weeks to six months of “this is fine” before the structural mismatch re-asserts itself. Across two years, I spent roughly 100 hours total on workarounds and recovering from broken workarounds. I tracked some of it; I extrapolated the rest. That’s 100 hours not spent designing the game.

When Notion is still the right call

I’m not trying to convince anyone to abandon Notion universally. There are real cases where it’s the best answer:

• Solo dev, small game (under 50 items total). The structural problems don’t have time to surface. Use it.
• Pre-production phase. Notion’s polish sells the project to publishers and team members before the cracks matter.
• You already pay for Notion and your tooling budget is zero. The marginal cost is zero.
• Your team has zero appetite for learning a new tool. Tool-switching costs are real and not always worth paying.
• Game jam or short prototype. You will throw the project away in 6 weeks. The tool’s job is to not interrupt you for that long.

The minute the project crosses into production with ~100+ items, multiple writers, and active iteration, the calculus changes.

What I look for in a replacement

After two years of fighting the gap, here’s the shopping list:

1. @-mention chips that survive renames everywhere. Not just in linked properties, but inside long-form text.
2. A backlinks panel that shows every mention in every doc, not just page-to-page relations.
3. Structured editors per item type. Characters get a character form, quests get a quest form, with all fields (including long-form) on one surface.
4. A branching quest editor with conditional logic as a first-class feature, not a Mermaid embed.
5. Game-specific GDD blocks: input scheme, object reference, color palette, timeline, sound list.
6. Speed at 1,000+ items, because that’s a real project.
7. Affordable for indies, because every indie tool that prices itself per-seat-for-enterprise eventually loses to the spreadsheet.

That list is, full disclosure, what I built Ludessy to be. Read the rest of this blog and pick the parts you find useful. The shopping list above is true whether you adopt Ludessy or build the workarounds in Notion yourself.

How to test whether Notion is failing you today

Don’t take my word for it. Two tests, three minutes each.

Test 1. The rename test. Pick the most-renamed item in your current project (a character or system that changed names in the last month). Open Notion’s search. Search for the old name. If you get any hits, your tool isn’t propagating renames. That’s the cost in concrete form.

Test 2. The contractor test. Imagine onboarding a new writer tomorrow. How long would it take you to explain “where each thing lives”. Which docs are canonical, which are drafts, which are archived, which are nested under which parent, where the latest balance numbers live? If the answer is more than 15 minutes, the structure is in your head, not the tool. That’s a debt that compounds.

If both tests pass, your Notion setup is working. Keep it. The cost of switching is real and not worth paying without a real reason. If either fails, you’ve found the leak.

Next step

I’m planning a follow-up on what we actually found when we migrated a 600-item project off Notion. What broke during the migration, what surprised us, what we wish we’d done differently. If that would be useful, request the post via the feature form and I’ll prioritise writing it.

If you’re earlier in the cycle and curious about specialised options, the 7 best game design document tools comparison covers what’s out there as of 2026. If you want the bigger picture argument for why generic tools fail this category at all, the why generic tools break for game design post lays out the structural case in detail. And if you want the founder backstory for Ludessy itself, the launch announcement covers what it is and why it exists.