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

attendance was looking good

The day was bookended by presentations from Eric Reiss, and Rory Sutherland. Both speakers were charismatic and good choices as the key speakers of the day. Reiss’s talk, on ‘Web Dogma’, introduced a high level overview to some of the key concepts of the day – advocating the idea of ‘user driven design’ at every stage of a project, and introducing his list of 10 basic rules for web communication. These rules aim to separate best practices from technology and fashion, and hence avoid the fate of the Dogme95 movement which inspired their creation. Although possibly too ‘high-level’ for a UX specific conference, Eric Reiss’s presentation was fun, full of character, and engaging, since he treated his presentation as an independent being imbued with a personality of it’s own (more on this later!). Eric Reiss’s full list of rules for web design have been widely adopted across the net, and can be seen here: Web Dogma.

Rory Sutherland’s talk ‘Of Clouds and Clocks’ was a fun ending to the day, and expanded the day’s discussions beyond the realm of just user experience. Sutherland based his talk around Karl Popper’s idea that most things are either clocks, and hence act predictably and mechanically, or clouds, which are much more complex systems and hence less easy to adjust. Popper said that the worst mistakes are made by people treating clouds like clocks (such as terrorists attempting to fix society with a bomb), and Sutherland points out that this applies to traditional interpretations of business. Instead of focusing on grand actions to change business, it is instead the accumulation of small actions, and an oblique approach to fixing a problem, that often proves successful. Sutherland’s infectious humour and personality shone through his presentation, and he provided an inspiring ‘wake up’ rally at the end of a long day! Rory Sutherland’s TED talk can be seen here

Other highlights of the day included Harry Brignull’s talk on the evil tricks designers use to control of your actions. Brignull has started to document these on his very interesting darkpatterns.org website, and used his talk to propose a code of ethics to help combat these tricks.

Graham McAllister presented some of Vertical Slice’s methods of biometrics research within games, which I’ve written about before. His talk seemed well received by the crowd, and gave an interesting example of the application of UX principles outside of websites.

Jeroen Van Goel, of Johnny Holland Magazine gave a fun presentation of the personality inherent in products, such as his washing machine, and how we as UX designers need to consider the personality of websites as we make them. By learning from the established field of branding, we can overcome the constraints set by design patterns and simple usability testing, to create ‘likeable’ products.

My own washing machine has seen unimaginable horrors...

Bunnyfoot’s Jon Dodd showed us how the teachings of advertising guru David Ogilvy still apply in the 21st century. His insights, revolutionary in the world of advertising, including using metrics, a/b testing, and talking to customers, and are all key aspects of creating successful user experiences. Dodd’s talk has inspired me to re-read Ogilvy’s classic “On Advertising”. Dodd also recommended Ogilvy’s ,“Theory and Practise of selling the Aga Cooker”.

Further talks, from James Page, Sabrina Mach, Claire Rowland and Julian Hirst, covered a diverse range of topics, from the nature of creativity, to the introduction of UCD into the methodology’s used in large businesses, to the advantages of remote user testing.

UX Brighton proved that the Brighton UX community can fill a conference venue, and put on a day of interesting and relevant talks. It was especially interesting playing ‘spot the twitterer’, as I spotted many people I’ve been twitter stalking for the first time. I’m sure after the success of 2010, the organisers will be looking to put on a UXBrighton 2011, and I’m already looking forward to the discussion of next year’s hot topics!

Related posts:

1. multi.player Conference Review – Social Interaction, Bartle and Orcs!
2. “Playing to win?” @ multi.player conference
3. UX Updates: What’s going on (Writing Workshop, Flash Games and a Conference!)

Traditional Software Development

In the olden days, and today in large unwieldy companies unsuitable for adaption, software was produced using a waterfall methodology. The waterfall methodology involves splitting the design process into distinct stages, and completing each stage before moving onto the next. Exactly unlike a waterfall. Some standard stages are

• requirements gathering
• design
• coding
• testing
• deployment

Each of these stages would be completed, documented and signed off when completed. Effectively this means that there is little scope to go back and make changes based on emerging requirements. For example, after coding has begun, no further design work could be done, even if the user’s needs change.

Another danger of the waterfall methodology

This methodology was found to have numerous problems, and be unsuitable for a typical software development process. So in 2001, a group of engineers came together and devised the ‘Agile Manifesto’

Agile Software Development

The Agile process aims to address the inflexibility of a traditional waterfall methodology. Essentially Agile development is iterative, and consists of short repetitive cycles. These are typically:

1. evaluate the existing solution
2. design a solution, based on the last solution, to the problems found during evaluation
3. build this new solution
4. GOTO 1

With a cycle being completed every few weeks, this process should be repeated until the software is complete (or no significant problems are found with the solution)

Sometimes going in circles can get you somewhere

Agile and UX

So why is the Agile methodology best suited to integration with user experience testing? Since you ask, there are a whole bunch of reasons!

1. The Agile method gives a workable product that can be shown to users earlier, getting their opinions and insights straight away.
2. Has appropriate stages for fixing problems found by users earlier. In a waterfall methodology users won’t see a product until the last phases, and by then changes will be costly, or impossible.
3. Waterfall methodologies assume that you can know everything about the requirements of a project at the outset. Real life experience with clients shows that this isn’t often the case. Agile allows for input throughout the process, and doesn’t presume to know the unknowable.
4. Waterfall only engages the stakeholder s (anyone who is interested in the final product) at the beginning of the design process, and then keeps them in the dark until the final unveiling at the end. Obviously this makes what would normally be a minor problem with the final product into a big deal, because it is ‘complete’. In contrast, using UX methods on an Agile methodology keeps stakeholders invested in the product throughout the design process, minimizing dissatisfaction with the final product, and ultimately leading to happier stakeholders.

The UPA have recently been focused, in their magazine coverage and events, on integrating UX tools into an Agile methodology, but I’d be interested in hearing other people’s thoughts, or insights into the advantages of Agile. What are your thoughts on Agile?

Related posts:

1. The 5 secrets to happy players with Agile Games Development
2. The right environment for user testing
3. How real-world game usability testing is changing