Making Two Invisible Systems Visible

Role

Producer: decisions.

Team

The full 20 Below team, 15 people.

Result

A 99-file divider library shown as one set, a map of how data moves between the apps, and a false claim on the download page caught and corrected.

The Problem

A system nobody can see is a system nobody can trust.

20 Below, a tabletop RPG I’ve produced since 2021, had two systems like that. The first was visual: a 99-file library of procedurally generated section dividers, nine edge treatments carried across eleven color roles, built one file at a time and never once shown as a set. The second was technical: a small constellation of apps and scripts — a character creator, a battle tracker, an encounter calculator, a publishing tool, and a pair of Owlbear Rodeo extensions — that had grown up around each other without anyone ever drawing the map of how data actually moved between them. Both were real. Neither was written down anywhere a person could look at once and understand.

The technical one had already cost something. The project’s own download page told players one of the Owlbear extensions could optionally read their character file. It couldn’t. Nobody had caught it, because nobody had checked the claim against the code that actually shipped.

Analysis

Two different systems, two different audiences, and I made myself treat them that way instead of reaching for one solution and hoping it covered both.

The divider library needed a reader who could see the whole set at a glance — nine styles times eleven colors is ninety-nine decisions, and ninety-nine files in a folder don’t read as a decision at all. The tool ecosystem needed something else: a map a contributor could trust, which meant it needed to be checked, not asserted. I’d already watched one piece of marketing copy go stale and wrong without anyone noticing. I wasn’t going to build the map the same way — from what the tools looked like they should do — and risk teaching the same lesson twice.

Design Decisions

• Built a specimen sheet that pulls in the actual ninety-nine source files rather than redrawing approximations of them — if a texture or a color is wrong, it’s wrong in the original, not in my copy of it.
• Laid the specimen sheet out as a grid, texture by row and color by column, so the pattern reads as a system in one look instead of ninety-nine separate judgment calls.
• For the tool ecosystem, went to the actual source before drawing anything: opened the extension repos, read their READMEs against their code, and traced the publishing pipeline back to the Scrivener manuscript and the two conversion scripts that come off it.
• That check is what surfaced the wrong claim about character-JSON support. I fixed the copy on the live site as part of the same pass, instead of filing it away as someone else’s problem.
• Diagrammed the real architecture, including the parts that don’t flatter it — a live data dependency between two tools that only has a local fallback if it fails, and a known, unresolved formatting mismatch between the web edition and the print edition of the same source text. A map that hides its own rough edges isn’t a map anyone can use to make a decision.

Outcome

Two systems that used to live only in my head, or in a folder nobody had reason to open all at once, now exist as artifacts someone else could pick up and use — and one real, live inaccuracy got caught and corrected as a direct result of refusing to build documentation from assumption instead of source. That’s the habit I actually want a portfolio to prove: not that I can make something look organized, but that I check before I claim it is.