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.
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:
For docs, the game is not over. Insert a coin.