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

Finally, the fun of stamp collecting on your console!

What are collectables?

Collectables in modern games are usually items hidden throughout the game world, found when the player deviates slightly from the game’s intended course. They are often thematically linked to the main story of the game, and can unlock achievements, or in game rewards when collected.

In Alan Wake, the primary collectable are coffee flasks, 100 of which are spread across the game world. They give no tangible benefit to the player in game, however collecting them all unlocks an achievement.

These are however not the only collectables in the game. Throughout the game, there are also 50 or so Manuscript pages, each of which unlocks part of a written story linked to the game’s plot. Achievements are also rewarded for finding all of the TV programmes, radio broadcasts and in-game history text scattered throughout the game world.

Seems like a lot, doesn’t it? Let’s look at the reasons why so many collectables have been implemented.

Why are collectables used?

The key reason why the design decision is usually made to implement collectables is because they can directly extend the game’s life span, by slowing the player’s pace. By hiding items throughout every level, with no indication of where they are hidden, the player is required to travel slowly and explore fully to find the collectables.

It also opens up additional replay value in the game, as completists who miss the collectables on a first run through have the additional challenge of replaying the game while getting all the additional achievements.

In Bartle’s player types, collectables seem to appeal to ‘achievers’, who are interested in visible displays of skill (such as the achievement points unlocked for completing these challenges), and ‘explorers’, who like to investigate the game world, by incentivising them to fully explore their surroundings.

What is the problem with collectables?

In the case of Alan Wake, it seems that the developers hadn’t considered the extent of the effect on player behaviour that the implementation of collectables would have. Unlike Sandbox games, which have also embraced collectables, Alan Wake is a story-led ‘survival horror’ game, where the narrative is crucial to the experience.

By implementing collectables, this disrupts the flow and timing of the narrative experience, by forcing the player to explore each area before moving on. This is exacerbated because the player cannot return to an area once they have left, forcing the players to extensively scour each room before moving onto the next.

This has a huge effect on the pacing, and ensures that the ‘experience’ isn’t received as designed.

The 100 coffee flasks suffer from having no sign-posting as to their location, making it incredibly simple for the player to miss one, which is cause endless frustration if the player was attempting to collect one, due to the aforementioned issue of not being able to return to an area. Their entire ‘run through’ of the game would be wasted, and this oversight would only be discovered at the end of a run, which can take 15+ hours.

Finally, the atmosphere and ‘illusion’ of the game world suffers from the implementation of collectables. Alan Wake can only carry 30 revolver bullets – fair enough. However he also has space for 100 flasks of coffee? Strange priorities!

As has been noted in reviews of Arkham City, in story-driven games collectables can often make little sense, negatively altering the experience. Batman only has a few hours to save Gotham – should he really be spending his time searching for trophies?

Gotta Catch 'Em All!

How should collectables be implemented?

In Batman Arkham Asylum, the Riddler had hidden a number of collectable trophies around the game world. To prevent similar issues to those identified with Alan Wake from occurring, a number of steps were taken to mitigate the effect on player experience of these trophies. The player was given a number of clues as to their location, both through a riddle, and through an indication on the map of the general area in which the trophy was hidden.

For a story-driven game, this helps immensely. By indicating to the player when they should be looking for collectables, it reduces the frustration of the player potentially missing a trophy, and only finding out when they reached the end of the game with 99/100 collected. Perhaps more importantly, it ensured that the pacing of the game during story sections was maintained, since the player would only look for trophies when indicated, and could act naturally for the rest of the game. This is in contrast to Alan Wake, where the player is continually required to search every room, for fear of missing a trophy. It’s also worth noting that in Arkham Asylum the trophies were hidden in areas the player could return to at the end of the game.

Collectables work well in Sandbox games, as the player always has the option of returning to an area. In many other game types, this isn’t possible. Caution should therefore be used when implementing collectables in non-sandbox games, as the effect on player experience will be greatly increased, at the possible detriment to the overall gameplay experience.

Related posts:

1. Get Lost! – Improving player experience through signposting and map design in games.
2. Some great articles on games usability and player experience
3. Improving the Player Experience – How to make great loading screens

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

Agile is a software development philosophy which encompasses a number of ideals, most interestingly the idea of delivering working software over excessive documentation and planning. Distilled to it’s core essence, it divides project development into short (bi-weekly) ‘sprints’, where an agreed amount of prioritised software is constructed, tested and delivered.

Something like this...

Because of Agile’s emphasis on delivering working software as soon as possible, it gives plenty of opportunities to integrate user insight into the process, and user insight in turn gives a wide range of benefits to software development. In games, it can mean the difference between addictive game-play, or a dull experience.

So, how should user insight be integrated in order to create a successful game?

1. Gather user insight before you start.

Before the project begins, it is typical to have a ‘sprint zero’, to allow necessary preparation/evaluation of the problem to be performed. This is an ideal time to start on user research, since the cost of integrating any findings would be minimal

A variety of techniques could be used to understand users before production has begun.  Paper prototypes, or evaluating competitors products will give insight into what aspects of the game would be desirable, and which are unnecessary. Evaluating competitor’s games is practically free, and will prevent you from making the mistakes that they made!

2. Test at each sprint

Agile delivers working software at the end of each sprint. This gives an opportunity not possible in traditional (waterfall) software delivery – to test an element of your final product with real players. Ignoring the programmer-art graphics, or game-stopping bugs, the core game mechanics can be tested, and refined from a very early stage.

A technique often used to achieve this is ‘staggered sprints’.  This is the idea of running user testing in parallel with development, testing what was created in the last sprint, and feeding back refinements based on user testing during the next development sprint. This will give the team the ability to integrate the feedback from users consistently, and improve the next iteration. It will also settle arguments about features!

3. Release early and iterate

Starting with the proliferation of ‘patches’ for games, updating games is now easier than ever due to automated updating platforms such as the iOS App-store, or Xbox Live.  This means it is now possible to release a game at the earliest possible stage, and then iterate upon it to update it.

This technique has been used to enormous success with facebook games such as CityVille. By releasing a game early, either to beta testers, or the general public, and improving it based on player feedback, it allows you direct insight into what players want, what they don’t want, and prevents you wasting time on unpopular or unnecessary features.

Plus you start getting revenue from a very early stage – just look at Minecraft’s millions!

pictured: notch

4. Prioritise

A key aspect of Agile is the idea of prioritising the workload. Before each sprint, the most important features are decided upon, and only these are worked on. This means that each iteration will produce the ‘best’ version of the game possible at that stage, and any delays/cuts will only affect the least important aspects of the game.

The advantage of integrating user insight into the game development process, as outlined above, is that it can help inform this prioritisation, and ensure that the features being developed are the ones most critical to the players.

5. Evaluate

By far the most important aspect of developing games with agile is understanding what aspects are going well, and what needs revision. By working in short sprints with user insight as a ‘review process’, it is easy to judge what areas of the game are working, and which are not.

If this is contrasted to a closed development process, where the players do not see the game until it’s complete, it is often not possible to understand how features will be received, or whether the game is ‘fun’ until much too late! And if you do decide to make changes? It’ll be a lot more expensive at the end than if you’d caught it at the end of a two week sprint – this limits the rework you’d have to do.

In summary, developing games with an agile methodology produces better quality products, and at a faster pace. Integrating user insight into games development is not only possible with agile, but brings massive boosts to the quality of the final game.

Related posts:

1. UX needs an Agile environment
2. Why you should always video players when testing games
3. Understanding players through biometrics

I’m going to the “UX Writing Workshop” by Cennydd Bowles and Martin Belam in two weeks. The workshop promises to give tips on how to improve my blog writing skills. So, expect this blog to be much more compelling and readable from then on!

Also, when I manage to get the pre-loader working, I’ll be able to share the flash game I’ve been working on. Hopefully next week if I find the time!

Lastly, I’m excited to share that myself and Pejman Mirza-­Babaei will be presenting our paper “Playing to Win?” at the Multi.player conference. We’re on on the Friday, and will be covering the links between social interaction and biometric responses in co-located gaming (i.e. shouting at your friends during Mario Kart!). I’ll update with more information soon.

Heres a picture of a duck. Its nose is a dog:

Quack

Have a great week all!

Related posts:

1. “Playing to win?” @ multi.player conference
2. multi.player Conference Review – Social Interaction, Bartle and Orcs!
3. UXBrighton 2010 Conference Review

We Dare is a collection of mini-games. The game’s unique selling point is that these mini-games are meant to be risqué, and include activities such as stripping and spanking. This advert on youtube will give you a clear indication on the content in game.  Sexy right? Just like a trip to GAME.

Hot Stuff

In the studies I’ve been working on currently, we’ve tried to define the key behaviours noticed in social situations while playing games. These typically can be divided into categories such as “Sharing awareness”, where the players discuss game mechanics or what’s happening to their player, and “Trash Talk”, where players smack each other’s bitch up. These interactions can typically be found in most multiplayer games, from Mario Kart to Little Big Planet.

However We Dare seems to encourage a whole new group of interactions. Here are some of the potential behaviours you may see while playing:

Avert Eyes

• Can also be combined with “pretend to get a text” or “fake a coughing fit”
• Like that time when you were stuck in the pub with that newly-dating couple, it’s time to bust out this move when you really can’t stand to look at the horror-show in-front of you anymore. Hey, I’d never noticed how interesting the pattern is on the carpet before!

Ironic “I’m into it”

• “Sure I’m playing this game with my brother because I don’t know any girls, but isn’t it funny!”
• Careful about this one , it can be a worrying front – If the host is only playing it ironically, why did they buy the game in the first place?! (twist by M. Night Shyamalan)

Drink to forget

• More of a long term game-plan than a short term interaction, but the pure awkwardness of this ‘swinging-for-dummies’ title may make you want to forget about the entire experience.
• How about taking a shot each time in the evening you wish you’d stayed in school?

Make light conversation

• “Hey, how about that football thing last night, right? What a game. I liked the ….goals”
• Just like your grandma when a sex scene comes on TV, an easy way to deal with your host putting a Wii controller down your trousers is taking a sudden interest in the weather, or anything far far away from the here and now.

Leave

• The nuclear option, for when you can no longer deal with an overweight nerd removing his trousers to show you his Wiimote. Best deployed immediately after someone says “Hey, I’ve got a game we can play….”
• Protip: The only way to keep your dignity when playing We Dare.

Ultimately We Dare seems to have been designed to create a very very creepy experience, and a fascinating field to study! It’s just a shame the game itself is rubbish.

Related posts:

1. multi.player Conference Review – Social Interaction, Bartle and Orcs!
2. How to make an addictive social game
3. All Change – Apple’s new social gaming network

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