I’ve recently been playing Tribes:Ascend. It’s a wonderful game with a major flaw, one that digs into the roots of the game’s overall experience.
Do you see it? It’s subtle.
There’s no “random team” button.
A simple non-simple decision
On this screen, Tribes: Ascend forces the player to make a simple choice: Pick your team. For those unfamiliar with the game: There are no differences between the teams aside from the name, the look and some of the voice work. They each have the same weapons, classes, and abilities. The maps are mirrored and neither team ever has a stronger starting position.
For some people, this choice is simple. Pick the one you think looks coolest. Pick the team with less players. Pick the one you weren’t on last game. Whatever, let’s just play.
For some people, this choice is Kafkaesque. There are a million factors at play. Everything that happens during a match boils down to which side of the screen they clicked on at the beginning, whether it’s a glorious victory or a humiliating defeat.
Since I’m one of those people, let’s examine some of the factors.
Who’s playing? Press Tab and you can see that the two star players from last round just joined Diamond Sword.
Which team is in demand? Don’t worry about finding the data for yourself. Just watch the numbers and see which team is in higher demand, then try to join it.
Who’s winning? Press Tab as you’re coming in late to see the score. In a 4-0 match, the team with 4 is probably going to win.
Who’s good? Again, press Tab. The game conveniently ranks players, just in case you don’t have experience with a particular player. Join the team that has all five 20+ ranked players (a common occurrence).
The point here is: If you make me do something, I’m going to do the most informed, best-for-me thing I can possibly do. Every time.
Unintended consequences
I’m not alone in this practice; if I were, it wouldn’t work. I’d imagine there exists a population of Tribes:Ascend players who have a very good record– not because they’re stellar players, but because they’re good team pickers.
It gets worse, though.
So far I’ve just been discussing the in-game factors. Tribes: Ascend already has a thriving community despite its closed beta status. A recent high-profile game between Reddit and /v/ ended with a big defeat for the Reddit team.
The Reddit team who happened to be playing as Diamond Sword.
So now there’s an entire group of players– experienced, plugged-into-the-community players– who have this whole new, outside-the-game reason to pick Blood Eagle. I don’t have the stats, but I would guess Blood Eagle has just generally been winning way more games since the Reddit/4chan match. It’s at least been my experience. Jump into any match and you’ll see a few taunts after each round, almost always taunting the silly Diamond Sword “sandrakers.”
Since this behavior is self-reinforcing, you’ll see a surprisingly high portion of games end with scores of 5-0, as one team (lately, usually Blood Eagle) repeatedly steamrolls the other.
Sometimes it’s even more complex, with a group of highly skilled players jumping between teams but always playing together and stacking the odds in their favor.
These games are relatively boring for both sides. It hurts gameplay. It drives away newbies.
Is it all because there’s no “Random Team” button? Yes. At least for me. Give me that button and I’ll use it every time I play, never again worrying about joining the better team when I join a server or start a new round.
It’s a choice that I just don’t want to make.
Choices in web UX
The Tribes: Ascend dilemma reminds me of some others in UX for the web. (Tribes readers, feel free to check out here!)
Choose your password
8-12 characters. Has to include numbers. Cant’s use underscores or spaces. Rules, rules, rules.
We’ve all run into the situation where our password of choice, whether it’s the one we use all the time, or one generated for a particular site, just doesn’t work with the website’s password rules.
It’s a really, really stressful situation. The user now has to remember that a website is an exception to his/her password policy, however simple or complex it is. Should it be written down on a Post-it? Will that get lost? Will he or she be doomed to use your password recovery every time he or she wants to use the site?
Spare your users the stress and let them use whatever password they want. Make password rules as flexible as you possibly can.
Enter a coupon code
This might be the worst. You’ve committed all this time and effort to the buying process and you come across this gem right at the end, which throws everything in disarray.
“There are coupon codes?” you ask, along with every other user to ever get to this point.
Some people press on, slightly dissatisfied knowing that some jerk somewhere is getting a deal and they aren’t. Others open a new tab and Google around for coupon codes. And some people just quit right there, because they know they’re about to put in a lot of work for a 10% off and an aggravated compulsion complex.
Don’t use a coupon code field. It’s better to use specialized URLs which automatically apply the discount code.
Pick a username
If your online product doesn’t need user names, then don’t use them. Use e-mail addresses.
If it does need usernames, then try to make it clear to the user exactly what they’re getting into. Plenty of people have been burned by picking and being stuck with stupid usernames (SexyLance69@hotmail.com) and still hold on to sensitivity there.
Bonus points: Letting the user change their name, like Twitter does.
Be really careful with the small big decisions
Really tiny decisions made at the beginning can impact everything that happens afterwards. Be especially careful when you design these parts of your product’s experience.
And if it works, always give your users a “Random Team” button.
