UX + Agile for Game Development

Game industry is going pretty well, right? But how many projects die after years of developing or even before shipping? Tons.

In this very enlightening study, the authors found that game industry suffers from some of the same processual issues addressed in traditional software industry, being some of them:

- Unreal or ambitious scope

- Decisions based on intuition instead of target audience's needs

- Bad management over available resources

User Experience Design is an user-centered (UCD) methodology which can be put into Agile or Lean design sprints in order to deliver, within company resources limitations, games that provides value to target players.

Here I present a workflow in which J. J. Garret's User Experience elements are put inside Agile design sprints:

This workflow was originally published as a paper at SBGames conference (2017).

During the first Sprints various ideas and tests may be needed to find out if the element of fun and monetization are balanced and as this becomes clearer, we can gradually focus on the Surface. The thing here is to fail faster!

By finding the potential for fun and conversion into a core game (MVP), we can gradually add new game elements that enhance the enjoyment, monetization, and attractiveness.

Lets talk about the phases (in a nutshell)!

STRATEGY

Last things first: what is our finish line?

Do we want to have 300k daily engaged players in our live game within 2 years? In order to validate our decisions we must be able to compare the always progressing actual status with some success metrics. The first sprints are naturally more abstract, so are these metrics that can be updated with no big damage at this first moments, but have it clear: all decisions, from gameplay to aesthetics must be a result from this strategy, so here is a high priority set of variables to be first tested and validated: has our game potential to engage?

What is our business goals?

Within the human and time resources, we must to have our investment back in two years? Or do we only want to make visibility for investors showing a high-polished game sample in 6 months? In any possible case, the business must achieve value, and UCD propose that will happen once we deliver value to users, here the players, so...

Who is our target player?

Once game designers aren't common gamers, this is necessarily an external learning process, we want to know who they are and what our players want. Gamers patterns and expectations can be found through competitors analysis (which I'll go deeper in another post) and can be organised with the famous Personas methodology. Once defined, for each decision or feature we can ask "is this valuable for some of the personas we are trying to achieve?".

SCOPE

Once we have some idea about the business' goals and players' expectations, here we strategically define the next more critical features that we will offer to meet those requirements.

Idealisation

Here there is an internal process of the team, be it by brainstorm or another process, where we have ideas about what the game will offer. But we can also glimpse an external process, for example, during prototype tests where the needs or ideas of features of the players may arise and, as they have perceptions and a cultural repertoire different from the producers, these discoveries can be valuable.

Organization

Together the team documents a timetable pointing out the temporal and human resources needed to accomplish each task. Each new feature may seem like a simple addition that would take a couple of hours to implement, but often each addition can influence others, or itself generate a series of requirements that can escape consciousness when only one team member projects the scope calendar.

STRUCTURE

Interaction Design

Here we seek out the best ways for the game to respond to player interactions. Rather than developing features, and considering that user difficulties dealing with them are part of the learning process, interaction design explores the varied ways players interact with the proposed game and how the system responds effectively.

Information Architecture

Here we explore the ways people process and absorb information cognitively. Here the most important information sought by the player can be structured in a hierarchical way, as well as the ones that are wanted to be transmitted to him. You can consciously design information frequency in a similar way to Game Design's pacing concept, so that information flows are transmitted according to the progress of the player avoiding saturation.

SKELETON

This phase is composed of three approaches: interface, navigation and information design (I need another post to talk about each one!). Here the features that have been structured in the previous phase begin to express themselves more concretely in sketches of how each functionality of the game will effectively be presented to the players.

A useful tool at this stage is the rapid prototyping through wireframing, which makes it possible to see and interact with all information proposed before they are brought into production.

SURFACE

Although it is tempting to start a game ideation by its theme - "it will be a fanciful medieval RPG with characters from the animal kingdom" or even "a futuristic and realistic FPS with Russian soldiers" - these choices are more towards the surface step than for the strategy step. The surface plane derives from the strategy plan, but when the objective is to provide certain experiences it is possible to put various thematic possibilities as possible resolutions, taking into account the resources needed to provide each result.

VALIDATION

Finally, as a result from other phases, at the end of each sprint here we must have a prototype that will answer some previously specified questions, again: the most critical first!

To test, for example, how engaging is the gameplay for an athletics running game, it is not necessary to produce a detailed scenario with animated athletes and interface buttons with visual finish. Once the focus is to test the engagement of the gameplay experience, colored balls representing runners with the proposed mechanics can be enough. If in this case the gameplay is not minimally engaging, the high quality aesthetic finishes may not be enough to keep players interested in the game for a long time.

Answers achieved: next sprint!

Cheers for you who got here, hope you enjoyed! Deeper information can be found at J. J. Garret book: The Elements of User Experience.