Board game UX: a study on error prevention
How do you prevent errors in a board game? A quick review on some techniques used in board games and how they relate to tech development.
Board games are a fascinating case of design. There are literally hundreds of thousands of different board games out there, which means that there are upwards of millions of different mechanics, rules, and specialized jargon out there floating around the industry and hobby. Some board games are designed by toy companies, others by companies that follow a game development cycle like that of video game designers, and others still are ventures designed by just one person.
If this sounds similar to software development, that’s because it is. Companies that aren’t explicitly tech companies need to at least dabble in the worldwide web to be competitive. Tech companies can directly design something that adds value to their field. And even one person can create a website or an app that will fill some need.
We can make more comparisons between board game design and software design, but there’s one stark contrast: Board games require manual manipulation of information. Consider a game of Monopoly. In the game, you roll dice and then you move the number of pips shown on the dice. You do this by physically picking up your piece and moving it. A computer isn’t running calculations in the background, and you don’t have an automated drone that picks up your piece and scoots it along the track. You — a human — move the piece.
Whenever people are involved, things run a risk of going wrong. That’s largely because of poor design, and as Don Norman put it in The Design of Everyday Things, “More and more often the blame is attributed to ‘human error.’ ... But in my experience, human error usually is a result of poor design: it should be called system error.” Most UX designers may be familiar with that stance, but sometimes they forget the rest of Norman’s saying: “Humans err continually; it is an intrinsic part of our nature.” In web development, you can plan around the fact that humans make errors by including logic checks and safeguards, but when you’re playing a game of Monopoly with your nephew and your ego is on the line, you’re out of luck. There are no safeguards, and errors — whether mistakes or slips — have a good chance of happening.
Luckily, board game design has come a long way since Monopoly first came out, and designers have made progress in preventing these kinds of errors from happening. Let’s take a look at what is being done in the realm of cardboard to prevent human error so we can turn it to the realm created by circuit boards.
Signposting: Recognition Over Recall
For those unfamiliar with the terms “recognition” and “recall,” think back to a test you had to take in high school. If the test was multiple choice, there’s a good chance that you found it to be easier than if it was an essay question. With multiple choice, you have options — one of which is right — that you can recognize, evaluate, and determine which to bubble in on your answer sheet. If you had to write an essay, the only thing that could help you was the writing prompt itself, and that’s not usually that helpful, so you’ll have to dredge up information from your mind and try to recall things.
When it comes to design, recognition is preferred to recall, since it doesn’t require the user to think as much about their next course of action; they see their next action right in front of them.
For an extreme example of this in board games, let’s take a look at the game Root, published by Leder Games. Root is a war game with asymmetric factions, meaning that each player plays with a different rule set with different objectives, though each player needs to abide by some overarching rules. All this means is that there are a lot of rules, especially when there are 10 factions to choose from in the game, with up to six being in one game. Even if you play with the recommended player count of four, you still would need to know your rules and objectives and three other rules and objectives to play as intended.
To counter this cognitive load, the game features individual player boards for each faction, with faction-specific rules printed on it. Here’s an example of one of the factions.
On the left, players are presented with their turn order. First, the player does the actions located under the Birdsong step, then Daylight, then Evening — a normal progression of time to reinforce how turn order works. Each step also has specific instructions with a text hierarchy to remind veteran players and to instruct new players (e.g., Craft using workshops). This doesn’t require reading every written instruction, but the rules (AKA the help documentation) provide clarity when needed. Players are given the option to recognize their next step instead of recalling it, and you’re less likely to err as a result.
Please also note that the rules listed on the player boards are not complete or “the law,” per se, and there is an extensive rule book with specific and niche situations. The game doesn’t teach players just with the player board, though they also have an interesting walkthrough system they’ve implemented to help new players. If they put all the rules on each faction board, it would be a bit much to look at, and usability would likely suffer.
How does this apply to tech development? Instructional signage isn’t always good, and in fact, it’s pretty bad sometimes. But any type of signifier that can serve as a reminder to the user — yes, even text — can help them have a better time using your system, especially if it is complex. While you should probably steer clear from putting paragraphs of text everywhere on your website to explain how to use ambiguous buttons, don’t think you need to commit to using just images and SVGs.
Clearly Defined Phases: Component Addition and Removal
In Uno, players are required to either add or remove cards from their hand each turn. Since you can’t always play a card and may need to draw a card, there may be a point in a normal game when everyone playing has a different number of cards in their hands. Let’s say at that moment, all the players get distracted because pizza showed up at the house, so they decide to take a 15-minute recess to eat food and then come back to the game.
With all the components that come in the box, how can you tell whose turn it is when they get back? Players don’t have a marker for who the next player is, and they all have wildly different numbers of cards. Players are required to recall whose turn it is.
Maybe that situation isn’t common enough for Uno, since games are pretty short. But it does beg the question about how players are expected to remember some ordinal data in the game.
One way to help with this is the introduction of game components, such as a card, token, or chit that can be used to symbolize something. A lot of modern games have first player tokens, but some take it a step further to add a “current player” token.
For example, take the game Tiny Towns, published by AEG. The white hammer (located in the top left of the image above) is used to mark who is the active player. In this game, every player takes pieces to place on their board at the same time based on what the person with the white hammer says. Without a marker, this could cause confusion about who declared what piece, since everyone is involved on everyone’s turn. Including a token — in this case, the hammer — can mark the current player, which can then be passed to the next player. That way, everyone is on the same page about whose turn it is, even when walking away from the table for some pizza.
Similarly, you can do the same thing by component removal. Instead of adding a token to a player’s goods, a player may be able to pay a token or reveal hidden information to show that they’ve made a move.
These methods can prevent error by reminding players to not act out of sequence with a physical, real-world reminder.
How does this apply to tech development? Errors can be prevented when a user knows more about where they are in the process. To use the example of filling out a form, if the form has clearly labeled steps that show that they’ve been completed when they’re done, they now know it’s safe to move on and that they won’t get an error. This can be done by making a button active when it previously wasn’t, putting a tick mark to replace the step number, or any other method that works during user testing.
Data Validation: Additional Players
Probably the most common way to prevent errors in games is the inclusion of other players. While some people play board games solo, the majority of casual players probably don’t, apps excluded. Other players are able to check the actions of their peers to make sure no one is cheating, to remind players of rules, and to showcase strategies and other techniques used in play.
To put this in research terms, it’s like everyone around the table is doing an ethnographic field study, where each player can see how others are using the system and make judgements about their own behavior as a result.
That being said, though, each player is also doing an audit of every other player’s actions. Whether it is to check for strategy tips, reminders about rules, knowing how to plan for your next turn, or preventing cheating, each player is invested in the state of the game to some extent.
Fury of Dracula, published by Fantasy Flight Games, is a game where one player acts as a vampiric Dracula who is able to move secretly through Europe with the goal to do what vampires do best: drain the blood of the population. The other players try to find and stop Dracula before it gets too late.
Since Dracula is able to move secretly through Europe, no other player knows where he is at any given moment (without, of course, the deduction gimmicks of the game or under specific conditions). This leaves the player controlling Dracula essentially unchecked and able to move about freely across the board, possibly evading his would-be captors until he wins the game. I would discourage playing a game with someone who is actively cheating like that, but I’m sure someone has done it before.
The twist, though, is that Dracula does not go unchecked. The rule book has rules regarding Dracula making an error — whether a slip or a mistake, it doesn’t matter — in a label simply called “Cheating.” After declaring the punishment for making an error, the rules end with this statement:
Although it may seem severe, the hope is that the Dracula player will quickly learn to be more careful in the future. (p.25)
In this case, the rules expect players to be responsible for error prevention and making sure that the data that are being manipulated on the board are accurate. The Dracula player has a high investment in not erring (as the punishment is severe), and the other players are eager to catch the Dracula player committing an error in hopes of making the game easier for themselves. Every player has some interest in making sure the game is played correctly.
How does this apply to tech development? Typically, we want to avoid the need for manual review of information, since that can be time-extensive. We also want to have broad acceptance requirements for different file types or formatting for things like phone numbers. But making users aware of the risks of putting invalid data into a form or system can help them watch themselves more carefully, too. Flagging incorrect data early (before hitting “Submit”) can help them not make a lasting mistake that may take time to undo. Just remember the old adage: To err is human, but to really screw up, you need a computer.
Conclusion
Every technology has some form of user experience. Seeing how complex systems outside of computing prevent errors can teach us a lot of lessons about what we can do in our UX roles each day. Whether it’s by signposting, marking phases clearly, including data validation, or by doing something completely different, we can help users to avoid errors, and we can be proud of our designs.
Additional Resources
If you want to learn more about error prevention or board game design, including methods not discussed here, I’d recommend the following.
- The Nielsen Norman Group writes many articles on usability, including one on error prevention. You can access that article here.
- Board Game Design Lab, hosted by Gabe Barrett, focuses mostly on board games. They have plenty of free resources available, including this page with many references about how to write rules for clarity and to prevent error.
- A brief summary of the famously controversial Milgram and Zimbardo studies also can be helpful in conjunction with the point of data validation through other people. While the studies are considered unethical by today’s standards, they help show how someone’s behavior can change by simply having an observer (or another player) there with them.
