When I was a kid, my dad taught me how to play chess. Since he had about 30 years more experience than I did, I didn’t do too well when playing against him. I much preferred games like Pay Day (Parker Bros) or Candy Land (Hasbro), and I played those with a brother who was about my age. They were more fun to me than chess.
As I’ve gotten older, I’ve noticed that I steer away from the preferences I had as a kid. If you ask any board game hobbyist about their opinion about Candy Land, they’ll probably include the phrase “game for kids” in there somewhere. People don’t typically put together a game night and make nachos to play Candy Land with their adult friends.
Most games geared toward younger audiences depend on luck. In the words of Harvey Dent from The Dark Knight, chance is “Unbiased. Unprejudiced. Fair.” Luck is no respecter of persons, and dice roll the same way for everyone. My games of chess against my father may not have been completely fair because of the skill gap, but Candy Land was completely luck based, and I could stand a chance there.
But chess and Candy Land, despite their many differences, have something in common: good visibility of system status.
What Is Visibility of System Status in Board Games?
One of the 10 usability heuristics put into the world by Jakob Nielsen, the visibility of system status suggests that designers should show where the user is in their process, give feedback promptly, and continually and openly communicate with the user. Let’s consider the website for the Nielsen Norman Group, who have an article on this usability heuristic.
The new user of this site — well, that’s you if you haven’t actually seen this before — just given this link should still be able to tell where they are. First, the navigation bar under the group’s name highlights “Articles,” so that means this is probably an article. Then, I know how I can get around to different topics of articles, go home, or search. Even if I just stumbled across this website, I should know where I am and what the site is trying to do.
If we want to communicate to players in board games, we first need to consider what we need to communicate. Many games include a score tracker to show where players are. One such example is Ticket to Ride, published by Days of Wonder.
In Ticket to Ride, players gain points in two main ways. First, players can lay out trains on the board and score points for the length of the completed train track. Second, players can connect two cities with their trains, completing a secret objective to score the points listed on its card. This difference is amplified by when these different ways are scored.
According to the rule book, players should score points for the length of built tracks when they’re played, and score the points for the secret objective at the end of the game. If we follow these rules, each player should know where their score is relative to the other players throughout the game, since scores are tracked around the edge of the board. But at the end of the game, there’s a bit of a “gotcha” moment, where a player that was seemingly behind had a completed objective cards that could put them in the front.
As house rules for some games of Ticket to Ride, we’ve decided to add up points at the end of the game instead, simply because it was too tedious to keep track of the score during the game. Offloading all the math until the end makes the game a little more enjoyable, but at the cost of not knowing approximate player position. An experienced player could guess positions based on the board state, or anyone who cares could count score, but the game feels different from the intended rules with that one change.
How does this apply to web development? Sometimes, we want to put some extra load at the end of a flow. For example, online stores like Amazon will mirror real-world stores and only show taxes during the purchase — at the end of the flow. That may be since the purchase process depends on calculations from all parts (in Amazon’s case, it may be based on the state or country you’re purchasing from). But making users aware of their position during their experience can help with continued usage by helping establish trust, since you’re communicating regularly and accurately.
Perfect vs Imperfect Information
In chess, each piece moves in a different way. During the game, this doesn’t change. If you stumble across a chess board mid-game and you know how to play, you could say with accuracy what the current player’s options are. The information about the game is complete at any given moment. It is perfect information.
Similarly, Candy Land is a game with perfect information, but it’s not strategic. Players will just draw cards and move that number of spaces. They do not need to plan or think. If I know the order of the deck and the number of players, I can say with certainty who will win each time. Contrasting that with something like Uno (published by Mattel), even if I know the order of the cards, there is still room for player agency, so anything could happen. But even still, Uno qualifies as a game with perfect information.
If all the options for the player are always laid out, and you can always tell where they have been and where they could be going. You know what your valid options are based on their options, and you can plan accordingly. (Though, in the case of Candy Land, your plan would be just to pick up another card and see what happens, but I still know what the other player will do next.)
But games don’t require perfect information to be enjoyable. One example is Go Nuts for Donuts, published by Gamewright. In the game, every player privately picks a doughnut on the table marked by a number. Then, once all players have decided, they reveal the number doughnut they want. If anyone has matching numbers, no one gets the doughnut at that number. Otherwise, they get the doughnut at the number the picked.
Everyone is given the same options for the numbers they can play, and the same options for doughnuts. We all play these numbers simultaneously. I don’t know what the other player has picked (though I may have a guess based on their previous choices). My information is imperfect, but it makes the game more fun than going around in a circle and having everyone pick just one doughnut at a time. It’s something that makes the game stand out.
How does this apply to web development? Perfect information is probably preferred for web development whenever possible. Knowing what I have done and what I can now do is a big part of feeling comfortable on a site. Imagine using a site with an imperfect information model: Whenever I input a value in a field, it fills in another one — or even the same one — simultaneously with another value. Was I responsible for filling in that second field, too? How would I undo that while keeping my value where it is, or can I not? Progressive disclosure is nice, especially when it is immediate, but not to the point of having navigability suffer like that.
Reward Schedules and Operant Conditioning
We need to talk a bit about luck. Most games have some degree of luck to them, even if it’s just determining who starts the game. I enjoyed Candy Land over chess as a kid, partially because I felt like I could win by getting lucky. Since the game is completely deterministic, it really does come down to “luck of the draw.”
One possible explanation why I found it enjoyable despite this was because both the random nature of victory in Candy Land and the random chance of getting a good move is based on a variable ratio reward schedule. Variable ratio reward schedules are similar to slot machines: I don’t know if I’m going to win, but I’ll keep trying because I’ve won a little before. The big one is just around the corner, right?
The small investment a player puts in a slot machine can yield an immediate return on that investment, though whether that return is in fun or intrigue or money is part of the appeal of the game. Similarly, Candy Land doesn’t have much of an investment at the start, and every turn I don’t know what card I’m getting, so I become excited when I get a good one.
This type of reward schedule, though, is contrary to the principle of visibility of system status. As an extreme, consider a website where I don’t know when my click on the home tab will actually take me home or just play a spiffy animation. Or even consider if there was a small chance that I could find a golden ticket in a chocolate bar. If I find it, that would be great (assuming I knew what it was for), but the vast majority of consumers will be met with disappointment for not finding it. There needs to be a careful balance between rewarding the user randomly and making sure they know how they can get rewarded.
Remember: You can’t impose joy. Let the user know what they can do to find their own joy with the system by completing their tasks.
How does this apply to web development? If we make it clear why the user is being rewarded, it can help them avoid superstitious behavior. If we give out promo codes to users in a seemingly random way, they may be more prone to buy or interact with our site, but once they realize there’s only a 1/1000 chance of getting it, they’ll probably opt to wait for an email discount code; we would gain repeat purchases in the short term, but possibly lose them down the line. Say why they’re getting a promo, and make it clear that it’s a special occasion because of something they did to help manage expectations.
Conclusion
Maintaining the visibility of system status with cardboard and with web development can create a more enjoyable experience overall. Showing users where they are at now instead of offloading extra calculations to the end of some milestone may help at times, but at other times it’s too much of a cognitive load. Progressive disclosure can both show the user’s progress and how their actions affect their environment. Sometimes new users or players need a little bit of luck to complete the tasks they need, but we can manage that luck. We have opportunities to design things in a way to communicate with our users while not screaming at them with help text or dialog boxes by maintaining visibility.
Additional Resources
If you want to learn more about visibility, communication, or board game design, including methods not discussed here, I’d recommend the following.
- Mark Brown runs a YouTube channel called Game Maker’s Toolkit, which talks about video game design. This 20-minute video talks about luck, and the principles discussed there apply directly to board game design as well.
- For more thorough examples of visibility across the web than the examples I posted here, you can reference this article by Jeff Doubek. Jeff shares examples of how to communicate visibility without using text through graphic changes, if you’re looking for help there.
Read the full article here
