Design Axioms for Game UI's - Part I: Data

The least consistent aspect of modern digital games is the quality of the UI. This is due to a variety of reasons, including: UI design not being a widespread profession until just the last 10-15 years; the cross-platform nature of games; and the variety of input/output devices they are played on. As a result, few developers are trained in UI design, and knotty UI challenges await designers every time they start on a new project. This leaves us with a world in which game UI's are rarely great and often poor.

Earlier this year I contributed to Involution Studios' set of Design Axioms (www.designaxioms.com). These are the approaches we've used to design software for Apple, Microsoft, Raptr and the Obama Administration. Geared toward UI design, they are rules for achieving exceptional UI design and are very applicable to crafting better game UI's as well. There are 17 of these rules, covering all aspects of UI design. Today we're going to look at axioms relating to data.

Data
Data is the most important part of any UI: what the user, ultimately, is there for. Whereas in software UI the content is generally written and not visual, in game design the opposite is true. Most games are predominantly visual, and the importance of those visuals is well-recognized and acknowledged by the team. Some more strategic games, like those produced by Paradox, have a greater weight between primary visual and secondary visual and written information. But, in general, modern game design "data" is dominated by the game's graphics. This actually makes it even more important that the written information is well-designed, since the focus is so much more prominently on the dancing pixels.

Given that framing, let's talk about two axioms for designing your data:

Let Data Scream
You need to figure out what the most important data in your game is and put the focus on it. Most modern games have decided that sexy graphics are the most important data, and gorgeous graphics are correspondingly prominent. But to really understand the challenge around game UI data problems lets talk about an infamous game that presents gobs and gobs of written and statistical data, Out of the Park Baseball.

Out of the Park Baseball is infamous because it has one of the highest MetaCritic ratings of all-time despite not being a particularly good game. Blame the fact few mainstream reviewers rated the game, leaving a small group of baseball wonks to push it into the stratosphere. The thing that sports simulation nuts love about OOTP is the gobs and gobs of data. The reason why OOTP is broken for the rest of us is terrible choices around those gobs and gobs of data. Consider the main screen for looking at one of the fictional players in the game:

OOTP screen shot

While it may appear that the data is screaming in their design, that’s not the case. They've made terrible choices about WHAT and HOW to display such data. All of the junk data they are showing obfuscates the really important stuff, which is hidden. Part of the problem is a total lack of “use case” around looking at a player. You see, for someone using this game, you would want to view a player for a variety of very different reasons. Among others, decide: 

 Each of those use cases requires different information. Neither this - nor any other single screen in this entire, large application - achieves any one of these objectives. The data is sliced and diced in many different places, hard-to-find and impossible to aggregate. Arguably the most important screen in the whole game, the player's profile page, gives you adequate information to reliably address zero of those use cases.

While part of the problem is a lack of use case-driven design, resulting in what Edward Tufte (www.edwardtufte.com) would call "chart junk", the more general design problem is that by making everything important, nothing is important. The designer has elected to give us small, incomplete sections on "Personal Details", "Status", "Personality", "Defensive Ratings", "Basic Pitching Ratings", "Other Ratings" and "Statistics". Let's assume the designer is attempting to cover so much in order to handle the largest breadth of use cases. That is a reasonable explanation, even though it fails. But assuming that explanation, why is "City of Birth" included? Why are pitch counts for the last four days included? Why are ratings for "Holding Runners", "Sacrifice Bunt", and "Bunt for Hit" included FOR A PITCHER? There is no design coherence here. There is junk data littering the page.

For player evaluation, and for many of those use cases, injury history is essentially important. The designer has a category called "Injury History", but it is measuring the wrong things. What frequently happens in OOTP - and only an experienced player would even know this - is a player gets ONE crucial injury which cripples their ability and potential. How do you discover this? On the first level of tabs you need to find the SIXTH tab, called history, and pick thru many granular details of this person's history in the sport, going back essentially to little league. This data is among the most important from a player personnel perspective in the entire app. And it is buried to the point of not existing. The data decisions made in this game reflect a near-total lack of sophistication in solving information problems.

Of course, while we're focusing on the main profile screen - which is where the largest and primary benefit of good data is realized - the real heavy lifting happens on the supplementary screens. In design, it is the fit-and-finish that separates the best products from good products that are noticeably inferior. Think the difference between Apple and Dell computing devices. That is why supplementary screens are so important. When they are done well they close the loop of an exceptional design. When they are done poorly they subtly take away from what, if not for that, could be something completely delightful.

To implement this principle in practice, you need to document the key use cases and consider all of the data necessary for your game to be a complete experience. Then be sure to add data that, while not literally necessary, provides juicy goodness for the user. In a non-gaming context, think of the Twitter fail whale. They could have easily had an all-text 404 screen. Instead they thought about "how can we make this fun?" and created a sticky point of personality that became synonymous with their brand. Once you identify the data, figure out how to make it resonate with the user.

Information architecture is the sub-discipline of UI design where the planning and structure work for data in your app happens. For more information on that field visit the Information Architecture Institute (www.iainstitute.org).

Reality Bites
One of the first tools student designers learn is Lorem Ipsum. For those of you who didn't go to design school, or who have designed so little with text as to have not encountered it, Lorem Ipsum is placeholder text that reads as if it is real Latin. (It isn't; it is just structured gibberish). The idea is that you can quickly throw Lorem Ipsum into a UI to preclude the need to have someone write copy. The phrase is also used for just quickly coming up with "dummy data" for when statistics or other metrics are required. 

Lorem Ipsum

A favourite design tool, Lorem Ipsum  of any kind - text, stats, data, metrics - is anathema to great design. You can't make good design decisions without seeing real data in your interface. It is the same as the difference between wireframes and real design comps. Until the resolution is there, until the real object that needs to be evaluated is present, it is impossible to really understand what your user experience is going to look like.

Yes, it might take time to generate credible stats and data to achieve this. It might take writers on your team time to provide something that is reasonably correct story, dialog or other copy. That's fine; it's not like there aren't plenty more things for people to work on while that is happening. It is more than worth the effort. I've seen it time and time again, when rubbish data and clumsy Lorem Ipsum get everyone nodding their heads, only to find that the size and proportion of the real data that much later makes its way into the interface ends up breaking the entire solution.

Benefit from my grey hairs: ban Lorem Ipsum. Insist on real data as early as you can possibly get it in the design process. Your end product will be better, and you'll get there faster. I'm guessing that will make pretty much everyone happy.

Next time I will talk about axioms for the interaction aspect of UI design. Until then, here's to better data!