What tech writers can learn from video game manuals

I’m not only a technical writer and an avid collector of old manuals: I’m also a gamer. One of the bits I always enjoyed about video games were the manuals, from the slim booklets that accompanied arcade games to the hefty guides that helped build virtual worlds in our heads while we waited for a few kilobytes to load in memory. Those manuals still hold valuable lessons for the software documentation we write today.

Nowadays, video game manuals are a rare sight, replaced by in-game tutorials and lore that, to be honest, I rarely find engaging. For example, I almost never read in-game books, primarily due to the uncomfortable experience of reading fake tomes on tiny readers. So I rely on wikis instead, which are ripe with information but are also difficult to read in a linear fashion, leaving knowledge fragmented and hard to explore.

Luckily, since gamers are notoriously more self-conscious and appreciative of the history of their medium than technical writers, elegies and retrospectives of game manuals abound. Manuals added to the gaming experience in ways that UI help doesn’t. The physical factor of printed manuals, the art, the additional lore… All that contributed to make the experience of playing video games more enjoyable.

The SimCity Classic manual (1993) included urban planning theory

The quality of manuals (and even the boxing) determined whether a game would get a high rating in specialized press. Zzap!, for example, was a video game magazine that regularly reviewed technical docs, the game manuals, as part of the overall analysis. Not including manuals, or packaging a poorly written leaflet, was bad.

In many cases, manuals were created by dedicated writers. Game manual writers and technical writers share many core principles, such as brevity and the use of examples. Even our struggles are similar. In Manuals: They Can be Good (1999), Arnold Hendrick wrote the following lines. I’m sure you’ll nod along as you read them.

There are those manuals who actually believe the programmers’ claims about self-explanatory software, allowing them to take the easy way out with a manual that contains nothing more than “background” and “color” (i.e., bad fiction).

Game manuals, then, were a serious business. At the same time, they also sought to entertain the users of games. Well, that’s obvious, I hear you saying, games are entertainment. And yet, while I agree that ingredients such as humor are to be used sparingly in most cases, I think some of the principles we see in game manuals  could be used in business software documentation.

Yes, I said it. We can be fun.

Bringing the fun of video game manuals to tech docs

That fun experiences help learners is a fixture of educational psychology. That we learn by playing or role playing from the earliest age is also well known. When it comes to software documentation, though, fun is taboo. Sure, most business software is way more boring than video games and less pleasant on the eyes, though one could argue that software, like games, aims at solving problems. You win at something, be it Excel, observability, or data science. You get the desired output and you’re hooked.

Security Journey uses cool RPG maps for navigating through learning courses

Like it happens with children’s books, when looking at game manuals from the perspective of a technical writer, one must ask oneself what things are possible. In other words, what features from our cousins, the game manual writers, could we borrow to make our documentation more successful (as in more engaging, useful, influential, or whatever your level of the docs hierarchy of priorities requires)?

The following are the five key aspects that one can consistently find in the best game manuals that could also work for software documentation:

• Docs can be beautiful: These days, technical writers are lucky to have resources for publishing the docs, let alone making them good looking. Still, the documentation that we remember best is usually the one we find not only well written, but also beautiful. Some examples: Stripe, Viam, Spotify.
• Docs can be lands of lore: The best game manuals included what gamers commonly refer to as lore, that is, background information, the setting and history of characters and places, and more. Software is never born in a vacuum: a changelog is in itself lore, as is explaining past issues.
• Docs can let you choose your own adventure: While games benefit from having a single, motivated user persona, their manuals do their best to walk players through the essentials using careful design and layouts. Software docs can afford to be opinionated and present users with journeys.
• Docs can use a friendly voice: In recent years, we’ve witnessed the rise of “you” and active voice in documentation. We’re still far from the tone of game manuals, but nothing prevents us from experimenting with it. After all, AI assistants will strive to be friendly, so why not doing the same in our docs?
• Docs can be a product: Game manuals like Falcon 3.0’s could be enjoyed independently from the game they described. They were carefully crafted artifacts that stood out on their own. Software docs, when they receive the same amount of love, can be as memorable (think of Stripe).

For docs, the game is not over. Insert a coin.