Board game UX: help and documentation
Documentation in web design is usually a secondary goal. But in board game design, it’s necessary. What documentation tips here can we apply?
Whether you’re a board game hobbyist or someone who has only played one or two board games in your life, I want you to think of a board game that by design does not have a rulebook. Players are able to infer the rules from the layout of the board, the game pieces, and any other trinkets that lay around. Anyone within the target age demographic should be able to decipher how to play this game without as much as a word being spoken or read about how to play.
This sounds like a fairly impossible task, and with my experience in the board game hobby, I’m fairly positive that game does not exist today. On the other hand, though, there are a few examples that absolutely need rulebooks due to the various uses or roles of their components (504 and Pyramid Arcade come to mind as examples). Without some system to check decisions and actions against, board game components can be used for pretty much anything.
A guiding hand is needed in board games, though it may be pushed to the side when considering the UX of websites as a supplementary nicety. I’ve written a bit about how good board game UX helps prevent errors, but not all errors can be prevented by the methods I list there. Yes, including player aids, marking the current game state, and playing with others familiar with the rules help considerably. But whenever there is confusion or a dispute, players will go to the rulebook.
With this kind of dependence on help documentation in the UX sector, we should look to board games as examples of how to have documentation readily available for users and to have answers to their questions readily available.
Component UI: When Components Give Instructions
The game Azul has become something of a modern classic, and it is fairly approachable for new hobbyists. One of the reasons for this approachability is the limited components and the clear affordances on one side of the board, pictured below. It’s fairly clear which pieces go where: the blue snowflake pieces go on the blue snowflake squares, the red pieces on the red squares, and so on.
This is good design, but it’s not necessarily what I mean when I say that component UI can act as help documentation. The board, while helpful, leans more toward error prevention than gameplay instruction. In fact, the opposite side of the board pictured here does not have these colors and the rulebook suggests it as a variant, not as the way to teach the game. Neither side of the board talks about progressive scoring nor about piece placement and why the image above is technically incorrect.
If we want to look at instructional component UI, we should probably refer to a game that is based on cards. One such game is Abandon All Artichokes. In the game, players try to remove artichoke cards from their hands by playing other vegetables from their hand. Each non-artichoke vegetable has an effect printed on the card with clear instructions on how to use it.
This written text says clearly what is needed. In the example of the onion, the player who uses the card would compost (or remove from their deck) an artichoke, and then give the onion to another player in their discard pile. Key terminology (compost, discard pile, etc.) is given special emphasis by capitalizing the words, and players are informed about the role of the card.
While the card could just have icons with explanations in the rulebook about their meaning (which other games have done with commercial success and industry prestige), including the text helps players not need to refer to the rulebook as frequently when learning to play. The rulebook still lists the card effects, and it includes some edge cases where applicable. The information is relatively easy to search with the images and labels next to each card, and steps are clearly defined. But maybe I’m getting ahead of myself… we’ll talk about rulebooks in a little bit.
The cards in Abandon All Artichokes provide users with information on how to play them, spelled out plainly on the card, but they also provide enough detail without the text to remind experienced players what to do with the cards.
How does this apply to web design? While your components may have the proper affordances and signifiers, they may still bring some confusion for new users if they’re unique to your site or app. Don’t be afraid to include optional help text when needed. Just make sure they know how to click that one.
Player Aids: In-Context Reference Tools
As a board game hobbyist myself, I’ve taught a lot of games in my day. Some games are more complex than others, and you probably shouldn’t expect your 5-year-old to join you for games of Gloomhaven on the weekend. But even when playing with the target demographic, you probably still need to provide clarity about specific rules while the game is being played.
One common solution to this problem is to include a player aid: a component that can help players remember something found in the rules. Some player aids are shared between players (e.g., Sushi Go Party! has a central board that shows which cards are available, but it’s technically not necessary for play), but most are given to players for their personal reference. This allows players to see information without needing to sift through the rulebook, potentially allowing the rules to be left in the box. It helps allow recognition instead of recall, too.
As an example of a player aid, we have Battle Line: Medieval. The game consists of players putting cards (numbered 1–10 and in six different suits) into battlefields, where the player with the best three-card poker hand on a battlefield wins it. The player aid below shows what counts as a formation, which are most powerful, and what examples look like. The other side of the card also shows the general objective, turn order, and some of the finer details of the game itself.
The player aid does its job, but it could be improved: the font size with the rules- is a little small, the example hands show all the suits but not all the numbers, and easily forgotten rules on the back may not be emphasized properly. But the player aid itself is easily accessed by players and it complements the rulebook.
As a less graceful example of a player aid, let’s look at Fort. The primary player aid is shown on the left in the image below and has a breakdown of the visual language of the game’s icons. Iconography in board games is appreciated for the international market to keep costs down and to make the game more accessible for those with difficulty reading, so this isn’t explicitly a bad thing. However, the player aid lists four sections: Suits, Things, Modifiers, and Actions.
Let’s talk about “Things.” It’s an odd choice for a category label on a player aid, kind of like a grab bag section. It’s even more odd that the rulebook has them listed in a section called “Other Action Symbols,” and that two of the icons under “Modifiers” are listed under that section in the rulebook. While this player aid gives a good summary of the information from the rulebook, it is a bit disjointed to allow using the rulebook as a reference, especially since some of the iconography looks similar.
To be fair, I enjoy playing Fort. The player aid doesn’t diminish my enjoyment, I am comfortable teaching the game and how to use the player aid, and I can find what I need in the example-rich rulebook. You can still have a good experience as a player in most circumstances generally despite some minor inconveniences with help documentation. But those inconveniences can further sour the experience when there is confusion about the rules. Making sure there is a match between the player aid and rules is crucial for clarity and helping resolve confusion.
How does this apply to web design? Help documentation in context is important. Ideally, you won’t need to write paragraphs of text or create a video walkthrough of the tool. But showing users what they may need to know to make good decisions in the moment, knowing they can fall back on those sources, can create peace of mind while using your site. For an example of this, see this article.
Rulebooks: Extensive (and Necessary) Documentation
Rulebooks have undergone a bit of a renaissance over the past several years. While I cannot pinpoint the exact date or game to start this rebirth, looking through my collection and basing their rules on the game’s age, I’d estimate it started around 2010. Since that time, rulebooks have gotten better at conveying information. Gone are the days when games could come with a piece of waxy paper folded like an accordion to house rules printed in Arial or Times New Roman, with some italics and bold words here or there.
As a hobbyist, I read through a lot of rulebooks. And as someone with design training, I’ve noticed some trends about what makes a rulebook effective and what makes it less effective. Of course, there is a lot of overlap with good user experience and technical writing.
The first thing is information hierarchy. Most good rulebooks share the same order of their contents. It goes a little like this:
- Backstory of the game, trying to suck you in through narrative, including the objective within this narrative (e.g., create a successful business, escape a black hole, cure the pandemic). If the game has little or no theme, this can be glossed over, but there should be some “selling point” of the game upfront.
- How to set the game up, highlighting individual components (typically with pictures) and what they are named for reference later. Include examples when needed.
- The goal of the game in gameplay terms, not narrative terms (e.g., score the most points, reach the finish line, be the last player standing).
- What happens during each round, turn, or during simultaneous actions. This is the meat and potatoes of the rulebook, but the framing before and after helps the reader understand specific details. Include examples.
- How the game ends and scoring. Sometimes, there’s overlap with the goal in gameplay terms, but it needs to be stated clearly again. If the game has a score involved, there’s a breakdown here. Include examples.
- Glossary and FAQ. What some terms mean, quick reference guides, and some special edge cases that help players have an official ruling on something weird.
This order seems to follow the GOMS model of instructional psychology. Players are given goals to accomplish in the games (1 and 3, for added emphasis), a set of operators they can manipulate to work toward those goals (2), methods for manipulating those operators (4), and a way to determine if they are making good decisions (5). This model is so effective in board game rulebooks that it has been translated to video format as well by various content creators, whether intentionally or unintentionally.
Another thing to consider is the length of rulebooks. Well-written rulebooks vary in length depending on the technical complexity, not the cognitive complexity. Using common games as an example, the rules for chess fits on two pages, though it is much more cognitively complex than The Game of Life, which takes twice as many pages to explain its rules. In other words, if the game needs more explanation for its various components, or if the game has more exceptions to its rules based on events or timing, the rulebook will be longer. Longer rulebooks are not necessarily a bad thing, but they may mean some difficulty with getting into a game. Some companies have even begun including tutorial rulebooks or abbreviated rulebooks to let players have experiential learning sooner.
Concise rulebooks for technically complex games are still possible, too, without needing to abbreviate things into more approachable rulebooks. But there’s a delicate balance to hit here, where you can make the rulebook short enough and explicit enough to keep material accurate without needing to consult forums for an interpretation. Examples and images help considerably with clearing up confusion, but it may make the document a little bit longer.
Cat Lady (also sold as Dog Lover with some changes to the gameplay) is a game about collecting cats, feeding them, and getting them toys and costumes. The rulebook for Cat Lady follows a similar outline to the standard format, starting with an overview, components and setup instructions, and then jumps straight into how to play, which takes up about a page of instruction, including an example.
However, at this point, it has a problem. The “How to Play” explains the one action all players can take on their turn clearly, but it does not frame this content with the actual components that could be gained by doing this. After this explanation, it goes to the “End of the Game” section, detailing when the game ends and how things are scored, mentioning components and scoring mechanics not yet revealed. It no longer follows the GOMS model, and would change the acronym to GMSO, which is less effective (and it just doesn’t have the same ring to it, ya know?).
How does this apply to web design? Help documentation is generally an afterthought when making a website, and it goes a bit against the agile manifesto. But accessible documentation is a tool to help users when they’re struggling. Writing this documentation in a way that promotes learning (whether using GOMS or other theories) can help users tackle their tasks with confidence and feel supported by the documentation, not limited by it.
Conclusion
Help documentation and in-line documentation are somewhat supplementary in digital design, but in board game design, they’re critical. If we review the best practices of documentation where it is absolutely required and then apply those to our fields, it can greatly improve the user experience for people that encounter problems or that may just need clarity.
Resources
If you want to learn more about help and documentation or board game design, including methods not discussed here, I’d recommend the following.
- The Nielsen Norman Group’s article on help and documentation. This article goes into some detail on different kinds of help we can provide users, whether it’s proactive (in-context help, like components and player aids) or reactive (user’s looking for information, like player aids and rulebooks). I highly recommend this to anyone who writes this kind of documentation regularly.
- This article on rulebook writing. Most of the points about the structure of the rulebook coincide with mine, but the author goes into more detail regarding the use of images, graphics, and examples than I do here.
- Make It Stick by Brown, Roediger, and McDaniel. For anyone interested in helping people learn, this book is basically required reading. For an abbreviated version, you can read Chapter 8 of the book. Check your local library for a copy if you’d rather not purchase it.
