Board game UX: help and documentation
Board game UX: help and documentation
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 Arcadecome 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.