At the start of 2011, I made some predictions on what would be big in games user research over last year. 12 months on, I’d like to review these predictions, and review how games user research has changed.

Prediction 1: More user experience positions within games companies

“the demand for UX and Usability skills looks to be on the way up.”

2011 saw a large amount of jobs open up in the games user research sector. The jobs thread in the Games User Research Special Interest Group on Linkedin was busy throughout the year with many exciting opportunities across the globe.

The success and prominence of games user research has led to many studios looking to bring increased expertise in-house, which has the benefit of both reducing costs and retaining talent. I personally benefited from the increased interest in user research, starting a full time GUR position in 2011. This trend is not over, and it looks like there will be plenty of similar jobs opening up worldwide in 2012 – I’ll try and share some on twitter as I encounter them.

Prediction 2: End of eye tracking

“eye-tracking will move more into the position of one tool among many that can be used, but with caveats as to how you apply the findings”

I’ve heard of eye-tracking being used in game related usability studies over the last year, although this was in conjunction with other methods, rather than being the focus of the study. I still however have doubts over how useful this data can be. Although it can be interesting to see where people are looking, it seems to lack an applicable method of analyzing and reporting this data – unlike websites, games move around too much to draw consistent conclusions.

Instead, the use of eye tracking could be to placate viewers who are watching the sessions. It’s interesting to watch, and can help influence the client’s immediate conclusions – perhaps it’s much more useful to make user research look interesting, than to teach us results. And perhaps this means it has a future.

Prediction 3: The rise of biometrics

“the research into the wider biometrics field will really take off in 2011”

Vertical Slice have had some great successes with the application of biometrics over the last year, both for commercial application to games development, and with its popular application to finding the ‘scariest game’.

Pejman Mirza-Babaei has been working on the application of biometrics to pinpoint the exact moments in games where players react to in-game events, and then using alternate usability techniques to understand why these moments are important.

This idea has a huge amount of potential, and has been shared through Vertical Slice’s involvement in conferences during 2010 and 2011. It’ll be interesting to see how this work develops both academically and for commercial games development over 2012.

Prediction 4: Increased Organisation

“will become an increasingly organised community in 2011.”

The Games User Research group on LinkedIn has grown to over 350 members, and frequently has discussions on the hot topics in games research. In particular the group has been fantastic at sharing interesting articles and features on websites such as Gamasutra. Outside of the community, there’s been increased awareness of the field of user research, with GUR presentations (such as my one on Social Interaction) featuring in both social computing conferences (like Multi.Player) and Game-Dev conferences like Develop. This trend seems to be continuing into 2012, with games research workshops at high profile conferences like CHI and DIS.

Prediction 5: Understanding Social Interaction

“ I’ve been working heavily in the field of understanding group social interaction while playing games, and can see a lot of potential for this to evolve in 2011.”

Last of all, my personal project during the early half of 2011. I was involved in defining and measuring the forms of social interaction noted in cooperative and competitive play, and was happy with the progress of this, the work having featured at Develop, Multi.Player and in an upcoming Gamasutra article. Although I’m no longer working with Relentless, there is definitely potential for similar work to continue throughout 2012, especially with the new forms of interaction created by motion controls, or mobile gaming.

That’s it for 2011 – Whats next for 2012? Leave me a comment, or message me on twitter with your thoughts, and I’ll share them!

Related posts:

1. 5 predictions for Games UX in 2011
2. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
3. Evaluating User Experience in Games – Book Review

Following up from my recent review of the top positive user experience elements in Driver: San Francisco, this week I’ll be looking at the top 5 usability and user experience issues that cause a negative player experience.

For each issue, I’ll also discuss potential fixes that could be implemented in order to create a more positive game playing experience.

Image by wiiloveit (Flickr)

1.  Boost Implementation

Early in the game, the player is given the ability to ‘boost’, gaining a temporary speed advantage, by pushing the left analogue stick up. However, because this shares a control with steering, a number of usability issues occur.

I encountered a large degree of accidental activation, particularly in missions which required precision driving, since I was using the stick to steer also. This accidental activation caused the car to lurch forward, and made completion of the precision driving difficult.

Although it may be a design decision, I also encountered issues with steering while boosting – because the player is required to push the stick forwards, this reduces their ability to steer to the left or right to the same extent.

Instead, the boost control should be mapped to a specific button, which it doesn’t share with any other controls, and hence accidental activation would be minimised.

2. Unclear definition of Mission Goals

Throughout Driver: SF, I found that the game was good at telling the player what their goal was, but not the steps to achieve this. For example, a very early mission finds the player driving an ambulance, and tells the player to “keep the patient’s heart rate above 20”.  The phrasing of this objective implies that the player can take action to raise or sustain the heart rate, however no indication is given to the player towards the game mechanics that can achieve this.

I encountered a similar issue when first running from the cops. The game told me to ‘escape the cops’, yet gave no indication of the techniques or skills needed to achieve this. It was not until I failed the mission where the game explained that the player should “weave through traffic to escape the cops”.

Through improvement of the hint system (detailed further below), and increased communication to the player prior to mission start (for example, on the mission acceptance screen), there is the ability to communicate the techniques required, and guide the player to the successful completion of their mission goal.

3. Hints

In Driver: San Francisco, the player can press a button to see a hint related to their current mission at any time. However my experience of the hint system was that the hints were often unhelpful, and either repeated, or paraphrased the objective. For example, an early mission said “go to the garage”, and the hint was “drive into the garage”.

Objective...

...and its hint.

A player would only be pressing ‘hint’ when they were unsure of how to complete their current objective, and would therefore find no benefit in being told the objective again. Instead, through thorough user testing, and evaluation of the nature of the problems that user’s encounter, it would be possible to anticipate the real problems players have, and provide context relevant hints.

4. The MiniMap

The expanded mini-map

Driver SF’s MiniMap suffers from a few usability issues.  Primarily, even in the expanded view, there is no key to reference what the icons represent. In the screenshot above, it’s evident that there are different mission types (a flag, a star, a padlock, lightning?), however the player has no ability to discern what each of these icons refer to.

Secondly, no indication is given on this map view of the relative differences in distance between each mission. Should the player be using this screen to decide what mission to complete next, they are not given the full information required to make an informed judgement.  This could easily be resolved by using transparency to indicate each map item’s relative distance to the player.

Finally, one of the icons on the screen is a padlock. If the player travels to this area, they will find that they cannot do anything once they arrive there. The mission is locked. As the player cannot interact with this area, there is no reason to indicate it as a place of interest on the map, since this will only potentially cause the player to travel there unnecessarily.

5. Investigation Screen

The investigation screen

Finally, I was confused by the investigation screen. This page was accessible from the main menu, and (likely) intended to sum up the plot so far. Pictured above is the investigation screen after two hours of game play.

This screen offers no interactivity, and is exactly as pictured above. The pictures aren’t selectable, and there is no additional information. This page therefore fails to communicate the story, or serve as a reminder for what the player has learned so far. To improve it, each item should be selectable, and offer increased context on what each picture represents, based on what the player has learned through the game’s story so far.

Conclusion

I really enjoyed Driver: SF, however as noted above, it did have a number of usability and user experience issues, which can cause the player experience to suffer. Through increased use of user research to understand and anticipate potential issues, these issues could have been avoided. Jason Avent, formerly of Black Rock Studios has said that user research can add 10% to a metacritic score, which would have pushed Driver SF into the coveted ‘85%+’ bracket.

Related posts:

1. Driver: San Francisco Usability Review (Part 1)
2. This week’s gaming usability roundup – Portal 2, Deus Ex, Driver San Francisco.
3. 100 Rogues – Playability Heuristics Review

Today, I’d like to share some articles on usability and user experience in games that I’ve enjoyed recently, in case you missed them. I’d also be interested to hear recommendations of things I should be reading, feel free to leave a comment!

Personality And Play Styles: A Unified Model

@Pejman_MB  shared this one with me, a Gamasutra article summarising the different models out there for defining player motivation. This has been a pivotal aspect of the research I have been working on recently, and is a recommended read for anyone wanting to accurately target games to specific player types.  The article can be found here.

Why Are Tutorials Terrible?

Graham McAllister and Seb Long from Vertical Slice collaborated on an article last week, in Graham’s regular Edge column.  By looking at examples of good and bad tutorials, they help pinpoint what it is that successfully teaches players how to play your game. Read on here.

Some Hows And Whys Of Usability Testing

@EmeraldSong  gave a great introduction to usability testing in games, highlighting how it can be invaluable throughout the development process , can find issues missed in other forms of playtesting , and can be done on a budget. Gamasutra has more.

Resetting Accessibility in Games

Mike Ambinder from Valve software, who was featured in this blog last week, has been interviewed in more depth about Valve’s take on accessibility, as part of this article by Dennis Scimeca. Mike’s feedback is really insightful for how commercial development can balance the needs of disabled gamers, and can be found on page three of the article here.

Scary Game Findings: A Study Of Horror Games And Their Players

Finally, Gamasutra also featured an article on Vertical Slice’s novel application of biofeedback techniques to try and understand what makes a game scary. Originally appearing in Xbox magazine, this article features examples of five scary games, and works out what makes them tick! Read more on Gamasutra.

That’s all for this week!

Related posts:

1. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
2. Improving the Player Experience – How to make great loading screens
3. Get Lost! – Improving player experience through signposting and map design in games.

Remember to be polite....

***********************************************************

Hi Gabe

I write a blog about User Research in games, and know that play-testing, and incorporating player insight, is a huge deal at Valve.

I was wondering if you could give a couple of sentences on your own opinions as to why user research is an important part of the game development process, and how you do this at Valve.

While I’m making wishes, I’d also like a motorcycle, and a picture of you in a cowboy hat. If not, just the sentences will be great!

Thanks, and all the best

Steve Bromley

***********************************************************

And great news, I got a reply! Gabe forwarded my email to Mike Ambinder, an experimental psychologist at Valve. He described Valve’s philosophy around integrating user research in games as follows:

“At Valve, we see our game designs as hypotheses and our playtests as experiments to validate these hypotheses. In addition, we always want to iterate and improve on our work, and we are constantly seeking feedback – through playtests and other means – in order to do so. By making use of a wide array of user research techniques, we will make better decisions and as a consequence, better games.“

I followed up with Mike, to get a bit more information about the practical side of implementing user research and play-testing throughout the development process:

“We start playtesting as early as we can—as soon as we have something playable. We’ll start with internal folks and then bring in external folks soon after.

In terms of research techniques, we like to use the match the right methodology to the desired form of data. If surveys and interviews are most useful, we’ll do them. If it makes more sense to look at gameplay stats or physiological data, we’ll do them instead (or in addition).  Our most common form of playtesting is direct observation followed by a brief survey and then Q&As.  We don’t use biofeedback too much in our standard playtests, but we’re running a bunch of supplemental playtests on the side that concentrate on biofeedback data, and we hope to incorporate these methods into our practices going forward.“

Thanks Valve! Mike was able to give some really interesting direct insight into how they incorporate user testing into the development process. Still waiting for my cowboy hat pic though…

Related posts:

1. Games User Research Review of 2011
2. Some great articles on games usability and player experience
3. Ian Marsh, creator of Tiny Tower, on user research, play-testing and F2P

Blammo!

It’d be fair to say Prototype is an ‘average’ game, having received 78% on metacritic (it’s sad that this counts as average, but that’s inflated review scores for you!). It does some things fantastically, and obviously has sold well enough for a sequel to be in development. So, what impressed me?

The Best of Prototype

Relatively early on in the game, the player gets the ability to glide, with subsequent upgrades increasing their potential mobility while in the air. The glide ability is successful in both appearing in-context of a superhero game, and allowing the player to navigate the game world quickly and reach destinations in an appropriate time. By giving the player great freedom of mobility, this reduces the time between the player’s missions, prevents the game feeling ‘sluggish’ and avoids issues with difficult navigation that have been found in many open-world games.

As an anti-hero, the protagonist of Prototype, Jim SomeGuy, has a habit of eating people. The ability to gain health by eating NPCs works in the context of the game, and ensures that the player is never ‘stuck’ without the ability to gain sufficient health to complete their mission, due to the prevalence of both enemies and civilians. As a method of healing the player, it is less dependent on suspension of disbelief than a shower of health packs, and more unique than the health regeneration seen in many modern games. However eating an NPC requires the player to stand still, often making it impossible to heal while being ganked by enemies – I’d query this design decision, since it significally heightens the game’s difficulty.

The Worst of Prototype

You wouldn't like him when he's angry

 As in many games, progress in missions gives you money to upgrade your abilities. However when upgrading the player’s abilities through the in-game menus, the upgrade structure is unclear, both in its UI and its execution. When abilities (such as the ‘overdrive’ ability) are dependent on other skills to be useful (i.e. it must be partnered with specific other powers), this is not indicated and allows the player to buy a potentially useless ability. When purchased, the execution of new abilities is taught through a description of what buttons to press, lacking crucial information on timing and context of successful activation.

A minor annoyance is the range of UI issues in the menu presented on start-up. Prior to loading the main menu, the game requires the player to press to continue past a pop-up dialogue – a needless delay. The menu also highlights ‘New Game’s as the first option, despite the use-case for ‘Load Game’ being a lot more common. The game knows if you have a saved game, and could highlight the appropriate option automatically. Minor annoyances like this are an easy fix, and should have been picked up during development.

Conclusion

Prototype has a huge amount of potential, and is undoubtedly fun to play. Compared to other open-world games I’ve played, it seems to have extensive variety and some unique game mechanics, such as eating people to disguise as them, which help to keep it compelling . However, a number of small issues with the UI let it down, and detract from the player experience. More extensive user testing, throughout the development process, would pick up these ‘quick-wins’, and could knock the game’s metacritic score into the 80s or above!

Related posts:

1. Usability Thoughts – Mass Effect
2. The importance of usability in Mobile Geolocation games.
3. Driver: San Francisco Usability Review (Part 1)

I spoke to Ian Marsh, one half of Nimblebit, who have had numerous iPhone hits beyond their success with Tiny Tower, including Scoops, Pocket Frogs, Textropolis and more. Ian shared his insight into how understanding player behaviour affects the development of a popular iOS game, and the idiosyncracies of testing with free-to-play mechanics.

A small tower

- Have you been keeping track on people’s reactions to your game since release?

Certainly, we keep a close watch on people’s response to the game through monitoring twitter, app store reviews, various forums, and feedback sent directly to us.

- What’s your opinion of the comment’s you’ve been receiving since Tiny Tower’s launch? Have people ‘got’ it?

It has been a very warm reception. We’ve been pretty blown away by the number of people really embracing the game, and very surprised at how little negative feedback there has been.

- Did you let anyone play your game before release? Did their actions/feedback influence your design at all?

We ran a very transformative private beta involving around 30 people. We learned a lot and made a lot of changes to refine the experience. There will always be aspects of a game that the developers are blind to for one reason or another so getting other people involved during development is essential. (NB: Ian asked players for qualitative based feedback, shared through a forum thread)

- Did you take any conscious steps to test the F2P elements with players?

An enjoyable free experience is the most important thing to us so we usually beta test the game without IAP functionality. This lets us balance the game for free players first, then layer on the IAP in a way that is entirely optional for the player.

some minature shops

- When you update the game, is it based on feedback you’ve received?

We certainly take all feedback to heart and it sometimes leads to new features, but we’re usually working on or have already considered most features that people suggest.

- How far do you think the game was (and is) lead by your own initial inspiration, and how much has been subject to changes based on player reactions to initial builds?

The game changed quite a bit during the beta period. The main goals and idea of the game remained the same but we were able to change certain systems and tweak progression to keep people more engaged, maximize the fun parts, and minimize the boring bits.

- Looking into the indie/mobile games industry as a whole how do you feel the idea of user-inspired development is being received? Is it still the culture of ‘design is law’ and superstar developers such as John Romero.

I think developers should always listen to criticism and feedback for their games but a good developer has a clear vision of what their game should be and knows whether it would actually improve the game or not. There is always the chance that someone will come up with a good idea that simply never crossed your mind.

Ian’s given some really interesting insights into the current debate over player-led vs designer-led game design, and how free-to-play mechanics should come second to a positive user experience. Their obvious success in this area implies they are on the right track, and we’re all looking forward to seeing what they come out with next!

Tiny Tower is available from the iOS App Store

Related posts:

1. Valve’s philosophy with User Research in Games (Gabe Newell & Mike Ambinder)
2. Games User Research Review of 2011
3. Erik Rothoff Andersson (Kick Ass) on testing with users & why you shouldn’t listen to what users say!

Classic Worms

However the iOS port has made a huge usability sin with its misuse of icons. Today I’ll look at what the problem is, and how it could be resolved.

Icons

Icons are visual pictures that act as a navigation or access point to software features. They are typically small pictures that represent an intuitive representation of the feature that they represent, for example a picture of a printer for the print function.

A good icon will be visually distinct and recognisable, yet have a close match to the function being represented.  It will also be uncluttered and make its function explicit.

(Interestingly, floppy disks are still used as the icon for saving, despite the fact that many computer users now will no longer be familiar with the original thing! As such, the icon no longer matches the function, and has become an abstract icon)

So, what’s wrong in Worms?

Icons are used in Worms when creating the map for multiplayer games. Here are the icons that are presented to the player upon starting a new game:

Worms Icons...

Let’s address each of these in turn.

Flying Saucer Thing – This controls the level’s theme, and matches what is displayed currently. However clicking it will take the level to the next theme (i.e. not the one pictured in the icon), which is counter-intuitive. This icon therefore doesn’t clearly indicate what it does without having to test it, which forces the player through some very slow loading times!

Question Mark – This changes the landmass, and is currently displaying as ‘random’. This is only obvious after clicking on it a few times however, each click signifying a different state of the landmass. Again, this leads to large loading times.

Arrows – This ‘refreshes’ the map, and gives a new random layout. This icon follows the standard for refresh, which is good, however makes no attempt to explain this functionality.

Mine – This controls the number of mines that are placed on the screen, and cycles between showing 0-3 mines. Like many of the other buttons, although the icon clearly refers to mines, it misleads the player by showing the current status, rather than what will happen when the button is clicked.

Coffee Cup – No idea what this does. If you click it, it cycles through showing 0-3 coffee cups, but I’m none the wiser what this refers too.

How can this be fixed?

It’s obvious in most of these cases that the icons are also functioning as status indications for the current map, which serves to confuse what the functionality behind clicking the button is!

As featured on UX Myths, Michael Zuschlag says that “icons contrary to intuition, do not necessarily help the user find a menu item better than a text label alone.  It’s not worth it.”

With these items in Worms, he’s definitely right. If these icons were replaced with text to indicate their function (such as ‘change theme’, ‘randomise level’), this would lessen the confusion caused by them functioning as status indicators otherwise.

I’d even suggest, if space wasn’t available for both, to just pick text – it’s less ambiguous, and can give a much more direct understanding of the functionality. Besides, a lot of the things being indicated in the icons (such as the level theme) is clearly visible in the level itself!

Related posts:

1. Usability Fail – Monkey Island 2
2. Usability Fail – Twitter on iPhone
3. Usability Fail – Lotus Notes

Today I’ll look at the major usability problem in this game, and how it would be fixed if Perfect Dark was made today!

When playing Perfect Dark, the immediate difference I noted to current-gen games was how long I spent lost, with little idea of where I should be heading, and with a severe risk of failing or missing objectives without any prior-knowledge.

Level Design - Then and Now

As is obvious in the picture above, level design has changed. In the nineties it was common to make the player trek endlessly through corridors, searching out key codes or objectives to extend the playing time of the game.

Throughout the game, Perfect Dark is guilty of this, leaving the player to wander endlessly through corridors with an ill-defined objective, only randomly stumbling upon the item they need to proceed. This is particularly evident in the plane crash level, where the player is left in an arctic tundra to search for a “medical scanner” (without mention that it looks like a suitcase), with no direction as to where this can be found across the miles of map, and no ‘signposting’ to indicate when the player is close.

Later on, the player is exploring a boat and has to trawl up and down endless staircases and corridors. Without visible landmarks, the player quickly becomes disorientated, and can only tell if they’ve walked through an area before by the bullet holes in the wall…

How would Perfect Dark be different today?

Games today are a lot better at guiding the player, since the player’s experience while enjoying the game has become more important than the game’s longevity.  How to do this correctly is the sort of thing usability can solve.

Perfect Dark's secret shout out to Usability Testing

Focusing on the player experience has lead to the creation of a ‘toolkit’ for games that can be used to direct player attention to specific items, a few of which I’ve listed here:

• Audio cues
  • Either a narrative voiceover or having key in-game objects make distinct noises can help guide the player
  • Best used in combination with other cues, since players often play without sound on, and for accessibility reasons!
• Visual cues
• Literal, or metaphorical signposts can indicate which way a player should be heading.
• Landmarks, and visually distinct areas, help players to orientate themselves.
• Moving objects, and unexpected events can direct player attention to a specific object in the immediate area.
• Maps
• Allowing the player to access a map, and place waypoints, can help them to navigate large areas without getting lost.
• It’s also useful to highlight unexplored areas, to give the player an indication of where they are yet to explore
• Mark key objectives on the map
• Checkpoints
• Checkpoints can give the player an indication that the path they are taking is correct, and reassure them that they are making progress.
• It can also allow them to go back and retry if they do feel like they are in an unrecoverable situation.
• Barriers
• If the player will not need to backtrack to a specific section, and has completed the objectives for that area, prevent them from going back
• This limits the playing field to only the relevant areas, and constrains how lost a player can get!
• Works best if the barrier is presented using in-game devices (no invisible walls!)

Any, or all of these in combination, can lead to a better player experience and overcome major usability issues around player attention and goal definition.

Related posts:

1. The thirty minute facebook game usability test
2. Usability Thoughts – Mass Effect
3. Game Usability: Advancing the Player Experience Book Review

Today I’ll be looking at the first 5 minutes of a successful social game, and highlighting which elements have made this game successful. In the future we’ll look at some games which have missed the point, and hence lost a large proportion of their customer base. From this, we can learn how to make an addictive social game.

The Game

The game we were originally going to study was intended to be Farmville, since Farmville is famously the ‘poster-child’ of social gaming success. However it wanted me to connect with my facebook account, and wouldn’t let me play without doing so. Game over!  (Presumably this is just an annoyance to me however, and hasn’t stopped the game’s success)

Instead, I looked at the ‘Top Grossing’ iPhone apps, and found ‘Smurf’s Village’. Like farmville, it’s a landforming game, where the player has to create a new village for the Smurfs, and look after their crops. Most importantly, it’s free, yet still a top-grossing app – clearly a sign of it’s continued success. (or was it all the work of this kid charging $1400 to their parents credit card) So, what happens in the first 5 minutes of Smurf’s Village?

The Experience

The first thing that happens when running the game is that it asks if I want to hook it up to facebook. This is a key business goal for the app developer, since it increases awareness of the game and is a key element to how social games work. Importantly for the user experience however, it is optional (unlike Farmville). I declined at this time:

Linking with facebook

After a very short introductory story, explaining why the Smurfs are moving, the game drops you straight into making a new village. With clear directions, the game tells me to click on the sign and lay a plot of land:

Planting a field

And with that, I get an immediate positive reaction “Quest complete”, and reinforcement of the lesson I just learnt:

Quest Complete

Now the same happens again with ‘growing blueberrys’, where an arrow clearly indicates what I need to do, and I’m given positive reinforcement having completed this task:

Planting berries...

And with that, a level up is gained:

Level up!

The game goes on, with the next level teaching you how to build a house, and crucially linking speeded up progress with using smurfberrys. Since smurfberries are the games in-app-purchase, and hence the primary method the developer makes money, this is an important link to make early on:

In app purchases

This earns me another level up. The game then goes on to repeat this to teach me how to build grass, before letting me play a mini-game to break up the monotony. If I were to continue playing beyond the first few minutes, the game would go on to ‘set me free’ and let me use the lesson’s I’ve learnt to continue to build the village unguided.

The Rules

So, what magic rules did we find that led to a successful first 5 minutes with this game?

1. Explain actions one at a time, let the player do them

• The game takes care to only show the player one action at a time, and first describes the task, before guiding them through performing the task themselves, to ensure that players know how to do it. The game then confirms the correct action has taken place after it has been completed, and tells the player what they did.
• By repeating the action numerous times, the game hence reinforces to the player how the action is achieved.

2. Reward the player for performing an action correctly

• When an action has been performed, there are multiple layers of success shown. Not only are there visible indications that the task has taken place, and the player is rewarded with both experience points and a ‘quest complete’ dialog, but the game also levels up the player’s village.
• Hence there is positive reinforcement that the correct action has taken place, causing the player to want to perform it again, much like Peggle’s Ode to Joy

3. Show the player the potential of what they can achieve

• By setting the game after the destruction of the original village, and allowing them to build a new one from the ground-up, this game highlights what can be done by the player if they were to continue playing.
• This message would potentially be reinforced by introducing the social element of the game, for it will be possible to see other player’s complete villages.

4. Let them take control

• After the tutorial period (admittedly longer than the 5 minutes I played for today), the game will hand over the reins to the player, having shown them what’s possible, and give the ability to create solutions in a manner of their own choosing.
• Although there will be continued goals to achieve, the method to achieve these goals becomes more free-form after the tutorial allowing the player to introduce creativity into their gameplay.

All these factors have been an important part of the continued success of this social game. Soon I will look at an alternative, unsuccessful, social game, and note what factors lead to its failure.

Related posts:

1. How to make an addictive strategy game
2. All Change – Apple’s new social gaming network
3. The usability of iPhone’s Game Center

As promoters of user insight in design, it’s therefore unfortunate that recording people secretly is unworkable in most real world situations. Much more importantly, as an aspect of scientific research, recording people in this manner is unethical. Today I’ll be considering why this is so, and look at how to do ethics correctly.

Ethics is an important element of user research, because scientific research without restraint can, and has, harmed people. Consider the experimentation that Dr Mengele performed on humans in concentration camps – his position was that it was serious work and furthering our knowledge scientific and biological knowledge for the benefit of humanity. So does the scientific merit justify these experiments? Consider also the research into Shock Therapy, as documented by Naomi  Klein – where subjects were subjected to seizure-inducing electric shocks, in order to ‘cure’ conditions such as bipolar disorder or catatonia. Subjects were often not in a position to give informed consent, which is an aspect of ethics we’ll be looking at.

It’s highly unlikely our research into user-insight will touch these morally-dubious boundaries, yet scientific research has since formalised many rules in order to prevent research becoming ethically wrong. Hence it’s important, when working directly with users, to be aware of ethical considerations.

So what ethical considerations do we need to follow when working with users?

Primarily there is the issue of informed consent. Consent is the idea of giving permission for research to take place, and the results be presented in a manner defined in the agreement. For consent to be informed, the participant has to have a clear understanding of the facts, implications and consequences of the research. Hence, we can see in the electroshock example given above that subjects, often in catatonic states, were unable to give their informed consent for being participants in research. As researchers, informed consent often has to be given before the research/observation begins, and again after to ensure that the participant is fully aware of what they are agreeing to.

We can see that informed consent becomes difficult to apply when working with special groups, such as children or people with certain disabilities. However it is these cases where the correct application of consent is particularly important, due to the vulnerability of the groups!

A second aspect of correct ethical procedure is allowing users to change their mind and leave during a study, without necessarily giving a reason. Although this has the potential to introduce a bias into the results (since your user group will be restricted to only willing participants), this has benefits in the validity of the data received – an unwilling and unhappy participant may intentionally disrupt an experiment.

Changing your mind...

As a part of this, the participant also has to have free choice over being involved in the experiment – it’s important to consider factors such as social pressure when understanding whether a user is truly free to participate.

Last of all, a guideline when working with real people is ‘Don’t be evil’. Google’s motto, though not always met by their actions, should be a guiding principle in all endeavours – the people you are working with are real people, and their wellbeing is morally more important than your research. Hence we can understand why the Stanford Prison Experiment, which looked into the psychological effects of becoming a prisoner or a guard yet descended into abuse, was prematurely stopped.  Research should be terminated

Yes, even you Doctor Badman

This issue becomes less clear-cut in certain cases. What if your research would harm the participants, but make life better for millions of others? Do the needs of the many outweigh the needs of the few? Spock thought so. However, for usability experts, a good rule of thumb is to consider the experiment from the participant’s viewpoint, and only involve participants in ways you yourself would be happy to perform.

Related posts:

1. How presentation affects perception when working with users
2. Test with real users – not your team
3. Watching ‘average users’: Word