More on Choice (and Dragons)
January 26, 2012
I’m a sucker for adventure games. Most of my favorite board games are short, focusing on getting a good resource or point engine running and then stopping right as players hit their stride. But I’ve spent the last 10 years wanting to dig into a really epic adventure game, the kind with a 30-page rule book, where you get to see your choices pay off.
This past weekend I stumbled upon perhaps the holy grail of adventure games, a surprise hit from 2011 called Mage Knight. It’s got all the geeky elements I want – exploration, conquest, leveling up, and of course dragons.
I’ve tried this sort of game before and they’ve all fallen flat for two reasons. First, all players need to know the entire rule set before they can take their first turn, and teaching it can take as long as actually playing it… which is a long time. And second, the same freedom that makes a game open and adventurous can also make it overwhelming and paralyzing to play.
Mage Knight’s rule set allows a huge pool of possible decisions that could be made every turn, but it keeps the playing experience enjoyable in a unique way. Every action the player can take is printed on a deck of cards, and the player draws a hand of action cards every turn. While many actions are possible, only the ones in his hand are available at any one time. This keeps the rule set very open, but the decision tree for any turn manageable. Playing the game is more like filling in Mad Libs than writing a novel. There’s enough choice to have fun, but not enough to become a burden.
On a semi-related note, I’ve been reading up on Domain Driven Design, CQRS, and Task Based UI. Obviously, in the software world, we can’t arbitrarily limit what information and choices users have access to in the way we can with a game and a deck of cards. Losing a game to the luck of the draw is part of the fun, but losing productivity because you can’t access the tools you need is… not fun. But if we as developers can work with domain experts to boil down the essential tasks that users need to take at any point, we can relieve the user from the trouble of figuring out how to accomplish those tasks via interfaces that provide a bunch of unnecessary extraneous options.
The Paradox of Choice
January 23, 2012
Barry Schwartz’ TED talk about choice from a few years ago remains one of my favorites. (Warning: semi-NSFW slides in the middle)
In a nutshell, Mr. Schwartz studies the effect of presenting choice to consumers. Some choice is clearly better than none, but there is a point where more choice just confuses and exasperates the consumer. In areas where I must make choices, this talk resonates. I feel his pain when shopping for everything from computers to toothpaste. Too much choice is not better than just a bit of choice (provided that the latter choices are at least passable). On the surface increased choice seems to add value, but it frequently only frustrates and disappoints.
As an interface designer, I have learned the hard way that I can accidentally put my users in a similar bind by attempting to give them too much robustness. Some of the most dramatic improvements I have made in my software have been by hiding choices from users. A few years into maintaining a project, I made an eye-opening observation during a training session. I was demonstrating features to new employees, and several times their managers, who I consider to be power users, gasped when I pointed out a button, remarking that they never knew that feature existed. The screen was so full of buttons that they could not discover on their own what each one did and use it to their benefit.
Determining what choices to limit or take away is a delicate but necessary process if the goal is to create a positive experience for the consumer.
Welcome!
January 23, 2012
In time, this site will be the intersection of my interests – technology, music and board and card games.
Thanks for stopping by. I look forward to sharing my thoughts with you.
Matt Moberly dot com 