How game designers can help application developers : Part 1

I'm a gamer. Our house has an Xbox 360, PS3 (the new slim variety) a Wii, an old xbox, an old ps2, a Gamecube, 2 Nintendo DSs and even a Gameboy Micro, plus the PC and a pair of iPhone 3GSs. Most of these get a fairly regular workout, except for perhaps the Micro and the Gamecube. Suffice to say, we're a gaming house. My wife is a Nintendo nut, and I'm more into PC and Xbox gaming. The PS3 is a blu-ray player.... What's this got to do with application design? More than you'd think! Usability, in application design, is often an afterthought. Not only in terms of interface design, but in terms of the user experience or user journey. This is mostly true for developer driven application design. The sort of design that evolves at the hands of a developer only to be "spruced up" by a designer later (if we're lucky). We consider how things work, but not really how they will be experienced. You can spot these apps a mile away. I know, because I've built plenty of them in my time. You don't realise how bad they are until you see someone trying to actually use your application in a real world environment, something many developers never ever witness and as a result never learn. Some typical examples, if I may:
  • Features that were clearly important at the start of development, remain visually prominent well after the feature has been demoted in importance or the focus of the application has changed.
  • Repetitive tasks use interfaces which are too cumbersome and time consuming to work, often as a result of a developer building an interface in isolation rather than as part of a work-flow.
  • Building a data interface which requires pre-existing data but with no way to add it, requiring the user to leave their current process to add the prerequisite data somewhere else.
  • Interface elements which are either non-obvious in their function or "tricky" to use for the inexperienced.
  • The worst offender, inconsistent design and implementation. When a developer is left to their own devices, they will often come  up with different solutions to the same problem. There is nothing worse than using an application which implements the same process two different ways in two different areas!
I'll be honest, you'll see a few of these issues in our own But we're working on addressing these... I promise! Whilst most of these issues could be easily addressed by a better pre-build process or even just some rudimentary user testing, this is often something that is out of the hands of the developer. Often in a small team, these tasks fall into the hands of the dev, something which, let's face it, we're all ill equipped to deal with. Not only that, but often the entire build process is focused on getting the job done quickly, rather than having a good product at the end. So, back to the games.... Imagine you're playing an RTS like Command and Conquer, Age of Empires or Starcraft. The enemy is approaching and you're in dire trouble. You need to build a wall, some defence towers and at least 20 units to fend off the attack. If all that isn't enough, you have only about 5 minutes in which to do it. The pressure is on! If the game is well designed, you will have enough time to fend off the horde. If the game is well designed, you will be able to achieve it all with a minimal amount of effort (time pressure aside!). Finally, if the game is well designed, there will be minimal interference from unrelated factors whilst you attempt to achieve your goals. Let's think about that more for a moment. If it takes too long for us to complete our task, we will be overrun by the Zerg Swarm and lose the game. If it is too difficult to complete the task, we will most likely give up and go play something else. If the game interrupts us constantly by notifying us that our citizens are unhappy, that another player wants to trade with us and that we should consider building more farms, we will get annoyed at the game and blame it for making us lose. Game developers spend crazy amounts of time considering these issues to ensure their game is fun to play, and yet in reality the same issues face us as application developers. We may not expect our users to have fun, but we still want them to be able to achieve their goals, and hopefully enjoying it enough to come back again next time! Come back next week for Part 2 of, "How game designers can help application developers"