I learned design systems on a pasteboard

My first design system was a set of paragraph styles in InDesign, and nobody called it that. Early in my career I was the only designer at Well Being Journal, a bimonthly magazine, which meant I handled everything from the feature spreads to the files that went to the printer. After that I spent a year and a half at Madden Media laying out visitor guides and event directories for tourism clients. The job in both places was to get pages out the door, issue after issue, without breaking consistency.

Consistency is the whole problem. Hand a template to a few designers on deadline and by the fourth issue you'll have captions in 8.5 point, 9 point, and 9 point with a little extra tracking because one line wouldn't fit. Nobody did anything wrong. Each change made sense on the page where it happened. Production design is mostly the work of keeping those small, reasonable decisions from piling up into a publication that looks like it was made by committee.

The tool for that was styles. You don't set a caption at 9 on 11 with 20 units of tracking. You apply the Caption style, and when you decide captions should be a little lighter, you change the style once and every caption in the book reflows. Character styles sat on top for bylines and run-in heads. Object styles handled frames. Master pages held the folios, margins, and column grid. At Madden I built the Travel Wisconsin Art & Craft Fairs directory and Events guide this way, 64 and 54 pages of mostly listings. Page after page of fair names, dates, and addresses is exactly the kind of content that falls apart the moment someone sets type by hand. With the styles in place, a new batch of listings was mostly a matter of flowing text and checking the breaks.

I didn't have the words for it then, but that's a token system. In QDS, the design system I've been building, a button never gets a hex value. It gets --qds-component-button-primary-color-background-rest, which points at a semantic token, which points at a primitive blue. Each tier is only allowed to reference the one beneath it. It's the same as a character style pointing at a font family. You name the decision instead of the value, so you can change the value later without hunting down every place it shows up.

The part of production work I think about most now is preflight. At Well Being Journal I handled prepress myself, so before every issue went to the printer I ran it through checks for missing fonts, RGB images in a CMYK job, overset text, and anything under 300 dpi. A file that failed didn't go out. Print is unforgiving that way. Once the plates are made, a mistake is ink on paper in every copy, sitting on a grocery store rack.

Creating continuous integration rules that catch mistakes before the code is merged is essentially the equivalent of preflight. The naming rules for tokens live in a spec, and the vocabularies in that spec live as data the build actually reads. A validate step runs before the build and fails if a token breaks the rules, points at the wrong tier, or exists in light mode but not dark. The docs site renders its reference tables from the same data, so the documentation can't describe a rule the build doesn't enforce. A style guide people are supposed to remember is a style guide people forget on deadline. I wanted the job to fail before a bad file got anywhere near the press.

Print also taught me to like hard limits. A magazine has the pages it has, and when an ad comes in late, something else gets smaller. You work inside the space you have.

In 2020 I left print for front-end work, and I've been building component libraries and token systems ever since. The pasteboard turned into Figma and then into a code editor, and the work got more abstract.

That's part of why I started making scorebooks. Full Count Scorebooks is a small side project of mine to reconnect to one of my favorite hobbies, and to do something with a smaller amount of abstractions. I lay out baseball and softball scorebooks in InDesign, print them, bind them by hand, and sell them on Etsy. Over 50 have gone out to people around the country so far.

Going back to InDesign after years of writing tokens was strange, because I caught myself building it like a component library. The inning diamond, the little box where you track a runner around the bases, lives in a Creative Cloud Library next to the field chart, the logo, and the wordmark. I place it from the library instead of drawing it on each page, and both books, a small one and a standard one, pull from that same library. All the type is one monospace family set in caps, which kept the system small enough that I could hold it in my head.

A scorebook is a good test of whether a system works, because it's mostly a grid that someone fills in with a pencil at a ballpark, sometimes in bad light, while also watching a game. Every game page has the same structure: a lineup grid across the innings, a pitching table, a line score with runs, hits, and errors, and a block for the weather, start time, and end time. Up front there's a scoring key that explains the shorthand, like FC for a fielder's choice and a backwards K for a strikeout looking. That key is the equivalent of a documentation site. If it's unclear, the person keeping score makes something up, and their book drifts the same way an poorly documented design system does.

So, anyway, I was building master pages so a small magazine could ship every other month without falling apart. Ten years later I build token systems for the same reason, and on weekends I'm back in InDesign making a book that has to hold up to a pencil and nine innings in the sun. It turns out I've been doing one job the whole time.