UI/UX Case Study: The Evernote Sharing User Experience.

During a typical day of working on Monday Night Combat, I’ll have brief but frequent periods of time where, in order to test a change to the UI I’ve just made, I’m waiting for the game to be built and pushed — or “cooked” — to my Xbox, and since I can’t actually make any changes during this time it leaves me with about two minutes of time where I’ll fire up a web browser, check email, or otherwise twiddle my thumbs. It can be pretty distracting to keep moving from random web articles back to the game, so I thought it would help my focus if I tried to at least productively read things that have to do with UI, keeping my attention at least mostly related to the task at hand.

So during those moments for the past few weeks I’ve been collecting articles about user experience design and user interface design and storing them in a notebook in my very favorite app of all time, Evernote. By tagging them in their own notebook I’m slowly accumulating an indexed encyclopedia of UX and UI design knowledge that I can use for my own reference, edification, and skill growth. I also post these articles to Twitter and Facebook as I find them (I’m trying to consciously add value to my social networking these days rather than just posting about what I had for lunch — it was a pulled-pork sandwich, though, if you must know), and after a couple of people told me they’ve really been digging these articles, I decided I should share my Evernote notebook publicly for the benefit of other people who might like to see this information collected.

Read the rest of this entry »

My User Experience: Blackberry.

I upgraded my phone several months ago and since I’m on Verizon I don’t get my first choice in phones, which would be the iPhone. Since I didn’t really like the Droid when I used it in the store I went with the Blackberry Curve.

For the most part the phone has been easy enough to use — “easy enough” meaning that the UI had issues, and it may take a mistake or two to get a setting right but eventually I figured it out. While looking for answers to questions I had online I saw more than one post that mentioned that Blackberries are well known for their steep learning curve but that the reward for having surmounted it was mastery of a lot of advanced options and a highly configurable device.

Well, that learning curve really decided to come back and bite me the other day: I had what was possible the worst user experience with a device I’ve ever had. I’ll tell you the story, and then I’ll tell you what questions it raised in my mind about the psychology of user interfaces and experiences.

Read the rest of this entry »

Good UI Principles: PC to Console, Console to PC

The days of the PC-only game developer are about as alive as the days of the dinosaurs — if you’re a PC-only game developer these days, the chances are good that you’re making casual games, not full-on triple-A shooter or RPG titles. Even RTS games, the genre with devotees that cling doggedly to the “PC is the only viable platform for RTS!” mantra, have transformed with the recent release of Halo Wars by Ensemble.
And that brings us to today’s Good UI Principle:

Principle 1: It is far easier and cheaper to develop a multi-platform UI for the console version first and use it as the basis for the PC version than it is to develop the UI for the PC version and back-develop it for the console version.
Principle 2: In the era of multi-platform (and thus multi-input-device) games, UI coding language and algorithms need to be changed from language that uses words like “mouseover” and “rollouts” to “on-actions”, “on-exits”, and “on-selects.”

Read the rest of this entry »

Good UI Principles 2b: More Info Is Not Good Info

Okay, I admit that I’ve only just started these essays and I’ve already blatantly lied to you. Not only did I not post my first one over the weekend like I promised, I’m also doing a bait and switch on the topic. Instead of talking about the development path between console and PC UI first, there’s something that came up in conversation today that I’d rather devote the first entry to, and its position on my list is 2b (because it kind of dovetails into a couple of other points I had made earlier on my list). Here’s the tenet:

Giving the player all information at all times is not only not advantageous, but actively damaging to the game experience.

It’s a subpoint on my list because it dovetails into a larger point, which is that a UI’s job is to present only the information you need when you actually need it, and that information shouldn’t crowd your screen at any other time.

Read the rest of this entry »

Good UI Principles: The Intro

I’ve spent the last five years of my game industry career making user interfaces for games of many types — PC games, console games, games that ship on PC and multiple console platforms, first-person shooters, third-person action games, and strategy action games. And I spent the five years prior to that working in areas of game development that touched heavily on the user interface experience — web design for some of the largest game web sites on the net, marketing materials for games, and more.
I’ve learned a lot over those many years, and about a year ago I decided it would be kind of cool to keep track of the things I’ve learned about UI design and the user experience in games in some kind of list. The list has since grown to include about twenty items so far and as long as I work in UI I can only assume that the list will continue to grow. I’ve taken to calling the list “Good UI Principles” and I’ve decided it would be a great idea to start expanding on each one of the items in my list in a collection of blog essays because discussion about good UI design is surprisingly hard to find. As to whether or not I’ll actually contribute anything to a discussion about good UI design remains to be seen, but hey, what’s the harm in trying?

Read the rest of this entry »

UI, Entropy, and the Tipping Point

I’ve been designing user interfaces for games for about five years now, and one of the things I decided to do about a year ago was to keep a list of “good UI principles,” those things that people in other positions in the game industry often don’t understand or realize about game UI development. This week I discovered one, what felt like a very important and revelatory one, and realized that it deserved more than just a two-line blurb in my text document.
For the past few months I’ve been working on the UI for Demigod (and by the way, we released the first official trailer today) and we reached a point a couple of weeks ago in which the UI needed a complete overhaul. The other leads on the project were worried about how I’d take this because they knew they were essentially telling me, “we’re sorry, but you have to completely redo this, it doesn’t fit with the game now.” After discussing what changes we wanted to make one of the leads asked me worriedly, “are you okay with this? I mean, we’re basically redoing everything.” And when I said yes, explaining that this always happens in UI because there’s a point you reach at which it just sort of…well, happens, he said, “it does? So what are we doing wrong, then?” Speaking in the broad, industry-wide sense of the word we.

Read the rest of this entry »