Chain of Authorship didn’t begin as a theory. It began as a design job that was supposed to be cosmetic.
DM a GM was a product for connecting tabletop role-playing game players and Game Masters. By the time I entered it, the product already had a shape in the conventional sense: backend work, skeletal screens, a pile of features, an idea of matching, short-form video, tags, swiping, profiles, messaging, campaigns. It looked, at first glance, like a product that needed visual coherence.
What I remember being asked to do was make it look pretty.
That sentence became important to me later. Not because it was uniquely insulting—designers hear versions of it constantly—but because it revealed the project’s underlying assumption: that the hard part had already happened. The product had been conceived. The systems existed. My job was to make the surface feel finished.
But every attempt to make the surface coherent forced a more basic question.
Coherent for whom?
I started trying to make a sitemap. I thought I was organising pages. Instead, I found myself surrounded by questions the existing screens couldn’t answer. What was a player actually trying to do when they opened the app? Were they browsing for entertainment, looking for a game, comparing possible groups, applying to join one, or trying to assess whether a stranger would be safe and compatible to play with?
What was a Game Master trying to do: publish a listing, build a party, review applicants, or manage an existing campaign? What happened after a player and GM “matched”? And where did a character belong—in a profile, an application, or the ongoing campaign relationship?
The feature list had answers in the shallow sense: there were screens for profiles, messages, campaigns, discovery, settings, reviews, character creation. But it didn’t have an account of how those things belonged together.
So the sitemap became a UX Brainstorm Dump. The more I mapped, the less I could pretend I was tidying up navigation. I was trying to discover what kind of system DM a GM was.
I made a questionnaire to understand how players and Game Masters found groups, built trust, and decided whether a game could work. Then it got lost in the work. The project kept moving, and the questionnaire was never sent out.
The project was already teaching me a distinction I didn’t yet have language for: a screen isn’t a resolved interaction. A list of features isn’t a product model. A polished artefact isn’t proof that the reasoning behind it exists.
The early designs were therefore doing two jobs at once. They were interfaces, but they were also questions expressed visually.
Could a swipe-based discovery experience really support an important decision about joining a long-term social group? Could people assess a campaign through fast content alone? What information would they need before applying? How would safety tools, table expectations, session frequency, communication platforms, experience level, character expectations, available seats, and scheduling fit together?
Eventually, I began distinguishing between different kinds of discovery.
The Dungeon Scroll was more exploratory: visual, low commitment, one campaign at a time. It could make people curious.
The Quest Board was different. It was for higher-intent evaluation: browsing, filtering, comparing, and understanding several possible campaigns before making a consequential choice.
Later, the War Table emerged for a similar reason. A bookmark meant, “Maybe later.” The War Table meant, “I’m actively comparing these plausible options.” That distinction sounds small until you understand that it changes the data, interactions, hierarchy, and meaning of the whole product.
This wasn’t “more UI.” It was a product becoming more honest about what it was asking people to do.
The problem was that the meaning of the work wasn’t shared. I could make a screen in order to think with it—to expose a missing relationship, test an interaction, or see what the system still couldn’t explain. Someone else could encounter the same screen as an instruction to implement.
Neither reading was irrational. The screen looked designed. It had layout, components, hierarchy, and enough visual resolution to resemble a decision. Under pressure to build an alpha, parts of unfinished mockups could be translated into code. Once implementation began, the artefact gained cost, momentum, and authority. Revising it could look like undoing completed work rather than continuing an unresolved inquiry.
That’s the point at which I began to understand that fidelity doesn’t tell you what a design decision means.
A mid-fidelity screen can be exploratory. A rough diagram can contain a major commitment. A finished-looking screen can still be a question. And once the status of the work disappears, design exploration can quietly become somebody else’s obligation to build.
The project wasn’t simply a story about a founder being wrong, a developer moving too fast, or a designer needing more time. It was a story about what happens when a team doesn’t have a shared way to distinguish inherited assumptions from observed conditions, interpretations from findings, exploratory artefacts from approved specifications, and implementation from inevitability.
I eventually needed a better working arrangement: a clearer brief, a bounded period for research and system definition, and a way to document why the work kept changing. Development Logs became part of that answer. Not exhaustive diaries. Not productivity theatre. A record of consequential movement: what prompted a decision, what was discovered, what changed, what remained unresolved, and what other work now depended on it.
Only later did I name the broader method: Chain of Authorship.
The name was never meant to claim that one designer authored an entire artefact alone. DM a GM was already shaped by founders, developers, prospective users, technical constraints, inherited screens, untested assumptions, platform conventions, and the work that existed before I touched it.
The question wasn’t, “Who gets credit?”
The question was: how did each contribution enter the chain, what status did it have, how did it change downstream work, and what disappeared when the final artefact was treated as though it explained itself?
Chain of Authorship came out of that disappearance.
And Chain of Ownership came after it, because once you can see a reasoning chain, a harder question becomes unavoidable: when organisational authority conflicts with the work’s actual evidence and dependencies, who gets to decide—and who is accountable for the override?