Imagine you are standing at an intersection of a dusty road in the middle of nowhere.  You have to make a choice regarding which direction to go.  Do you flip a coin?  Follow an instinct?  Check for footprints from earlier travelers?  Stand in one place until someone else comes by to provide insight?

You are faced with decisions every day – this may be as simple as choosing the correct freeway exit, or deciding between health insurance policies. You might even be choosing between software development companies. Each time you are faced with a decision, you most likely take one of two approaches: Methodical or Instinctual. They both work just fine, but more than likely, one works better for you.

Design engineers are unique because they are faced with decisions regarding someone else’s needs and goals, rather than their own.  The methodologies most often deployed by User Experience Designers are User Centered Design (UCD) and The Genius Method (aka Rapid Expert Design).   While it may seem counter intuitive, our UX team actually needs to understand how our clients make decisions first, and deploy the appropriate methodology for them (rather than require our clients to adapt to our preferences.)  Luckily our team has been around the block a time or two (or three) so we can easily work with either approach.

It is critical to understand the distinctions between the Genius Method and User Centered Design, as each approach can benefit and facilitate the design process differently.  In addition to client comfort zones, we also have to consider time/budgetary constraints, and team dynamic.

User Centered Design

User Centered Design involves a methodical approach, including hypothesize, test, analyze, adjust, test, analyze, adjust, and so on until certainties are in place and the project can launch. A project taking a UCD approach most likely includes extensive wireframes, user research (including user testing, and focus groups), A/B testing, beta launches, etc.  User-Centered Design  processes are well-known, stable, and can guide teams when creat­ing software applications. UCD moves slower, but with greater certainty. UCD, combined with our project management discipline and advanced development teams, ensures that your users get the most predictable outcome possible with your software development project. Although UCD is one of the most common practiced design methodologies, it has a few drawbacks: focus groups may not be representative of the actual user base; and it can be a longer process, which often costs more money. Nonetheless, UCD is still a very effective approach to concepting and designing software applications with measurable benefits to the end users.

Here’s an example a project IdentityMine created using the UCD approach.

IdentityMine worked with Graphic.ly, a startup focused on comic books and the ecosystem built around them. The challenge was to translate their passion for comics and their leadership in the space to a mobile application for the pre-released Windows Phone 7 platform. We focused on a selection of user scenarios that highlighted what was to come in the final shipping build. The resulting application is a culmination of all of the feedback we received from both users and Graphic.ly personnel as we developed the entire experience using Silverlight from login to purchasing and reading comics.

The Genius Method

The Genius Method is inspiration-based – it relies on the visual design and user experience  teams to make decisions based on their intuition, experience and expertise without significant external input. The Genius Method is certainly the more romantic of the two – it implies that creative geniuses are at play inventing delightful experiences that surpass convention. If you are fond of certainty, this may seem like a barbaric approach – but when it comes to creating a product, you may benefit from the unconstrained approach.  Since the Genius Method relies heavily on inspiration, it is best suited for designers with many years of experience. This approach is generally  faster than UCD, with sizeable cost benefits because it relies on the intuition of the design team, rather than using a controlled data set and user research. You will come to conclusions faster and with less systematic documentation, and there is less risk that a brilliant concept will be dismantled by research participants  that don’t actually know what they want in the context of your concept, and team meetings.  It is the individual nuances of the Genius Method that makes it such an effective and innovative design methodology.

Here’s an example of a project IdentityMine created using the Genius Method

Intergraph is a leading global provider of engineering and geospatial software. We were asked to revamp their Security, Government, and Infrastructure division. Using the Genius Method, key improvements were made across Intergraph’s application suite to standardize UI, improve screen layouts, and streamline user workflows. We successfully completed this by employing our expert UX design gurus to brainstorm, envision, and then architect the overhaul of the application suite.

So how do you decide which way to go?  Is User Centered Design right for you and your project, or are you more suited to the Genius Method?

Go with UCD if:

• You like predictable, measurable results
• User testing is a significant source of decision-making confidence for you and your team
• You are risk averse
• You  have the time and budget to devote to repeated testing and validation

Go with the Genius Method if:

• You are working with a highly experienced team (like ours!)
• You trust your colleague’s intuition
• You trust your own intuition
• You have a deep understanding of your end users’ ultimate goals

How do we do it?

IdentityMine is significantly proficient at both the Genius Method and UCD – our team of experts has the essential background and knowledge to make educated design decisions – resulting in a rich user interface that complements the end-user experiences.  We’ve also navigated the complex waters of User research, and UX design.  Hopefully this information will help you as you launch your next project (or take your next road trip).

Related posts:

1. The Reflective Practitioner in User Centred Design
2. Understanding Cognition, User Experience Winners & Losers, and a Design Failure.
3. The right environment for user testing

For those of you who are interested in game usability, and yet inexplicably are unaware of Pong, it’s the classic (stolen) 1970’s table tennis simulator. It makes a sound like ‘plink’, and looks like this:

but... more interactive

And on with the show.

Game Play

Due to the lack of anti-aliasing technology, Pong had to stand on its game-play alone. However, as we’ll see, there is only mixed success in this area.

Successes

Provide clear goals, present overriding goal early as well as short-term goals throughout play.

Get the ball past the other player. Ten times. That’s a pretty clear goal (although it loses points for not actually explaining this goal in game – I have to assume it was written on the cabinet).

The first player action is painfully obvious and should result in immediate positive feedback.

My first action was to miss the ball. The digit on the other side of the screen went up. I assume that’s bad. My second action was to return the ball. The digit didn’t increment. Better…

Pace the game to apply pressure but not frustrate the player. Vary the difficulty level so that the player has greater challenge as they develop mastery. Easy to learn, hard to master.

So the ball gets faster when I successfully return it. I suppose that is ‘incremental difficulty’. Wouldn’t really say “hard to master though”

Game play should be balanced with multiple ways to win.

Knock the ball up above the other bat. Knock the ball down below the other bat. The Konami code. Ok, so there’s not that many way’s to win.

Failures

Player’s fatigue is minimized by varying activities and pacing during game play.

Return the ball. Return the ball. Return the ball. Miss the ball. Return the ball. Return the ball. Return the ball. Return the ball. Return th……

Provide consistency between the game elements and the overarching setting and story to suspend disbelief.

The ball is square. The bats are disembodied. The ball doesn’t bounce. No-one makes me play in shorts (doesn’t stop me). It’s not really like table tennis is it.

There is an interesting and absorbing tutorial that mimics game play.

There is only a tutorial in the sense that ‘a computer defeats you at virtual table tennis’ teaches you that you’ve achieved nothing.

Player is taught skills early that you expect the players to use later, or right before the new skill is needed.

10. Return the ball

20. Go to 10.

Players discover the story as part of game play.

I wasn’t even aware there was a story, until I purchased Pong: The Novel (sold separately)

Player should not experience being penalized repetitively for the same failure.

The game only has one type of failure – missing the ball. It’s hard not to be repetitive.

Player’s should perceive a sense of control and impact onto the game world. The game world reacts to the player and remembers their passage through it. Changes the player makes in the game world are persistent and noticeable if they back-track to where they’ve been before.

Player 1 had trained for this moment. His sensei had honed his reactions until they had become automatic, felt in his heart instead of his hand. His tutor had gone through the maths behind each shot again and again, until Player 1 no-longer saw a ball, he saw a formula. His parents had bound his body throughout childhood, distorting his body into an unrecognisable mass, yet formed perfectly for table tennis.

And it had all been for this.

The game had been hard so far. His opponent, the notorious ‘CPU’, was his equal in every way – not only matching him in skills, but, due to a freak accident of nature, being his exact double in looks. His opponent’s cool demeanour betrayed no hint of the rivalry between the two of them. Ever since that day back in playschool, with the shark and the peanut butter.

But it was no time for reminiscing. Player 1 had strived too long and come too far to lose now. And with the seconds ticking by, and their volley reaching lightning speeds, now was the time to strike.

It wasn’t conscious. It barely even registered to Player 1 that a mistake had been made, but when CPU passed the ball back dead straight, instinct took over. He moved very slightly upward, bringing his lower half in line with the square ball. This was it. Inching ever so slightly upwards, until just a sliver remaining in the firing line. Then… bang! Contact! The ball had grazed his side, and was on its way back, spiralling off to the top of the screen. His opponent scrambled to get in line. The ball drew ever closer, crossing the dotted centre line. It was out of Player 1’s hands – only the gods could intervene now. But no deity was watching, or if they were, they were smiling on Player A.

The square ball squeezed effortlessly passed CPU. That was it! It was a goal! Player 1’s ghostly white face gave no hint of the jubilant celebration going on inside.

Hanging silently above the field, it’s radiant light illuminating the entire stage, the score digit increased by one.

Player 1 had made his mark.

The game should give rewards that immerse the player more deeply in the game by increasing their capabilities (power-up), and expanding their ability to customize.

No blue shell, no cardboard box, and no Odd-job. No customisation.

I like big bats, and I cannot lie

Game Story

So, the game play wasn’t fantastic. What about the story though?

Successes

The Player has a sense of control over their character and is able to use tactics and strategies.

To be fair, there is just as much strategy as in the game of table tennis. ‘trick’ the computer player, by knocking the ball at extreme angles. And you definitely control the character. A success!

Player experiences fairness of outcomes.

It’s a battle of skill, with the computer constrained to the same rules as you. It’s definitely fair.

Player understands the story line as a single consistent vision.

It’s a game of table tennis. It’s never golf, and hence provides a consistent vision.

Failures

Player is interested in the story line. The story experience relates to their real life and grabs their interest.

Bored of this now. Nope.

The Player spends time thinking about possible story outcomes.

Nope.

The Player feels as though the world is going on whether their character is there or not.

Nope.

The game transports the player into a level of personal involvement emotionally (e.g., scare, threat, thrill, reward, punishment) and viscerally (e.g., sounds of environment).

Yes! I mean… nope.

Conclusion:

Terrible game, will never catch on.

Despite this, if you want to try it yourself the closest recreation of classic pong I could find is here

Related posts:

1. 100 Rogues – Playability Heuristics Review
2. Playability Review – 56 Sage Street
3. Driver: San Francisco Usability Review (Part 2)

Early chapters in the book try to define what the field of user experience is, and what it means in relation to games. There is a degree of confliction here, with each chapter giving a slightly different interpretation, but they often settle on themes such as immersion, fun, presence, involvement, engagement, flow and playability.

Also wind, fire and heart!

The book gets more exciting when it presents a range of methods for evaluating user experience in games, with a variety of models appropriate for various stages of game development, from prototyping to post-production. This encompasses many custom models for different situations, such as a model for inexperienced gamers, or one for fitness games.  The book also presents studies of the usability of game controllers, and the development of heuristics, which is particularly interesting in the last chapter which aims to collate and amalgamate previously created gaming heuristic.

All this content is interesting; however, a liberal spreading of maths means it often comes across as extremely academic (particularly in comparison to Isbister’s book). This can largely be accounted to the background of the various authors, largely coming from academic institutions, compared to the real world perspective of Game Usability.

Where the book excels is the divergence from this academic interpretation, notably in the papers by Vertical Slice and Emily Brown. Vertical Slice cover the current state of user experience evaluation across three Brighton game companies, and give an insight into the methods used through case studies, from the expert evaluation found in the earliest stages of production, through to the user testing close to the end of a project.

Brown gives a comprehensive overview of the range of tools currently in use, and shows optimism for the future, since she recognises only a “lack of knowledge” as a hindrance to the extension of user testing into gaming, rather than opposition to the methods. This conclusion is reinforced by the case studies by McCallister and White, who show game developers are looking to extend their application of user experience testing in the future.

Which will be the same as today, but with more robots

Unlike Remote Research or Game Usability, this book is not a practical how-to guide. Instead it presents the state of user experience in games, and where the cutting edge of research is. Personally I have found it very useful for developing my own research.  However the book would be unlikely to be a ‘one stop shop’ for a developer looking to start user experience research at their company.

It will be useful to see how the wide range of interesting ideas found within this book can be integrated into practical solutions for companies to use when producing games. This move from the theoretical to the practical will greatly assist the field of user experience in games, and will truly see the ‘coming of age’ of video game usability.

Related posts:

1. Game Usability: Advancing the Player Experience Book Review
2. Remote Research – Book Review
3. Games User Research Review of 2011

Just under 16 years ago Microsoft attempted to reinvent the desktop metaphor, and bring it up to date. The product, Microsoft Bob, aimed to shift computing from an office metaphor to a home metaphor. And it was a massive failure. My first home computer came with Bob installed, and so today I’ll be looking at why it failed, and what we can learn from this failure.

Usability advantages of the desktop metaphor.

So why has the desktop metaphor proved to be a lasting success? Introduced at a time when graphical methods of interacting with a computer were new, it had several key characteristics that led to its success.

...such as fun games

First of all, the desktop was familiar. Rather than having to learn context specific methods of interacting with a computer, it built upon the user’s pre-existing knowledge. For example, when deleting a file, a user could use their existing understanding of a trash can, and drag the file into it (rather than running a deltree command, which doesn’t map with any real-world knowledge). Therefore the desktop metaphor was easy to figure out, and consistent with real life experience, reducing the learning curve upon adoption. This meets Nielsen’s heuristic on a ‘match between the system and the real world’.

Building upon this familiarity was the appropriateness of the desktop metaphor for the tasks at hand. Before home computing, the workplace was the most likely place for users to use a computer, and the computer would be performing office-based tasks, such as word processing or calculating. Hence the adoption of a workplace metaphor seemed appropriate for developing a graphical user interface, as it registered with the target market. This meets Nielsen’s heuristic on ‘recognition rather than recall’.

Furthermore, the desktop metaphor was wide enough to expand to meet the growing roles that computers played. By extending the workplace metaphor through terms such as ‘cut’ and ‘paste’, and the development of graphical tools emulating image manipulation tasks, the desktop metaphor proved that it wasn’t static, and could extend to reach an ever growing range of requirements.

The desktop metaphor also met the heuristic requirement, of having a wide degree of flexibility, by allowing ‘experienced’ users to automate or speed up tasks, such as by selecting groups of objects, or utilizing keyboard shortcuts.

What did Bob try to do?

In the mid 90’s, Microsoft Bob was devised as the successor to the desktop metaphor. Recognising a growth in home computing, Microsoft aimed to shift the graphical interface model for computing from a business/creative focus, to the ‘home’. It was thought that this would open the computing world to a whole range of ‘novice’ users, who would have found the desktop metaphor inaccessible.

Bob presented the user with ‘their room’, covered with clickable objects, such as bookcases, clocks and a notepad. Clicking these things will launch the relevant program (or help you locate files), and you can add your own programs to the shelves. It’s just like your home! (assuming your home is littered with boxes that say ‘Internet Explorer’ and ‘Corel Draw’).

Bob in action

Why did Bob fail?

Microsoft Bob offered an alternative to using the desktop metaphor, aimed at novice users, but its primary failure was that it didn’t offer any significant advantages. For a product that came over twenty years after the ethos of its competitor, this wasn’t a good sign…

Despite being based on the home, Bob still had a learning curve, and so missed it’s key objective of being intuitive. Clicking on a clock to open a calendar, or a pen and paper, still required just as much learning as a calendar or notepad icon in a traditional desktop environment. More complex tasks than just opening programs still require further learning. Also, the enforced ‘home’ layout is just plain inefficient – rifling through a cabinet to find a file offers no advantage to browsing a list of files in a folder.

By attempting to change the way people interacted with computers, Bob alienated itself from existing computer users, and prevented new users from being able to ask for help from power-users. By offering only ‘simple’ ways of interacting with computers, the user was unable to allow users to grow, and learn superior (and more efficient) ways of performing tasks.

It’s also apparent that the ‘cuteness’ of Bob didn’t sit well with users. The two elements of this operating system which outlived the OS itself are among the most hated villains of computing – Virtual assistants like Clippy, and the Comic Sans font. Obviously Microsoft failed to understand the needs of their target market.

The final nail in Bob’s coffin came within a year of its release. Microsoft released Windows 95. It sold… quite well, and offered a fully-powered alternative to Bob based on the traditional desktop metaphor. Bill Gates punished those responsible for the mess that was Bob. He married lead project manager Melinda French. Burn.

What will replace the desktop?

It’s obvious through Bob’s failure that the Desktop cannot be beaten by a simple re-skin or appropriation of another metaphor without offering significant advantages.

As I wrote about in my review of The Humane Interface, Raskin proposes a ‘Zoomworld’ which offers a non-windows environment with no gaps between the operating system and the files. However development by Archy has stalled and they seem to have fallen off the internet…

Or maybe the future will be more like Google, and involve typing queries or commands into a prompt to find answers and perform tasks? Although this does seem like a regression, and breaks several key usability best practises.

So what other systems are out there that offer a viable alternative? Or will it be desktops forever? As ever, I’d be interested in hearing your thoughts in the comments below!

Related posts:

1. Evaluating existing technologies, paper prototypes in action, Windows 7 and the disappointing user experience of my DVD player!

This review aims to evaluate the playability of the game, including pertinent usability issues, and the effect this has on player experience. This is especially important, given 100 Rogues’ mission of making a difficult genre accessible. I’ve based the review on the heuristic points identified by Heather Desurvire’s paper ‘Using Heuristics to evaluate the playability of games’

What this review doesn’t cover is non-usability or player experience issues. Hence, it’s not a review of the game itself (which I gather is a pretty standard Rogue-like). It’s also not QA, and so doesn’t cover bugs in the game. This is especially important as 100 Rogues has infamously been plagued with a number of bugs since its release last week. The first version would crash if the player equipped a shield. The fix for this introduced several new bugs. And I still haven’t been able to get defeat the first boss without the game killing my player after I’ve defeated the boss. I gather the developers are working on this though.

100 Rogues

Game Play

Game play covers the game’s goals, and player’s involvement in achieving these.  100 Rogues succeeds in many areas here. Crucially, it guides the player through their first steps, and introduces them to the range of actions available to them, by immediately giving them the ability to level up their player, which is reinforced by the low cap for the second level up, allowing the player to practise this mechanic twice within the first 2 minutes of the game.

More complex actions are also introduced to the player, through the game’s challenge mode – a series of short scenarios where only the use of an advanced technique (such as ‘tele-stabbing’) will succeed. These introduce the player to some of the more complex moves available to them, in an intuitive way (rather than just… telling them)

The game handles the inevitable death of your character well, also. As mentioned previously, when playing a Rogue-like, you only have one life, no reprieves, and you will die. They explain this by likening the game to Tetris – the goal with your one life is to see how far you can get, not to reach the ‘end’. However death in any specific situation is never inevitable and the game always seems fair. This isn’t Mario Kart, where the CPU will always cheat at the last moment. Instead, after every death you’ll always believe that you could have done something differently and survived, and hence the game encourages a ‘one more go’ attitude to playing, and challenge comes off as a positive experience.

The only game play element which seems poorly balanced, and takes some of the control away from the player, is the ‘food’ mechanic. If you don’t eat food, your character dies. Makes sense. And sometimes you cannot find anything but rotten food, which will fill you up, but reduce your maximum HP. That’s fine too, if it’s a choice between being weakened, and death.  But sometimes the game will spawn no food at all. And then you’re stuck, and nothing you can do will save your character from death. This looks like it needs to be balanced in future games, so the game at least spawns some food (rotten or not) when the player is critically hungry. As it stands, the player doesn’t feel in control of their destiny, and has no ability to prevent their character from dying.

Pictured: 100 Rouges

Story

Story defines how your characters’ actions fit into the world you are presented with and the feeling that the game-space exists as a real world, which you can affect, but which exists without you.

The story in 100 Rogues is simple. Satan is at the bottom of the dungeons, and you must kill him. Why? Because he’s Satan.

This story is introduced by a cut scene at the start of the game, and loading text gives character-related background, however this is where the player’s involvement in the story ends. The in game content, and enemies don’t reflect this final goal (aside from the end boss), and the character development isn’t plot related.  Occasional infighting among the enemies gives the potential for further depth within the story, however this is not explored further. Ultimately, like Tetris, the story of ‘why’ you are doing this is not a focal point of the game.

Mechanics

Mechanics covers consistency in how the game reacts, how the AI acts, and how the player controls their character. The AI in the game is a success, with the NPC’s acting consistently, and yet occasionally surprising the player – such as when an archer’s miss-fired arrow will hit another enemy, and they will start battling it out.  Hence the game balances allowing the player to understand how NPC’s react, without making them entirely predictable.

The game allows the player to track their own progress, through in game score/stats, and a global high-score table. Although implementation of this isn’t perfect, as I’m not convinced scores are being posted to the internet, the bug has been noted and is being ‘worked on’.

An area where the mechanics of 100 Rogues fails is with its controls. The character is controlled by touching the screen – touch the screen at the top to make the player go up, or touch an enemy to attack them. However, with no confirmation before an action is taken, and no indication of the active areas for each target, I found myself ‘miss-clicking’ numerous times, with often deadly consequences. Hence, when trying to click on an enemy for a ranged attack, I’d instead walk towards them, putting my character in danger.  Restricting the range of actions available on a single click, or making ‘attack’ a double click, may help alleviate some of these issues.

Must be my sausage fingers...

Usability

Usability concerns how the game gives feedback for inputting actions, and whether they can achieve their goals. A success for 100 Rogues is how it saves the game state on quit, allowing the game to continue from the last point, as I’ve discussed before

As I discussed above, the game also gives direction to a first time player, by giving them an introduction to levelling up on game start. However, it hinders play the second time you start by… giving the same introduction. Since the game demands multiple play-throughs, I feel that I have grasped this mechanic the 20^th time it has been introduced to me.

Conclusion

As has been made clear by a heuristic evaluation of 100 Rogues, the game has a high degree of playability, and provides an accessible entry point to a traditionally difficult genre. As noted, there is room for improvement, yet the game offers significant advances on other games in this genre.

However, I’d be hesitant to recommend the game, as it stands, as a positive player experience. Although, playability shouldn’t include bugs, bugs will undoubtedly have an effect on player experience. Hence, as the game stands, the unexpected crashes and deaths will detract from player’s opinions of the game. What incentive do players have to give the time and effort of playing, when their character could be taken away from them through no fault of their own?

That said, the development team have been dedicated to fixing bugs – having released two patches in the week after the game was released, and are promising up to two-three times more content released periodically, which is an advantage of the iPhone as a platform. Within a few more iterations, I can see this game being the definitive introduction to the Rogue-like genre.

Related posts:

1. Pong – Playability Heuristics Review
2. Playability Review – 56 Sage Street
3. Driver: San Francisco Usability Review (Part 2)

The topics are widely spread, and try to cover every aspect of usability and UX within computer games, including an introduction to heuristics, how to perform an expert evaluation, and guides to many of the processes of user experience testing. Since the topic is relatively new, there is a wide range of material than can be drawn upon – maybe this book wouldn’t be so useful in ten years time, after a greater degree of precision is applied to each area of usability testing.

Where this book excels is when it covers the actual ‘how to’ of usability processes. If the reader had never performed an expert evaluation before, this book would give them a great introduction and allow them to get started. Similarly for running user tests, articles in the book tell you what to do (and what not to do), common problems encountered, and what results you should be looking for. This is supplemented well by concrete examples, such as Microsoft telling us how they use heat mapping to work out which areas of Halo are causing problems, and what actions they took to fix it.

now try to capture the flag

It also covers the difference between ‘casual’ and ‘power’ gamers, and how games should adapt to the shift towards casual games that can be seen through the success of the Wii. Unlike Alan Cooper (whose book Inmates says that the divide between casual and power users should not exist), this book recognises that ‘power-gamers’ have grown up developing a different skill set to casual gamers, and are more prepared to put up with issues like dying repeatedly, and a higher degree of challenge. By addressing the differences between gamers, and what their expectations are, this book would be a useful aid in the design of personae, and at targeting your game to an intended audience.

 Some aspects of the books seemed a tad odd however: An interview with Georgios Yannakakis of Copenhagen University asks only three (very brief) questions (maybe Georgios wasn’t aware it was an interview). Another interview is with someone who shares Schaffer’s last name, and looks to be the author’s dad. Schaffer’s dad has been established in the field of usability, but has little to add with regards to games.

Perhaps the main issue not covered by the book is that all the contributors to the game are established in companies that accept the value of their work. The book briefly covers some counter arguments to common complaints about performing user testing (“It’s too expensive = It’s cheaper than shipping a rubbish product”, or “It takes too long = It’s integrated with the design process so doesn’t take much longer”). However it’s getting into a position where UX is a consideration at all within a company that will be a consideration for many (and is the subject of John Rhodes’ book Selling Usability ). Maybe future revisions of this book will include techniques for making usability a priority within your company.   

The focus of the book is maybe sometimes too wide, and only lightly touches each subject before moving on. If you were already familiar with the topics covered in this book, there will be nothing new for you here.

These oversights are only minor though, compared to the large amount of ground the book covers as an introduction to usability. It offers more in terms of practical “how-to” guides than Alan Cooper’s Inmates, and its focus on Games means it can offer fairly comprehensive coverage of the main topics of the field. If you are new to the subject, or a non-usability specialist looking to understand the subject, or can only afford one book, Game Usability would be a great introduction to the theory and practice.

Also, to finish, my quick Usability fail discovery, from Sussex University.

Instead of letting the user break it, how about… not offering the ability to make mistakes (See: Macs)

Related posts:

1. A Theory of Fun for Game Design by Ralph Koster – Book Review
2. Evaluating User Experience in Games – Book Review
3. Rocket Surgery Made Easy by Steve Krug – Book Review

To get the best results possible, and be as helpful as possible to the client, we had to choose our methodology carefully. In this blog post, I’ll discuss how we chose to approach this task, why we chose these methods, and what the alternatives are.

The first rule placed on us is that we are to work in groups of 3. As described in an article by Laitinen on performing expert evaluations, the evaluation reaches its optimal group size between 3 and 4. Less experts than this may miss things. More experts than this fail to find a significantly larger number of faults.

plus too many cooks spoil the broth

The other restraint placed upon us is that we would only have a short amount of time with the game. We decided to use this time to play and evaluate the games separately, and then come together to discuss our findings. The alternatives to this would have been having one person play, and the other two take notes, or to have each person play for a bit (as we did), but the experts not playing would take notes then. All of these sessions would involve filming the game screen, and the participant.

Two experts watching one player

Advantages:

• One longer complete play through, so can see player development
• Experts can ask the player questions during their play session

Disadvantages:

• Only one play through, so difficult to see if issues are common or just for this user
• Questions asked during play through may distract/alter playing experience

Three experts playing together, in turns

Advantages:

• Three sessions played through, so can see reoccurring issues
• Experts can get a greater understanding of the game mechanics through playing it

Disadvantages:

• Players wouldn’t get as far as they would with a long session from one player
• Second and third experts play experience will be biased from the experience of the first

Three experts playing separately

Advantages:

• Each player gets an authentic ‘new player’ experience
• Comparing after can show what issues naturally arose for all

Disadvantages:

• Players wouldn’t get as far as in one long play through
• Have to perform expert evaluation after the game play, rather than during.

Since the sessions were all being recorded, we opted to do the last one, and hence have the ‘purest’ play experience recorded for each.  There is, of course, no right answer – many other groups chose different approaches, and I’m sure they found equally valid issues. I’d welcome comments below if anyone has reasons for a preference with how to perform an expert evaluation.

Now having a video of a play test, we are individually analyzing them. I’m approaching it using heuristics, such as those made by Nielsen, Nokia, and the work of Federoff as a guide. Having identified the issues, I will then attempt to rate them by severity – the extent to which they will hinder the user’s enjoyment of the game. Then, in a group session with my team members, we will evaluate which issues we all agreed where particularly prominent and severe, and amalgamate our results, ending up with a list of issues with the game.

We will then have to present our data to the client. I posted before about writing a UX report, but the circumstances for this report will differ – Geographical location, and time constraints mean that this report will be an in-person presentation, with some take-aways. I will blog about these soon….!

Related posts:

1. Quantifying the unquantifiable – Expert Evaluations
2. 100 Rogues – Playability Heuristics Review
3. How to present a UX Report

Oh no – its playing the Marble Zone theme at full volume! We’ve been foiled, and you’ll never get the sandwiches now!

So what went wrong? Despite having the phone set to silent, the game still had sound. Depending on how diligent the coders were, this has been an issue with the iPhone for a while, as the iPhone won’t automatically silence apps when set to silent – this has to be manually coded. Quick ports or just forgetful coders (usually working in small teams) can miss this.

This becomes an issue because of user expectations – they’d expect the silent switch to work globally, and will be surprised and frustrated when this isn’t the case. As seen in the scenario above, it can lead to the user being embarrassed and worse of all (according to Alan Cooper) feeling stupid!

It’s not simply a ‘design choice’, as a logical look at the situation will tell us. Not only would manually setting the desired volume settings inside an application duplicate functionality that is already implemented in a much more functional manner on the device itself, but I can also think of no scenario where a user would want their phone on silent, but their game to make sounds. It’s just poor design.

So in summary… just don’t do it app designers!

(Also while you’re at it, let me listen to my own music in game!)

Who does this well?

 A lot of games to be honest, as its not really a ‘do well’ thing, rather its just done or not done. So lets talk about Doom Classic, as it does do this. John Carmack’s finally (6 months after it was “almost ready”) released his port of the original Doom for the iPhone. Control issues aside, it’s a faithful port, and includes WiFi multiplayer. Its Doom, so you know what you’re getting, and its just as fun as it was 15 years ago. More relevant, it does respect the silent switch on your iPhone, so I’m justified in talking about it here! We’re all looking forward to when Carmack starts on his port of Quake.

Who does this badly?

Hook Champ, from Rocket Cat Games, is a fun platformer where the only means of getting anywhere fast involves swinging from the ceiling, over lava, through brick walls and away from the scary cursed..fish thing. Its fun, recreating the opening scene from Raiders of the Lost Ark. It’s just a pity that the game ignores your silent switch, and so plays at full volume regardless of your iPhone’s settings. You can set the volume in game. But you shouldn’t have too. A disappointing oversight!

Another offender is Sonic 1, but I didn’t feature that as I’ve already talked about it in a previous post (link to previous post). Oh dear!

Also, just quickly, thanks to Brian Franklin from WebHostingSearch for featuring this blog in their ’20 Great UX blogs’. Rather unexpected, but thanks!

Related posts:

1. Controls should be appropriate to the iPhone’s input methods (shake now!)
2. iPhone games should not be interrupted by calls.
3. iPhone Game Design Heuristics

PopCap, they of Peggle and Plants Vs Zombies, commissioned a survey on where most people play mobile games. Results showed that men play more at work (28%) than women (17%). They were also asked when do they play these games. “while waiting for an appointment” came first for both genders, although I imagine this is because “on the toilet” wasn’t an option in the survey (I’m not judging… just saying!). 

waiting for an appointment

What these results show is that people want mobile games to be ‘pick up and play’, and use them to fill time, as opposed to committing a large amount of time to playing them. It is therefore important that game designers facilitate this method of game playing, and make it easy to pick up and play games. The main elements of this are:

• fast start up time (from app load to actually playing)
• low number of extraneous menus to navigate before playing 
• app resumes from where it left off 
• app shuts down quickly, but doesn’t lose progress 

A previous blog post touched on the issue of apps resuming your progress after an exit, and so this topic will focus on the user experience starting (or resuming) a game.

The player, when they start the game, wants to play as soon as possible. Initially they have to sit through a load screen, which beyond the abilities to reduce this by programming optimization is a necessary evil. However, as developers interested in ux, steps should be taken to reduce the number of steps a user has to go through after this to reach the game.

There is a trade off that has to be made here, based on our assumptions of what the user wants to do.  With many types of games we can assume that the user will already be on their right profile, will want to resume a current game, or start a new game. More complex games may have a wider degree of options that they need to present the user (particularly on a first boot). So how do we decide what options the majority of users will require? More effective than experts’ ‘educated guesses’ would be qualitative testing – either through a limited release prior to the app store (I believe apple allows you to distribute your app to 100 people, enough for a good sample group), or through ‘hooks’ in the code of early releases, which will log, and send back, details on user activity. If you then found that 87% of users, on loading a game, went straight to ‘resume game’, you could make the game do this automatically, and reduce their wait.

The design of an effective ‘entry method’ into the game is incredibly well suited to large user tests, based on qualitative tests of user behaviour, and can have an enormous effect on a player’s good will and ‘feeling’ about a game. Put simply, if player’s know that they can load your game quickly, compared to one with a 30 second wait, and 5 menu screens to navigate, they are more likely to pick your game when waiting in a queue or for a meeting.

"anyone for peggle?"

 Who does it well?

Textropolis

Textropolis, the word guessing game by Ian Marsh. Click on the app, and after a short load screen you’re playing the game – no menu options (obviously you can get back to the menu, but the game assumes, correctly, that most players will not need this). The nature of the game (no time crucial element), lend the game to a quick start, so this is also a fine example of a game design being suited to its platform. The game isn’t lacking in features too – the ability to sign in as separate user profiles exists, the game assumes that you will be less likely to want to do this than just play. Textropolis’ quick start up time would make this game a suitable choice for the sort of quick gaming that Popcap’s user survey says mobile gamers are into.

NB: I was going to feature Geared, the puzzle game by Bryan Mitchell here, as it loads quickly, and I cant remember having seen the title screen (it throws you straight into the game). However when writing this, I realised it doesn’t save your progress on a puzzle when you exit/re-enter, and hence it loses user experience points!

 
Who does it badly?

hero of sparta

Hero of Sparta, the (rather epic) hack and slash game by Gameloft (Think those PS2 Star Wars/LOTR games).

So, we’ve got five minutes before the meeting starts, lets play. App started. A load screen, then a one minute cut scene, ok, I’ve seen it before, so I’ll skip this. Another load screen. A title screen. Touch the screen to continue, ok, I’ll do this.  New game, or Continue. Obviously I want continue, so I select this. Select a chapter. Well, I’ll select the one I’ve been playing on. Great. Another load screen. And I’m in.

That’s a lot of stuff to get through between deciding I want to play, and actually getting to play. Probably one of the reasons why I haven’t devoted much time to playing this game.

How could it be improved?

After the first load, I’ll be unlikely to want to watch the opening cutscene again (despite the flashy graphics). The title screen adds needless clicking to my experience. Although I haven’t verified this with testing, I believe the player is likely to select ‘continue’ rather than ‘new game’ after they’ve started playing. And th

Related posts:

1. The importance of usability in Mobile Geolocation games.
2. iPhone games should not be interrupted by calls.
3. 100 Rogues – Playability Heuristics Review

Looking at an iPhone, the immediate thing that strikes most users – compared to other mobile devices – is the lack of buttons. There are 4 in total, and all have very set roles – the power button, the silent switch, the volume control, and the ‘home button’. The home button is the most prominent of these, and sits on the front of the device, below the screen.

All of these buttons are useless for gaming – three have very specific roles, and the home button is exclusively used in the iPhone OS to exit programs and return the user to their ‘home screen’. What this means for gaming is that the device is lacking a critical element that users of consoles have come to rely on – tactile feedback when pressing a button.

Buttons on controllers are important for many reasons.

An Ergonomic Masterpiece

The physical shape and size of buttons are ideally ergonomically placed to make the controller comfortable, and prevent gaming being a painful experience. They should also be placed in places that become intuitive to the user – gamers, like touch typers, should be able to forget about the controller’s physical presence between them and the game, and react naturally to events on the screen without having to think about how to translate their actions through a control pad.

And then theres the iPhone. Game developers aren’t allowed access to any physical buttons for players of their game. They have to innovate (uh-oh!).  Or not.  Some developers, whether its due to the style of game they are trying to present, or just laziness, have just plastered on a ‘on screen joypad’ ontop of their game, with virtual buttons. See, for example, the iPhone port of Duke Nukem 3D.

Lots of buttons!

So that’s 5 virtual buttons, and 4 virtual… test tubes?.. acting as directional controls (two for movement direction, and two for aiming). Obviously the medium of the game (a First Person Shooter), does need a large degree of complex manoeuvres to be performed, but it seems both lazy and ineffective to have these as virtual buttons. Not only does it take up a very large proportion of the small screen’s real estate, but without the physical presence of the buttons, it seems very likely that the wrong buttons will be pressed constantly. This causes the constant need for the player to think about the controls, and will prevent playing from ever becoming truly intuitive. The iPhone does contain tilt sensors, as used in other games as the primary control method, and this could well have been incorporated into the aiming or walking mechanics (although not if you don’t want to draw stares on the bus).

Instead of lazily placing endless virtual directional pads and buttons, developers should be taking the medium into consideration when implementing controls. The iPhone has capability for tilt sensor input, and multi touch (so multiple elements can be selected at once). This has been used successfully to produce games of most formats – in particular Rolando, a tilt platformer, and Doom Resurrection, a tilt FPS being examples of successful implementation of formats traditionally considered to rely on control pads. Moving from a control pad to the iPhone requires novelty and implementing new methods of controlling the games, rather than a simple port. Buttons just don’t work as well without tactile feedback, and totally disregard the other control methods the iPhone allows. As before, I’ll end with an in focus look at two games available on the iPhone, both platformers, one of which successfully implements a suitable control method, one of which fails.

Who does it right?

Rolando, by Handcircus, has been described as the ‘Mario of the iPhone’ (by someone). At heart it’s a traditional platformer, with goals such as getting to the end of the level while overcoming traps, obstacles and enemies. All standard stuff for the genre. However what it does correct is the implementation of this, taking into consideration that it is on the iPhone. To move left or right, the phone is tilted, removing the need for directional controls. A swipe on the screen will cause your character to jump – again no button here. Elements on the screen, such as the lift in the picture, can be manipulated with your finger, which of course your hand is free to do, as you are not restricted by using them to move. So, with Rolando, moving is intuitive, jumping can be done anywhere on the screen, and there is no need for virtual buttons and the problems we’ve identified surrounding them.  

Rolando!

 
Who does it wrong?

Sorry, but its Sonic. Obviously it’s a classic platformer, and an exact port of the version on the master system (so no spin dash!). However the port itself seems lazy – controls being implemented by simply placing a virtual d-pad and jump button on the screen. For a game that involves precision jumping, such as Sonic, this is a huge mistake. Lacking tactile feedback on which direction you are pressing, or whether you have your finger above the jump button, can (and often does) lead to missing jumps, and frustrating deaths. And, with no level-select, three deaths will mean starting the game from the beginning. Ultimately it makes the gaming experience frustrating and removes a lot of the fun that the sonic series used to be about! A design failure.

Sonic for iPhone

I think app store reviewer Mr Intesity puts it best:
 

Score: 2/5

Subject: I am cooking chicken and rice

Review: It’s alright. Its Sonic as you would expect but with dodgy controls. I’ve played it twice, too fiddly to sit and enjoy I found.

Related posts:

1. Shh! iPhone gaming should respect your sound settings
2. iPhone games should not be interrupted by calls.
3. Usability Fail – Worms (and Worms 2)