UXMatters recently posted a great article called “Quieting the Outcry over Software User Interface Redesigns.” It touches on something we’ve probably all experienced on sites like Facebook: the moment there’s any significant redesign of the site, half of our feed is full of outrage over the change and threats to quit that almost always prove to be empty.
As a UI designer, it can be hard to figure out where that line is between legitimate user frustration over something that turned out to be a poor design decision on your part, and the knee-jerk reaction to change that’s very common when people have become accustomed to doing things a certain way and finding things in certain spots on their favorite web sites (or the game UI they’ve been using for the past few weeks). This article provides some great information on how to avoid that reaction (or mostly avoid it, since there will always be a vocal minority that hates change even if it’s for the better). But there is one small bit that I disagree with.
In addition, evaluate the groups of users who are complaining and the tasks with which they’re having problems. Are they representative of the primary users of your product? Do they match one of your key audience profiles? Are they typical users? Are they upset about something relating to a key task—or a secondary task that users rarely perform? For example, removing a command-line Interface tool might make a tiny group of users very upset, but benefit 99% of your target audience.
I thought this was a poor example of a good point the author was trying to make. The usual goal of UI design, whether it’s for games or for applications, is to make interactions simple. But frequently we as designers can take that idea too far and begin watering down gameplay or feature richness for the sake of UI simplicity, losing useful and in-depth features that the user may ultimately benefit from and enjoy once they’ve crossed the line from beginner to advanced user.
Instead, why not think of something like a command-line interface tool as a deeper, more richly-featured layer of UI that can remain in place as something accessible to the more hardcore users? In fact, a command-line interface is a great example that’s directly applicable to games. Many online multiplayer games require servers to run, and for some games these servers are run by the players themselves, usually by players who are technically adept and know their way around a command line. For years, running a server was almost always only possible via the command line, but it’s now pretty standard to include a GUI in the main menu with most of the common options a server administrator would want to set. And in most of these games, the command line interface is still accessible and allows really knowledgeable server admins to set many more advanced options on their servers.
The percentage of server admins compared to players is going to be pretty small for any game, but those server admins are a very important component of your game — without them you’d have far fewer servers to play on. Instead of cutting the command line interface because it’s advanced and only used by a small percentage of players, the ability to run a server is made accessible for both beginner and advanced players by adding an outer layer to the whole game UI.
Not every UI decision can be treated like this, of course. In some cases a game mechanic may be very complex, and the only UI solution that works with it may be equally complex. In cases like this, the questions to be answered are these: is there any way to create a layered UI solution that helps beginning players grasp the basics of the mechanic, but gives advanced players the information they need to play at a higher level? If there isn’t, then does the mechanic need to be simplified in order to make it accessible to the highest number of players so it doesn’t turn people away? Or would simplifying the mechanic unacceptably water down the gameplay goals?
In the best game UI design scenarios, layered UI can be created so that beginners don’t feel alienated by advanced features or mechanics that they don’t yet understand, but the more advanced layer of UI still exists so that when players are ready to go from beginners to advanced users, they can level up in their UI skills as well as their game skills. Yep, it’s gamification of the UI — if you’re a Photoshop user you’re probably familiar with the feeling of mastering the deeper layers of complexity within the app, and it’s something that can happen in game UI, too.
So while we may run into situations in which we have to consider cutting that feature so that 99% of our audience is made happier, I like to approach game UI problems as layers of an onion first. Sometimes with more eye-watering, depending on how hard the problem is to solve.