UX in the Game Development Process — Part 2: Converge
In this blog series, we walk through the game development process and point out key moments when adding UX Researchers and Designers into the discussion can reduce time, increase momentum, and positively influence the final product.
In the last post, we discussed the first phase of the game development process: Ideation. During this initial phase, the game’s basic story is laid out, and game features classified as “must haves”, “nice to haves” and “table stakes” are defined. During Ideation, divergent ideas are imagined, encouraged, explored, and their relative importance is weighed.
In this post, we will cover ways in which UX can help the game development team during the Convergence phase — the time of the process when choices start being made.
After Ideation — Real Choices
The second phase of game development is about a convergence of ideas. Convergence is the time when you eliminate all of the undesirable ideas and focus on one or two ideas that appear to be winning, plausible directions. Once that is done, it is time to scope the project. It is time to make choices.
During the Convergence phase, the team will be busy storyboarding, digging into the preferences of their best bet target audience, and defining the game mechanics, reward structure, and visual style. The game artists are developing the characters, the effects, the landscape. The “universe” of the game is becoming clear and the game is starting to look like something that resembles a story.
As decisions are made, the game starts to converge on a unified environment and the list of details that need to be figured out starts to grow.
How does User Experience help with the Converge phase?
Between UX Research and Design there a several big areas that they can tackle, most importantly: feature prioritization, shell and menu design, and game interaction design.
Can’t Make It All — Cliffnotes On Feature Prioritization
There are three primary groups of features that every product has. There are “must haves”, “nice to haves”, and “table stakes”. Sometimes, “table stakes” and “must haves” are confused. The distinction is that “must haves” are features that drive potential customers to your product. “Table stakes” are the features that, if not present, will drive your customers away from your product.
Unfortunately, “must have” features get all the attention.
“Must haves” are the parts of the game that make it into the demos and press releases and, quite frankly, make the game sexy. “Table stakes” features are more often than not, essentially invisible. Because of that, they are sometimes put on the back burner.
The unfortunate outcome of putting them off is that it becomes easy to slip them off the work item list altogether or give them only cursory attention late in the development/iteration phase. By this time, it is probably evident that this discussion of “table stakes” versus “must haves” comes to a critical junction when establishing the timeline.
There are way too many factors that go into establishing a timeline for game development to address here. However, ensuring that the timeline has space to land, the “table stakes” items can make the difference between a hit and a mediocre game. This becomes a real pinch for teams, especially when using Agile development practices or Lean engineering to develop the game.
We have found that the best way to keep the balance between “must haves” and “table stakes” is to have regular frequent contact with the target audience.
Gathering user feedback can cause turmoil as well. The audience is seeing a partially finished game and everyone knows that. It is tempting for the team to want to caveat the work as it is shown to the audience. By caveat we mean focusing the attention of the users who are providing feedback on one or two aspects of the game — like target acquisition, or steering mechanics. However, doing so can make your test audience gloss over and forgive problems and issues in “table stakes” items.
In some cases, for example, when trying to nail down a specific interaction, providing caveats will help focus the feedback of the audience. However, letting the game stand on its own each time it is shown to potential customers can ensure that the list of feature priorities is correct and the balance between the “must haves” and the “table stakes” is maintained.
Playtests, usability sessions, and 1:1 interviews are all valuable tools in determining whether a game has moved too far towards “must haves” and too far away from “table stakes”.
Keeping Them From Leaving
During the Convergence phase, UX Design initiates their design of the “shell”. In this case, we define the “shell” as the parts of the game that are not part of the play mechanics. This could include the menus, game settings, options, etc.
In a well designed game, the menus should not be a harsh contrast to the actual game, even though menus are, for practical purposes, a wrapper. The best shell design works under the same paradigm and universe as the game itself. If the game has a rotary menu system, the shell should match that as well. It doesn’t have to be exactly the same, but familiar.
It takes a good designer to fit all of the dry shell necessities in an efficient way within a game that is created for fun. A good game immerses the target audience in new environments, and a good shell design should not make them surface too abruptly.
Dirt2 was a racing game that did a good job of keeping the theme of the game in mind as the user traverses the non-gameplay portions. For example, the player moves through different in-game geographies when moving from one type of menu to another, which keeps the groupings logical and their locations race-like.
The menu titles appeared as if written on duct-tape, much like the participant areas of a real race settings. These bits of authenticity helped to keep the player immersed in the racing world while facilitating their navigation both in and out of the gameplay itself.
Shell efficiency is as important as the look and feel. After all, players want to play and not mess around with optimizing the game for their specific needs. Keeping the menu system and game options as efficient as possible should be the priority.
User Experience Design can accomplish that through workflow identification, wireframing, and prototyping. User Experience Research can run usability sessions to identify any problems with the workflows or bring wireframes into the lab to ensure ‘ease of use’.
There are quite a few resources on the Web that can provide examples of good shell design. There are many more examples of bad shell design. Bringing design into the conversation when the team is converging can help games stay out of the bad category. Being part of the early discussions ensures that the designers understand the game itself to produce the most efficient and appealing shell design.
User Experience Design is also integral to the in-game play as well — helping engineers think through the different actions that a user will have to do, and mapping that workflow to the most logical control arrangements. UX Design can help identify when a game is putting too much complexity into an interaction. User testing of the interactions can identify the usability problems, but designers need to figure out how to fix issues uncovered by said testing. More on that in the next post.
If we imagine that at this point we have a game concept, some initial art, a story arc, and some shell design complete — all of which have been shown to users for initial feedback — the hard work to make the next big hit really enters high gear.
This is part 2 of a 3-part blog series on how UX can fit into the game development process. Check out Part 1: Ideate and stay tuned for Part 3: Iterate & Produce.
