Matthew Baldwin - Read the Rules: What technical writers can learn from board game design

Board game rules are a high-stakes form of technical writing because they’re effectively “unpatchable” once printed: if a rule is unclear or missing, players can’t experiment their way to the answer and the game won’t work until the rulebook is fixed. That makes rulebooks a useful model for documentation work, since the rules function like an algorithm executed by people—where the “platform” is the reader and the “program” is the step-by-step instructions. Matthew Baldwin, a content developer at Microsoft and a longtime board game enthusiast, argues that technical writers can borrow board game rule design principles—especially information architecture and usability best practices—to make complex systems easier to learn, navigate, and trust.

His first focus is information architecture, using Wingspan as the centerpiece example. The rulebook splits content into a main “how to play” guide plus an appendix reference, so readers get a guided learning path without being forced to wade through every edge case up front. Wingspan also teaches from general to specific: it starts with a short, theme-flavored introduction that still communicates concrete learning goals (what players do, what resources exist, and how points are earned), then provides an overview of turn structure and round flow, and only then drills into the details of each action (play a bird, gain food, lay eggs, draw cards) and bird powers. Baldwin highlights how this structure creates “bounds” in the reader’s mind—like assembling puzzle edges first—so later details have a clear place to land.

Navigation and scanability get treated as design requirements, not afterthoughts. Wingspan’s sections use clear headers, images, and whitespace, with nonessential notes visually separated so readers can ignore them when they’re focused on playing. The appendix acts as a just-in-time reference when a card interaction isn’t obvious, mirroring how good technical documentation separates conceptual explanations from dense reference material.

In the second half, Baldwin offers a “laundry list” of rulebook best practices that translate to documentation. People learn by doing, so step-by-step setup pages and “quick start” style instructions work better than passive reading. Clear language beats branded jargon: calling hexagons “squares” (or renaming familiar concepts like a draw deck) may feel clever but causes forgetting and confusion later. Consistency matters: define terms once and use them exclusively, which also reduces localization burden. Images and examples improve comprehension—especially for setup—while overusing screenshots can create maintenance problems. He also recommends flagging frequently missed steps, using consistent layouts via templates, and tailoring the writing style to the audience (war gamers may tolerate numbered, versioned structures; role-playing fans may prefer more narrative prose). Accessibility shows up in practical choices like icons for color-blind readers and second-person writing that avoids gendered pronouns.

Finally, Baldwin stresses validation: designers should run blind play tests where people learn from the rulebook alone, revealing omissions that experts overlook. After release, feedback loops matter too. He points to Tapestry’s self-reported gameplay data, which led to balancing patches, and argues technical teams should similarly monitor support signals and verbatims to patch documentation experiences before customers struggle. In short: rulebooks succeed when they teach effectively, navigate cleanly, use consistent terminology, and continuously improve based on real user friction.